Clients senden DNS Dynamic Update Pakete nicht zuverlässig

[notimportant 0]

Hallo zusammen,

 

ich habe mal wieder ein sehr spezifisches Problem.

 

Und zwar haben wir in unserer Umgebung Probleme mit den automatischen Updates der DNS-Records.

 

Nur in Kürze die notwendigen Eckpunkte:

• AD integriertes DNS
• Clients registrieren ihre A-Records selbst, die Reverseeinträge übernimmt der DHCP (also keine Option 81, sondern Standard)
• Nichtaktualisierungsintervall 7 Tage + Aktualisierungsintervall 7 Tage ... danach Scavenging der Records

 

Hat jahrelang funktioniert, es wurde keine wissentliche Änderung gerade an solchen Kernfunktionalitäten vorgenommen, jedoch seit dem Herbst gibt es Probleme mit den automatischen Aktualisierungen.

D.h. die DNS-Records vieler Clients altern aus dem DNS raus und werden vom Scavengingprozess gelöscht, obwohl diese Rechner:

• per DHCP versorgt werden
• täglich neugestartet werden

 

Meines Wissens muss ein Client ja bei Neustart, wenn seine DHCP-Lease erneuert wird ein Dynmaisches DNS Update versuchen. Und gerade das scheinen unsere Clients zum großen Teil nicht mehr zuverlässig zu senden.

• Wir haben keine GPO bzgl. RegistrationRefreshIntervall o.ä. gesetzt.
• Die "üblichen" Verdächtigen "primäres Domain Suffix" usw. sollten alle als "passt" angehakt sein.

 

Ich kann folgende Szenarien beobachten, erstellt unter der Zuhilfename einer großen Anzahl von Traces auf verschiedenen Clients:

 

Szenario 1: "Alles OK"

Der Client sendet einige Sekunden nach Konfiguration der NIC die folgende Paketreihenfolge: SOA-Anfrage, SOA-Antwort, DNS-Update-Anfrage, DNS-Update-Refused, TKEY-Negotiation, DNS-Update-Anfrage, DNS-Update-Success. Ganz brav, wie es MS hier etwa beschreibt: Secure Dynamic Update

 

Szenario 2: "Keine TKEY Negotiation"

Der Client sendet folgende Paketreihenfolge: SOA-Anfrage, SOA-Antwort, DNS-Update-Anfrage, DNS-Update-Success.

Es erfolgt keine TKEY-Negotiation. Das sollte doch eigentlich nur passieren, wenn keine Secure Updates verwendet werden. Diese sind aber auf allen DNS-Servern als zwingend konfiguriert.

 

Szenario 3: "Gar nix passiert"

Der Client sendet keine DNS-Update-Pakete. Gar nicht. Das sollte, wenn ich es richtig verstehe, definitiv nicht vorkommen. Erklären kann ich es mir nicht. Solche Clients kann ich auch durch Änderung der Richtlinien (explizit DynUpdates aktivieren, RegistrationRefreshIntervall auf fixe 30 Min setzen) nicht dazu bewegen bei Neustarts zuverlässig die Updatepakete zu senden.

 

Anmerkungen zu 1,2,3:

Die Szenarien sind nicht fix auf einen Client beschränkt. Es gibt zwar Clients die relativ zuverlässig in Szenario 3 sich bewegen, aber eine große Anzahl der untersuchten Rechner sendet eben mal ein DNS-Update-Paket und eben mal nicht. Das ist über Modellvarianten brav verteilt. Es sind ca. 10-20% der Clients (ca. 3 -7.000 von 30.000) immer betroffen, wir sind ab Sommer/Herbst großflächig auf 20H2 migriert. Die Auffälligkeiten sind zusammengefallen, aber eine logische Verbindung konnte ich noch nicht herstellen.

 

Szenario 2b: "Test Lab"

In einem Testlab (DC auf Server 2022, alles ziemlich default) sendet ein Client zuverlässig, d.h. immer zu 100%, kurz nach seinem neuen DHCP-Lease seine DHCP-Update-Pakete. Diese allerdings auch immer ohne TKEY-Negotiation.

 

Frage 1:

Hat jemand irgendeine Idee, wo wir noch ansetzen könnten? Ich denke das ist eine Kernfunktionalität des DHCP-Client-Services. Keine Idee, wo man das kaputtkonfigurieren sollte.

 

Frage 2:

Kann jemand das seltsame TKEY-Negotiation-Verhalten erklären? Müsste das nicht immer auftreten? Oder ist hier die MS-Doku veraltet?

 

Viele Grüße

notimportant

bearbeitet 15. März 2022 von notimportant

[testperson 1.535]

Hi,

vor 24 Minuten schrieb notimportant:

Hat jemand irgendeine Idee, wo wir noch ansetzen könnten? Ich denke das ist eine Kernfunktionalität des DHCP-Client-Services. Keine Idee, wo man das kaputtkonfigurieren sollte.

 

ist auf den (betroffenen) Clients das Logging für den DHCP Client und DNS Client an und findet sich dort evtl. etwas hilfreiches?

Get-WinEvent -ListLog @("*dns-client*", "*dhcp-client*") | ft LogName, IsEnabled

 

Gruß

Jan

[notimportant 0]

Per default nicht, das haben wir aber bei den traces aktiviert und mitlaufen lassen. Leider so gar nichts ungewöhnliches.

[MurdocX 904]

vor 23 Stunden schrieb notimportant:

Szenario 2: "Keine TKEY Negotiation"

Der Client sendet folgende Paketreihenfolge: SOA-Anfrage, SOA-Antwort, DNS-Update-Anfrage, DNS-Update-Success.

Es erfolgt keine TKEY-Negotiation. Das sollte doch eigentlich nur passieren, wenn keine Secure Updates verwendet werden. Diese sind aber auf allen DNS-Servern als zwingend konfiguriert.

In der Dokumentation steht, dass ein unautorisierte Aktualisierung abgelehnt werden muss. Im nächsten Schritt findet eine Kerberos-Authentifizierung statt. Hier könnte man ansetzen.

 

vor 23 Stunden schrieb notimportant:

täglich neugestartet werden

Ist denn der Hybernate-Modus aus- oder eingeschaltet? Eventuell startet der (AFAIK Dhcp-Client) nicht neu.

[notimportant 0]

Hallo,

 

vor 5 Stunden schrieb MurdocX:

In der Dokumentation steht, dass ein unautorisierte Aktualisierung abgelehnt werden muss. Im nächsten Schritt findet eine Kerberos-Authentifizierung statt. Hier könnte man ansetzen.

 

Genau. Das Bild kann ich auch genauso sehen (Die KRB5-Frames sind ausgeblendet):

 

 

Ich verstehe nur nicht, weshalb ein und derselbe Rechner auch das hier macht. Ich würde erwarten, dass ich immer obiges Bild erhalte.

Übersehe ich etwas? Im Testlab erhalte ich immer untenstehendes Bild (aber auch hier sind only-secure-Updates aktiviert).

 

 

Oder eben die Dynamic Update - Pakete gar nicht auftauchen.

 

Beim Aushandeln mit dem DHCP sieht dann noch immer alles gut aus:

 

 

Aber es tauchen keine Dynamic Update Pakete auf.

 

vor 5 Stunden schrieb MurdocX:

 

Ist denn der Hybernate-Modus aus- oder eingeschaltet? Eventuell startet der (AFAIK Dhcp-Client) nicht neu.

 

Ist definitiv deaktiviert.

 

Grüße

 

bearbeitet 16. März 2022 von notimportant