MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Dynamische DNS Updates, dNSTombstoned und DHCP Option 81

Wenn Computer eine dynamische IP-Adresse bekommen, dann sollte der Hostname und die IP-Adresse per DNS auflösbar sein. Diese Seite beschreibt den Prozess, wie der A- und PTR-Record für einen Clients mit dynamischer IP-Adresse korrekt im DNS ankommt. Wenn nämlich sowohl der DHCP-Server als auch Client den Namen registrieren, kann es zu Konflikten und Problemen kommen. Hierbei spiel die DHCP Option 81 eine wichtige Rolle.

Kurzfassung

Bei einem meiner Kunden hat die Firewall per Reverse-DNS den Namen eines Computers zur IP-Adresse einer Verbindung aufgelöst und zum Namen die Gruppen gesucht und Richtlinie angewendet. Das funktioniert natürlich nur, wenn die DNS-Auflösung vorwärts (Name>IP) und rückwärts (IP->Name) die korrekten Namen liefert. Damit das auch sicher funktioniert, erlaube die DNS-Server nur sichere Updates, bekommen von DHCP-Server ihre Adressen und  sind Domainmitglied. Dennoch hat es nicht gepasst und bei der Analyse haben wir folgende Verhaltensweisen ermittelt.

  • Clients bekommen per DHCP Adressen angeboten und senden mit dem DHCP REQUEST in der Option 81 mit, ob sie selbst ihren Namen im DNS eintragen können.
  • Der DHCP-Server wertet dies aus und liefert in seiner DHCP ACK-Antwort über Option 91 seine Entscheidung mit.
    Mit der passenden Konfiguration kann der DHCP-Server dem Client verbieten, die DNS-Einträge zu aktualisieren. Auf dem DNS-Server gibt es keine Option, die Aktualisierungen auf einen DHCP-Server oder Dienstkonto zu beschränken.
  • Windows 8.1 und höher ignorieren die RFC4702 per Default
    d.h. die machen immer eigene DNS-Updates, obwohl DHCP es ihnen verbietet und als Domainmitglied können Sie dies auch. Um "Konform" zu sein, müssen Sie auf dem Client extra einen Registrierungsschlüssel (RegistrationOverwrite=2) setzen.
  • Die Einträge im DNS habe ACLs
    Wer zuerst den Eintrag im DNS anlegt (DHCP oder Client) wird zum Besitzer und blockiert noch lange Zeit spätere Änderungen durch andere Systeme. Selbst wenn der Lease abgelaufen ist und der Eintrag in der DNS-MMC und per NSLOOKUP nicht mehr auffindbar ist, bleibt er weiterhin als LDAP-Objekte mit dem Property "dNSTombstoned=TRUE" und der ACL existent. Das macht es außerordentlich schwer in Testfeldern das Verhalten zu analysieren.
  • Clients machen kein "DHCP RELEASE"
    Es gibt zwar die Option im DHCP-Protokoll aber anscheinend macht das weder Windows 11 25H2 noch FreeBSD 15. Nach dem Ablaufen des DHCP-Lease im DHCP-Server wird der Lease gelöscht aber der Eintrag im DNS bleibt weitere vier Stunden unverändert erhalten, bis er durch den DHCP-Server auf "dNSTombstoned=true" gesetzt wird und damit entfällt.
    Nur ein aktives Löschen des Lease im DHCP-Manager setzt sofort "dNSTombstoned=true" aber das LDAP-Objekt wird nicht gelöscht.
  • DNS-Scavenging löscht veraltete Einträge aber ist per Default "Off"
    Damit bleiben alte Einträge quasi "für immer" erhalten und blockieren ein Recycling von IP-Adressen im DNS.
  • Wenn DHCP und DNS auf einem DC laufen, ist ein Dienstkonto zwingend.
    Ansonsten funktionieren die dynamischen Updates durch den DHCP-Server nicht zuverlässig

Wenn Sie nun neugierig geworden sind, dann können Sie sich den kompletten Analysepfad mit den Erkenntnissen und Schlussfolgerungen durchlesen.

Das Problem?

Eine Administrator kann bei seinem DNS-Server hinterlegen, für welche DNS-Zone auch dynamische Updates möglich sind. Das bedeutet, dass ein Client oder auch ein DHCP-Server im Auftrag des Clients entsprechende Einträge addieren kann. Früher haben sich Windows Clients per WINS eingetragen, damit andere Systeme zum Namen eine IP-Adresse auflösen konnten. Heute macht das DNS. Wenn Sie die Zonen im Active Directory ablegen, dann können Sie sichere Updates einstellen, so das die Clients sich vorab authentifizieren müssen.

Das können eigentlich alle aktuellen Windows Clients und Server, sofern sie Mitglied der Domain sind und sich authentifizieren können. Die meisten Drucker, IoT-Geräte etc. können dies aber nicht. Daher kann auch der Windows DHCP-Server diese Arbeit für den Client übernehmen, z.B. wenn diese die Funktion nicht unterstützen oder nicht in der Domain sind.

Für die weitere Betrachtung stelle ich Updates auf "nur sichere". Das ist aus meiner Sicht der einzige sinnvolle Wert, wenn Sie Veränderungen durch nicht authentifizierte Clients verhindern wollen.

Achtung:
Ein Wechsel der Authentifizierung kann ohne vorherige Anpassungen die späteren Updates aufgrund falscher Berechtigungen verhindern.

Damit die Updates gegen Überschreiben oder Veränderungen anderer Clients geschützt sind, arbeitet Windows DNS mit Berechtigungen. Der Computer oder das Dienstkonto, welches die DNS-Einträge vornimmt, wird zum Besitzer und erhält die Berechtigungen zum Update und Löschen. Das sehen Sie hier am Beispiel eines Windows 11 Clients, welcher selbst die Einträge vorgenommen hat und eines FreeBSD-Clients, der dies nicht konnte und der DHCP-Server die Arbeit übernommen hat.

 

Damit wird aber nun klar, dass nicht nur theoretisch sowohl ein Client als auch ein DHCP-Server die Einträge pflegen möchte. Was passiert, wenn ein Client einfach verschwindet und sein DNS-Eintrag und insbesondere der Reverse-DNS-Eintrag bestehen bleibt, während der DHCP-Server die Adresse wieder neu vergibt. Microsoft beschreibt selbst auch, was das Problem ist.

 
Quelle: Unexpected DNS record registration behavior if DHCP server uses "Always dynamically update DNS records" 
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-registration-behavior-when-dhcp-server-manages-dynamic-dns-updates

Das Problem ist hier sogar nur partiell beschrieben. Denken Sie sich folgendes Szenario:

  1. Ein Client bekommt eine IP und registriert diese selbst und wird damit Besitzer
    Der DHCP-Server ist diesmal nicht schnell genug
  2. Der Client verlässt das Netz (z.B. WLAN) und kann sich nicht deregistrieren
  3. Der DNS-Eintrag bleibt erhalten, wenn kein Scavenging aktiv ist
  4. Der DHCP-Lease läuft aus und der DHCP-Server vergibt die Adresse erneut
  5. Weder der neue Client noch der DHCP-Server können den PTR-Record aktualisieren

Wie lösen wir das Problem und warum ist es ein Problem?

Wenn Sie einen DHCP-Server und mehrere DNS-Server haben, dann kann es sein, dass Client und der DHCP-Server unterschiedliche DNS-Server nutzen und im Moment einer Neueintragung noch kein Problem haben. Die AD-integrierte Zonen werden dann aber bei der Replikation einen Konfliktfall erkennen.

DHCP Option 81 und DNS

Es beginnt alles damit, dass ein Client nach DHCP-Servern sucht um eine IP-Adresse zu erhalten. Die DHCP-Server bieten je eine Adresse an und es ist wieder am Client, von den Angeboten verschiedener DHCP-Server eine Adresse auszuwählen, verbindlich anzufordern und vom DHCP-Server bestätigen zu lassen.

Dieser Prozess wird DORA (Discover - Offer - Request - Acknowledge) genannt. Am Ende hat der Client eine IP-Adresse. Im DHCP Request und DHCP ACK-Paket gibt es nun die Option 81, mit dem der Client dem Server seinen FQDN mitgibt und der Server dem Client sagen kann, wer für die Registrierung im DNS zuständig ist. Der Client kann folgende Informationen neben dem FQDN senden:

DHCP Request Beschreibung

Option 81 nicht gesetzt

Der Client kann keine Option 81 und der DHCP-Server erkennt einen "alten" Client, für den er bei entsprechender Konfiguration die DNS-Einträge stellvertretend vornimmt.

Option 81 gesetzt 

Der Client gibt dem Server den FQDN, damit der Server die Eintragung vornehmen kann.

Das Option 81-Feld hat aber noch mehr Informationen. Dazu schauen wir uns die Pakete eines Clients und die Antwort des Servers an.

DHCP mit Windows 11

Ich habe einen Windows 11 25H2 Client in meinem Labor gestartet und mit Wireshark auf dem DHCP/DNS-Server die Pakete mitgeschnitten. Zuerst sehen wir den "DHCP Discover" gefolgt von einem "DHCP Offer". In diesem beiden Paketen ist noch keine Option 81 enthalten. Erst bei "DHCP Request" sendet der Client die DHCP Option 81 mit dem FQDN des Clients mit.


DHCP Request vom Client zum Server

In der "DHCP ACK"-Antwort des Server ist auch die DHCP-Option 81 enthalten. Dies ist aber die Entscheidung des Servers.


DHCP ACK vom Server zum Client

Der DHCP-Server sagt hier deutlich, das ein "Server overrides: Override" und "Server: Server" steht.

Option 81 Flags

Die Flags haben eine wichtige Bedeutung. Damit kann der Client seinen Wunsch äußern und der Server teilt ihm seine Entscheidung mit. Interessant sind hier die vier Bits der Flags. Im Paket vom Client zu Server haben wir folgende Bedeutung:

Bit th> Bedeutung 0 1

0 

Server  (S)

Client will Updates machen

Server soll die Updates machen

1 

Server overrides (O)

Client muss das Bit auf 0 setzen

Ungültig

2 

Encoding

ASCII

Canonical Wire Format

3

Server DDNS

Server soll Updates machen

Server soll keine Updates machen

4-7

Reserviert

Reserviert

Reserviert

Was der Client zum Server sendet, können Sie nicht anpassen.

Microsoft's DHCP client doesn't provide a method to directly set the client's O and S values in the user interface. By default, both values are 0
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-registration-behavior-when-dhcp-server-manages-dynamic-dns-updates  

In Gegenrichtung kann der Client wie folgt antworten:

Bit  Bedeutung 0 1

0 

Server  (S)

Server macht keine Updates

Server soll die Updates machen

1 

Server overrides (O)

Der Server

Server hat Client überstimmt (S-Bit abweichend)

2 

Encoding (Server muss gleiches Format wie der Client nutzen)

ASCII

Canonical Wire Format

3

Server DDNS

Server soll Updates machen

Server soll keine Updates machen

4-7

Reserviert

Reserviert

Reserviert

Der Client kann per Flags neben dem Encoding mitteilen, ob der Server die Updates machen soll oder nicht. Der Server muss sich daran aber nicht halten und kann selbst die Updates vornehmen und dies dem Client mitteilen. Der Server kann den Client also "überstimmen" aber muss in der Antwort die entsprechenden Bits dann setzen, damit der Client dies auch verarbeitet.

Achtung:
Windows 8.1 und neuer ignorieren die Anweisungen des DHCP-Servers und halten sich damit nicht an die RFC 4702. Windows versucht in der Standardeinstellung immer selbst das DNS-Update, auch wenn der DHCP-Server dies untersagt.

Leider hat Microsoft sich dafür entschieden, die RFC an einer Stelle zu ignorieren und dokumentiert dies auch:

In Windows 8.1 and later versions, the DHCP client doesn't honor the DHCP server's Option 81 O and S values. If the client is configured to update A records, it continues to do this even if the server is also configured to update A records. That's the case when you select Always dynamically update DNS records in the DHCP management console.
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-registration-behavior-when-dhcp-server-manages-dynamic-dns-updates  

Ein DHCP-Server kann dem Client zwar ein DHCP ACK-Paket senden, indem er sich für die Updates verantwortlich bezeichnet, aber das hindert einen Windows Client dennoch nicht daran, selbst die DNS-Updates vorzunehmen. Die RFC4702 "The DHCP Client FQDN Option" beschreibt die Funktion aber ist genaugenommen nur ein "Request vor Comments" und kein "Gesetz". Da kommen wir aber im übernächsten Abschnitt noch einmal darauf zurück.

Option 81 auf dem DHCP-Server

Wenn Sie sich auf dem DHCP-Server nun die Bereichseinstellungen anschauen, dann gibt es dort gar keine Option 81. Das ist auch in Ordnung, denn Microsoft hat die Einstellungen in der DNS-Karteikarte auf dem IPv4-Knoten als auch bei jedem einzelnen Bereich angeordnet, welche umfangreiche Einstellungen erlaubt:

Wenn ich möchte, dass mein DHCP-Server die Verwaltung der DNS-Einträge vornimmt, sollte ich die Einstellungen so konfigurieren. Sie stellen sicher, dass der DHCP-Server immer die Updates vornimmt und den Client überstimmt. Damit das möglich ist, sollten Sie ein Dienstkonto anlegen, welches in der Gruppe "DNSUpdateProxy" Mitglied ist, so dass es die Berechtigungen hat.

Please note that if we deploy Domain Controller and DHCP Server roles in the same server, then using dynamic update credential is not optional but mandatory. If DC and DHCP are on the same server, dynamic update would not work properly without configuring credential
https://learn.microsoft.com/en-/archive/technet-wiki/51810.windows-server-integration-between-dns-and-dhcp

Die Einstellungen der GUI sehen Sie später nicht in den DHCP-Optionen. Dort gibt es keine Option 81 aber eine Abfrage mit "Get-DhcpServerv4OptionValue" liefert sowohl für den Server als auch jeden Bereich entsprechende Werte.

Ich habe dann ein paar Einstellungen durchprobiert und die verschiedenen Werte hier protokolliert:

Einstellung  Option 81 

Alle DNS-Update-Funktionen abgeschaltet

0

DNS Einträge nur nach Anforderung

1 

DNS Einträge immer dynamische 

17 

DNS Einträge immer dynamisch und A/PTR beim Löschen verwerfen 

21 

DNS Einträge immer dynamisch, A/PTR beim Löschen verwerfen und NT4 dynamisch

23

DNS Einträge immer dynamisch, A/PTR beim Löschen verwerfen, NT4 dynamisch und PTR deaktivieren

87

Daraus ergibt sich folgende Bedeutung der einzelnen Bits:

Bit Dez  Beschreibung
 0   1   Dynamische DNS-Aktualisierungen ein
 1   2   DNS-Einträge für DHCP-Clients, die keine Aktualisierung anfordern dynamisch aktualisieren
 2   4   A- und PTR-Einträge beim Löschen des Lease verwerfen
 3   8   <keine Funktion>
 4  16   DNS-Einträge immer aktualisieren
 5  32   DNS Name Protection  (Addiert einen DHCID-Eintrag zum Schutz gegen Name
 6  64   Dynamische Updates für PTR-Einträge deaktivieren
 7 128   <keine Funktion ?>

Was die anderen Bits bedeutet, konnte ich noch nicht in Erfahrung bringen.

Später finden Sie noch Wireshark-Mitschnitte. Was sie hier einstellen, wirkt sich aber nur auf das interne Verhalten des DHCP-Servers aus..

Anscheinend wirken die Einstellungen nur im DHCP-Server aber nicht zum Client.

DHCP-Client akzeptiert O=1

Diese Probleme wollen wir lieber gleich verhindern. Ideal ist, wenn der DHCP-Server für alle Eintragungen verantwortlich ist. Zum Glück dokumentiert Microsoft auf der gleichen Seite aber auch eine Einstellung, mit der Sie den Windows Client zu einem RFC4702-konformen Verhalten bringen können. Der folgende Registrierungsschlüssel korrigiert das eigenmächtige Verhalten.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
"RegistrationOverwrite"=dword:00000002
  • 0 = nicht überschreiben
  • 1 = Client überstimmt DHCP-Rückmeldung
  • 2 = DHCP-Einstellung überstimmt den Client

Auf meinem Windows 11 25H2-Client wurde die Einstellung umgehend aktiv. Ich habe einfach eine DNS-Registrierung erneut wie folgt angefordert:

ipconfig /registerdns

Beim ersten Mal habe ich sogar noch gesehen, dass der DNS-Client seine früheren Einträge selbst noch gelöscht hat und alle nachfolgenden Versuche habe keine DNS-Update-Aktivität des Clients mehr mit Wireshark gezeigt. Der DHCP-Server hat nun die Zeit gehabt, den Eintrag vorzunehmen und sich auch als Besitzer mit Berechtigungen einzutragen.

Mein zweiter Test war die freundliche Rückgabe der IP-Adresse.

Hinweis:
Wenn Sie Windows 11 25H2 herunterfahren, sendet es bei mir keinen DHCP-RELEASE.

ipconfig /release

Der Client hat keine DNS-Updates gesendet aber der DHCP-Server hat umgehend den Namen aus der DNS-Zone entfernt. Zuletzt habe ich den Windows 11-Client einfach "pausiert", so dass er keine DHCP-RENEW-Anfragen mehr stellen konnte aber die IP-Adresse auch nicht abgegeben hat. Der DHCP-Server hat daher den Client noch nicht entfernt. Nach Ablauf der Lease-Dauer hat der DHCP-Server den Eintrag sofort in seiner Datenbank freigegeben. Der Eintrag im DNS-Server ist aber weiter existent.

Damit bestätigt sich wieder das Verhalten, dass der DHCP-Server einen von ihm gesetzten DNS-Eintrag nur aktiv löscht, wenn ich den Lease als Administrator auf dem DHCP-Server lösche. Wenn der Lease einfach nur abläuft und der DHCP-Server ihn in seiner Datenbank löscht, dann bleibt er im DNS-Server vorhanden.

Das mag überraschend sein aber sonderlich kritisch sollte es nicht sein, denn wenn der DHCP-Server die Hoheit hat, dann kann er auch einem anderen Client die freie IP-Adresse geben und den Eintrag aktualisieren. Nur ein Client, kann den Eintrag natürlich nicht verändern.

Mir wäre es lieber, wenn der DHCP-Server sowohl bei der manuelle Löschung als auch beim Ablaufen eines Lease den DNS-Eintrag mit entfernt.

DNS Client mit GPOs steuern

Es gibt noch eine zweite Option, die Clients hinsichtlich DNS zu steuern. In den Gruppenrichtlinien gibt es z.B. die Steuerung zu "Dynamisches Update" und feinere Steuerungen.

Ich habe einfach mal die DNS-Updates komplett abgeschaltet. Dies geht auch per Registrierung.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DisableDynamicUpdate"=dword:00000000

In Wireshark habe ich dann die Auswirkungen kontrollieren.

  • Keine DNS-Updates
    Der Client hat keine DNS-Updates mehr an den DNS-Server gesendet.
  • DHCP Option 81 unverändert
    Der Client hat aber weiterhin beim DHCP REQUEST seinen FQDN gesendet, so dass der DHCP-Server die Registrierung vornehmen konnte

Die Änderung der Einstellungen erfordert zwar keinen Neustart des Clients oder eines Diensts aber wirken nicht sofort. Wenn dynamische DNS-Updates aktiv waren und sie die Einstellung auf "deaktiviert" stellen, dann wird der Client z.B. bei einem  "ipconfig /release" erst noch einmal per dynamischen DNS seine gemachten Einstellungen rückgängig machen und umgekehrt.

Auch mit der kompletten Deaktivierung von dynamischen DNS-Einträgen auf dem Client wurden die Einträge im DNS korrekt aktualisiert. Das war aber auch zu erwarten, da im DHCP REQUEST die passenden Informationen enthalten waren.

Damit haben wir einen zweiten Weg, die störenden DNS-Eintragungen durch den Client selbst zu unterbinden.

DHCP Bereinigung in DNS

Während der gesamten Zeit habe ich auf dem DNS-Server keine Scavenging-Funktion aktiv gehabt. Dennoch waren nach Ablauf einer Nacht die Systeme aus der DNS-Zone verschwunden. Auf der Suche nach der Ursache habe ich im Protokoll des DHCP-Servers gesehen, dass er Einträge löscht. In der Logdatei steht am Anfang sogar die Beschreibung, was die Nummern in der ersten Spalte bedeuten:

11 Eine Lease wurde von einem Client erneuert.
17 Eine Lease war abgelaufen, und die DNS-Einträge für eine abgelaufene Lease wurden nicht gelöscht.
18 Eine Lease war abgelaufen, und die DNS-Einträge wurden gelöscht.
24 Der Bereinigungsvorgang für die IP-Adresse wurde gestartet.
25 Statistik der IP-Adressenbereinigung.
30 DNS-Updateanforderung an den benannten DNS-Server.
32 Das DNS-Update war erfolgreich.

So vorbereitet lässt sich das Log recht einfach lesen. Die Kommentare mit "#" habe ich nachträglich addiert.

# Ohne Aktivität finden wie jede Stunde ein DB-Cleanup
24,12/09/25,23:45:49,Beginn der Datenbankbereinigung,,,,,0,6,,,,,,,,,0
25,12/09/25,23:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
25,12/09/25,23:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
24,12/10/25,00:45:49,Beginn der Datenbankbereinigung,,,,,0,6,,,,,,,,,0
25,12/10/25,00:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
25,12/10/25,00:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0

#Wenn der Client eine IP-Adresse bekommt wird dies und der DNS-Eintrag protokolliert
30,12/10/25,00:48:21,DNS-Aktualisierungsanforderung,10.0.0.101,NEDI.forest3.msxfaq.de,,,0,6,,,,,,,,,0
10,12/10/25,00:48:21,Zuweisen,10.0.0.101,NEDI.forest3.msxfaq.de,00155D2D7B04,,1005383342,0,,,,,,,,,0
32,12/10/25,00:48:22,DNS-Aktualisierung erfolgreich,10.0.0.101,NEDI.forest3.msxfaq.de,,,0,6,,,,,,,,,0

# Alle zwei Minuten erneuert er die IP-Adresse und wir sehen auch ein DNS Update
30,12/10/25,00:49:21,DNS-Aktualisierungsanforderung,10.0.0.101,NEDI.forest3.msxfaq.de,,,0,6,,,,,,,,,0
11,12/10/25,00:49:21,Erneuern,10.0.0.101,NEDI.forest3.msxfaq.de,00155D2D7B04,,602899764,0,,,,,,,,,0
32,12/10/25,00:49:21,DNS-Aktualisierung erfolgreich,10.0.0.101,NEDI.forest3.msxfaq.de,,,0,6,,,,,,,,,0
30,12/10/25,00:50:21,DNS-Aktualisierungsanforderung,10.0.0.101,NEDI.forest3.msxfaq.de,,,0,6,,,,,,,,,0
11,12/10/25,00:50:21,Erneuern,10.0.0.101,NEDI.forest3.msxfaq.de,00155D2D7B04,,277469701,0,,,,,,,,,0
32,12/10/25,00:50:21,DNS-Aktualisierung erfolgreich,10.0.0.101,NEDI.forest3.msxfaq.de,,,0,6,,,,,,,,,0

# Dann wurde der Client wieder abgeschaltet und die Updates stopppen

# Es geht weiter mit den DB Cleanup und da wird protokolliert, dass der Lease abgelaufen ist
# Der Lease war natürlich schon gegen 00:52:21 abgelaufen aber das wurde nicht protokolliert.
24,12/10/25,01:45:49,Beginn der Datenbankbereinigung,,,,,0,6,,,,,,,,,0
18,12/10/25,01:45:49,Abgelaufen,10.0.0.101,,,,0,6,,,,,,,,,0
25,12/10/25,01:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
25,12/10/25,01:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
24,12/10/25,02:45:49,Beginn der Datenbankbereinigung,,,,,0,6,,,,,,,,,0
25,12/10/25,02:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
25,12/10/25,02:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
24,12/10/25,03:45:49,Beginn der Datenbankbereinigung,,,,,0,6,,,,,,,,,0
25,12/10/25,03:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
25,12/10/25,03:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
24,12/10/25,04:45:49,Beginn der Datenbankbereinigung,,,,,0,6,,,,,,,,,0
25,12/10/25,04:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
25,12/10/25,04:45:49,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0

Erst vier Stunden später erkennt DHCP, dass er den DNS-Eintrag aktualisieren muss
24,12/10/25,05:45:50,Beginn der Datenbankbereinigung,,,,,0,6,,,,,,,,,0
30,12/10/25,05:45:50,DNS-Aktualisierungsanforderung,10.0.0.101,NEDI.forest3.msxfaq.de,,,0,6,,,,,,,,,0
17,12/10/25,05:45:50,DNS-Eintrag wurde nicht gelöscht,10.0.0.101,,,,0,6,,,,,,,,,0
25,12/10/25,05:45:50,0 Leases abgelaufen und 1 Leases gelöscht,,,,,0,6,,,,,,,,,0
25,12/10/25,05:45:50,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
32,12/10/25,05:45:50,DNS-Aktualisierung erfolgreich,10.0.0.101,NEDI.forest3.msxfaq.de,,,0,6,,,,,,,,,0

# Danach ist dann nichts weiter passiert.
24,12/10/25,06:45:50,Beginn der Datenbankbereinigung,,,,,0,6,,,,,,,,,0
25,12/10/25,06:45:50,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
25,12/10/25,06:45:50,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
24,12/10/25,07:45:50,Beginn der Datenbankbereinigung,,,,,0,6,,,,,,,,,0
25,12/10/25,07:45:50,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0
25,12/10/25,07:45:50,0 Leases abgelaufen und 0 Leases gelöscht,,,,,0,6,,,,,,,,,0

Hinweis
Per Wireshark habe ich gesehen, dass weder der Windows Clients als auch eine FreeBSD-VM beim Herunterfahren einen DHCP-RELEASE senden. Der DHCP-Server kann also gar nicht aktiv einen Lease freigeben und den DNS-Eintrag sofort löschen.

Ich habe mich daher auf die Suche gemacht, woher diese Zeiten kommen könnten.  Für dynamische Einträge hat Windows aber noch weitere Intervalle parat:

Funktion  Wert Beschreibung und Quellen

DNS Refresh

24h

Client mit statischer IP-Adresse versuchen alle 24h eine Registrierung. Client mit per DHCP zu gewiesener Adresse registrieren diese jedes Mal, wenn Sie den DHCP-Lease erhalten oder erneuern.

Statically configured clients and remote access clients do not rely on the DHCP server for DNS registration. Statically configured clients dynamically update their A and PTR RRs every time they start and then every 24 hours in case the records become corrupted or need to be refreshed in the DNS database.
Quelle: DNS Processes and Interactions https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197552(v=ws.10)#dynamic-update-process-for-statically-configured-and-remote-access-clients

DHCP Grace Period 

4h

Wenn ein DHCP-Lease durch einen Client nicht weiter verlängert wird und abläuft, dann hat ein Windows Server eine interne Verzögerung von 4h, ehe sie die Adresse wieder vergibt. Das kann ein Problem sein, wenn Netzwerk sehr viele wechselnde Clients haben und mit sehr kurzen Lease-Zeiten eine schnelle Wiederverwendung erwarten.

Although reducing the lease duration creates more DHCP-related network traffic, it increases the rate at which addresses are returned to the available address pool for reassignment. With an average volume of DHCP request traffic, Windows Server 2003 DHCP has a four-hour default grace period after which an expired lease can be reused. This means that an address is marked for deletion four hours after the lease expires, regardless of lease duration.
Windows 2003 DHCP-Server Beschreibung. 
Quelle: Determining Lease Duration https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc783573(v=ws.10)

Wenn der Pool an verfügbaren Leases aber stark geleert ist, dann schaltet DHCP auf 60Min Check herunter. Die Werte sind in der Registrierung anpassbar:

HKLM/System/CurrentControlSet/Services/DHCPServer/Parameters
  LeaseExtension:  xx MInuten
  DatabaseCleanupInterval : xx Minuten

Da würde ich aber erst einmal nichts dran ändern, sondern eher meine IP-Bereiche passend dimensionieren. Denken Sie einfach daran, dass eine einmal vergeben Adresse immer für die Dauer des Lease + 4 Stunden nicht an andere MAC-Adressen neu vergeben wird.

DNS TTL 

 10
15
20 Min

Der TTL des dynamischen Eintrag hat je nach Prozess einen unterschiedlichen Default TTL

  • 10 Min Netlogon-Service
  • 15 Min DHCP Client
  • 20 MIN DNS Server

Der TTL bestimmt, wie lange später die Antwort im Cache des anfragenen Clients vorgehalten wird. Nicht wie lange der Eintrag an sich gültig ist

Whenever a dynamic update client registers in DNS, the associated A and PTR RRs include the Time to Live (TTL), which by default is set to 10 minutes for records registered by the Net Logon service, and 15 minutes for records registered by the DHCP Client service. If the DNS Server service dynamically registers records for its own zones, the default TTL is 20 minutes. You can change the default setting in the registry. A small value causes cached entries to expire sooner, which increases DNS traffic but decreases the risk of cached records becoming outdated. Expiring entries quickly is useful for computers that frequently renew their DHCP leases. Long retention times are useful for computers that renew their DHCP leases infrequently.
Quelle: DNS Processes and Interactions https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197552(v=ws.10)#time-to-live 

DHCP Eventlog

Wenn Sie Fehler suchen, liefern sowohl DHCP-Server als auch DNS-Server einige Evenlogs und zusätzliche Textdateien. Hier eine Auswahl aus "Microsoft-Windows-DHCP Server Events/Admin"

Severity EventID Beispiel

Fehler

20322

Fehler bei der PTR-Eintragsregistrierung für IPv4-Adresse [[10.0.0.101]] und FQDN FC-VM-WIN11.forest3.msxfaq.de mit der Meldung 9005 (Der DNS-Vorgang wurde abgelehnt. ).

Fehler

20319

Fehler bei der Forward-Eintragsregistrierung für IPv4-Adresse [[10.0.0.101]] und FQDN FC-VM-WIN11.forest3.msxfaq.de mit der Meldung 9005 (Der DNS-Vorgang wurde abgelehnt.

DNS Eventlog

Auch der DNS-Server protokolliert sehr ausführlich die Änderungen. Allerdings müssen Sie hier genau hinschauen, denn es gibt zwei DNS-Server-Evenlogs:

Der oberste Eventlog protokolliert normale Aktivitäten des Diensts selbst, z.B.  

Eventid  Severity Meldung 

2 

Information

Der DNS-Server wurde gestartet.  

3 

Information 

Der DNS-Server wurde heruntergefahren.

4

Information 

Das Laden und Signieren von Zonen im Hintergrund ist abgeschlossen. Alle Zonen sind nun für DNS-Aktualisierungen und Zonenübertragungen verfügbar, sofern ihre jeweilige Konfiguration dies zulässt.

769 

Information 

Die Zone _msdcs.forest3.msxfaq.de aus der Datei NULL auf Server DC-FOREST3.forest3.msxfaq.de wurde vom DNS-Server geladen. [Virtualisierungsinstanz: .].

4013 

Warnung 

Der DNS-Server wartet darauf, dass von den Active Directory-Domänendiensten angezeigt wird, dass die Erstsynchronisierung des Verzeichnisses durchgeführt wurde. Der DNS-Serverdienst kann erst nach der Erstsynchronisierung gestartet werden, da wichtige DNS-Daten möglicherweise noch nicht auf diesen Domänencontroller repliziert wurden. Sofern die im Ereignisprotokoll der Active Directory-Domänendienste protokollierten Ereignisse deutlich machen, dass Probleme bei der DNS-Namensauflösung vorliegen, sollte ggf. die IP-Adresse eines weiteren DNS-Servers für diese Domäne der DNS-Serverliste in den Internetprotokolleigenschaften dieses Computers hinzugefügt werden. Dieses Ereignis wird alle zwei Minuten protokolliert, bis von den Active Directory-Domänendiensten angezeigt wird, dass die Erstsynchronisierung durchgeführt wurde.

5504

Information

Der DNS-Server hat einen ungültigen Domänennamen in einem Paket von 9.9.9.9 festgestellt. Das Paket wurde zurückgewiesen. Die Ereignisdaten enthalten das DNS-Paket.

 

Interessanter sind für die Fehlersuche aber auch Auditing die Events aus  "Microsoft-Windows-DNSServer/Audit"

Eventid  Severity Meldung 

514 

Information

Die Zone forest3.msxfaq.de wurde aktualisiert. Die Einstellung Aging wurde auf 1 festgelegt. [Virtualisierungsinstanz: .].

515 

Information

Ein Ressourceneintrag vom Typ 1, Name test.forest3.msxfaq.de, TTL 3600 und RDATA 0x0A00006F wurde im Bereich Default von Zone forest3.msxfaq.de erstellt. [Virtualisierungsinstanz: .].  

519

Information 

Ein Ressourceneintrag vom Typ "1", Name "dc-forest3", TTL "1200" und RDATA "0x0A000001" wurde erstellt in Bereich "Default" von Zone "forest3.msxfaq.de" über das dynamische Update von IP-Adresse "10.0.0.1".  

520

Information 

Ein Ressourceneintrag vom Typ "1", Name "dc-forest3" und RDATA "0x0A000001" wurde gelöscht aus Bereich "Default" von Zone "forest3.msxfaq.de" über das dynamische Update von IP-Adresse "10.0.0.1".  

541

Information

Die Einstellung "ScavengingInterval" im Bereich "." wurde auf "1" festgelegt.

550

Information 

Die In-Memory-Inhalte aller Zonen auf dem DNS-Server wurden in die jeweiligen Dateien geleert.  

552 

Information

Ein Aufräumzyklus für Ressourceneinträge wurde auf dem DNS-Server gestartet.

561

Information 

Die Daten für Zone forest3.msxfaq.de wurden erneut von Active Directory geladen. [Virtualisierungsinstanz: .].

Hier finden wir sowohl alle Konfigurationsänderungen als auch dynamischen Updates und Löschungen. Insofern eine sehr gute Quelle für ein Change Auditing.

dNSTombstoned am DNSnode im AD

Alle Zonen waren AD-Integriert und da habe ich natürlich auch einen Blick per ADSIEDIT darauf geworfen. Bei der Analyse ist mir aufgefallen, dass die DNS-Einträge im Active Directory nicht sofort gelöscht werden. Vergleichen Sie die beiden Bilder, die zur gleichen Zeit aufgenommen wurden.

Im DNS-Manager sehe ich neben dem DC nur noch den Host "NEDI". Mit ADSIEDIT sehe ich aber einige andere Hosts. Die Liste ist natürlich insgesamt schon noch etwas länger, da die Unterordner des DNS im AD nicht abgebildet wird.

Der Rechner "FC-VNM-WIN11" ist im AD noch vorhanden und wenn ich mir die Details anschaue, dann sehe ich ein Feld "dNSTombstoned = TRUE".

Achtung:
Ganz neue Objekte, die noch nicht veraltet waren, haben kein DNSTombstoned-Wert. Er ist daher "FALSE".

Für die verschiedenen Löschungen habe ich folgendes ermittelt. Ein Client registriert sich per DHCP.

Aktion  DHCP DNS AD
Client bekommt IP-Adresse per DHCP
DHCP-Server registrierte die DNS-Namen

Lease erscheint

 Namen erscheinen
Besitzer ist das DHCP-Dienstkonto		 Eintrag erscheint
dNSsTombstone=FALSE

Client deregistriert Adresse mit ipconfig /release

Lease wird gelöscht 

Name verschwindet

 Eintrag bleibt
dNSTombstone=TRUE

Admin löscht Lease im DHCP-Server

Lease verschwindet

Name bleibt erhalten 

 Eintrag bleibt
dNSsTombstone=FALSE 

Admin löscht DNS-Eintrag im DNS-Server

Lease bleibt 

Name wird gelöscht

 Eintrag bleibt
dNSTombstone=TRUE 

Admin löscht AD-Eintrag (unsupported)

Lease bleibt  

 Name bleibt erhalten.
Erst ein "Reload" der  Zone aktualisiert

Eintrag wurde gelöscht

Ich habe natürlich auch einmal versucht einen dNSTombstoned=TRUE auf dNSTombstoned=FALSE zu setzen aber auch durch einem Reload der Zone oder Neustart des Dienstes wurde der Eintrag nicht im DNS sichtbar. Ich vermute, dass die relevanten Daten im binären Feld "dnsRecord" codiert sind und dNSTombstone nur für Scavenging relevant ist.

DNS Scavenging

Im vorherigen Abschnitt habe ich munter gelöscht aber in einem Fall wurde der DNS-Eintrag mit "dNSTombstoned=TRUE" irgendwann gelöscht. Weder eine manuelle Löschung im DNS-Admin noch des Lease im DHCP-Server oder eine Deregistrierung durch den Client haben den Eintrag entfernt.

Wenn dem so ist, dann dürfte es ganz viele Domaincontroller mit ziemlich vielen alten Einträgen geben, die nie verschwinden, denn Scavenging ist normalerweise aus

Die Beschreibung von Microsoft zu Scavenging führt in der Einleitung alle Probleme auf.

With dynamic update, resource records are automatically added to zones when computers start on the network.
However, in some cases, they aren't automatically removed when computers leave the network.
If left unmanaged, the presence of stale resource records in zone data might cause some problems
- ...large number of stale resource records ...take up server disk space .. cause long zone transfers ...
- ...DNS servers with stale resource records might use outdated information to answer client queries,...
Quelle: DNS Aging and Scavenging in Windows Server https://learn.microsoft.com/en-us/windows-server/networking/dns/aging-scavenging

Die Lösung liefert Microsoft natürlich auch gleich mit (Auszüge)

- Time stamping ...for any resource records added dynamically to primary-type zones
- Scavenging for any resource records that persist beyond the specified refresh period.
- Servers can be configured to perform recurring scavenging operations automatically

Quelle: DNS Aging and Scavenging in Windows Server https://learn.microsoft.com/en-us/windows-server/networking/dns/aging-scavenging 

Eine Warnung platziert Microsoft. natürlich auch gleich noch dazu:

By default, the aging and scavenging mechanism for the DNS Server service is disabled. It should only be enabled when all parameters are fully understood. Otherwise, the server could be accidentally configured to delete records that shouldn't be deleted

Quelle: DNS Aging and Scavenging in Windows Server https://learn.microsoft.com/en-us/windows-server/networking/dns/aging-scavenging

Ich frage mich dann natürlich, warum Scavenging eine eigene Konfiguration ist und nicht auf der gleichen Karteikarte platziert wird, auf der ich dynamische Updates aktiviere.

Wir arbeiten erst einmal am Verstehen:

  • Timestamp ist nicht TTLs
    Der "Time to Live" an einem Eintrag teilt dem DNS-Server und Clients mit, wie lange Sie den Eintrag im Cache halten dürfen. Nach Ablauf der Zeit muss der Client den Namen neu anfragen. Das hat nichts damit zu tun, wie lange der Name an sich gültig ist. Der Timestamp wird auch nicht per DNS-Anfrage mit übermittelt, sondern ist eine interne Verwaltungsinformation der Windows DNS-Server.
  • Statische DNS Einträge haben keinen Timestamp und sind damit nie im Risiko.

Das steht so auch bei Microsoft:

Typically, only those resource records added dynamically using the DNS dynamic update protocol are subject to aging and scavenging.
Quelle: DNS Aging and Scavenging in Windows Server https://learn.microsoft.com/en-us/windows-server/networking/dns/aging-scavenging

  • DNS-Einträge von Clients mit statischer Adresse machen alle 24h einen Refresh
    Das gilt also auch für die MSDCS-Einträge von Domaincontrollern, die eine statische Adresse haben.

Das bedeutet aber auch, dass Sie den Timeout beim Scavenging nie auf weniger als 24h setzen sollten, da ansonsten die DCs zeitweise nicht mehr auffindbar sind.

  • Scavenging Dauer wird auf der Zone konfiguriert
    Hier stellen Sie ein, nach welcher Zeit ein Eintrag "verfallen" ist. Die Beschreibung finde ich unglücklich und vor allem dass beide Zeiten identisch sind.

    Das täuscht aber, denn die obere Zeit gibt an, wie lange die Verfallszeit von einem Client nicht mehr geändert werden darf. Damit möchte Microsoft verhindern, dass z.B. ein Client immer wieder seinen Eintrag neu aktualisiert und es zu exzessiven AD-Replikationen kommt. Die zweite Zeit startet erst dann, wenn das erste Intervall abgelaufen ist. Ein veralteter Eintrag würde also erst nach 14 Tagen Inaktivität komplett entfernt.

7+7 ist mir persönlich zu hoch aber unter 24h würde ich natürlich auch nicht gehen, damit meine Einträge für DCs und AD nicht verschwinden. Heute sind aber Bandbreiten und Server deutlich leistungsfähiger und ich könnte mir vorstellen, dass ein Eintrag z.B. zwischen 6-23 h aktualisiert und nach vielleicht 2-5 Tagen auch wieder gelöscht werden darf.
Sie können dies ja pro Subnetz einstellen und z.B. im Server-Netzwerk die 7+7 Tage belassen aber die Reverse Lookup-Zone für Clients deutlich flotter bereinigen.
Zumindest sollten Sie die Zeit mit der DHCP-Lease-Time abstimmen

Achtung
Wenn Sie die Zeiten reduzieren, dann denken Sie daran, dass bestehende Einträge vielleicht noch einen zu alten Timestamp haben, weil eine zwischenzeitliche Aktualisierung ja verboten war. Ich würde daher immer zumindest die 24h abwarten und danach die Timestamps prüfen, ehe ich den Aufräumprozess starte.

  • Scavenging muss auf dem Server aktiviert werden

    Angeblich braucht der Aufräumvorgang sehr lange und ist CPU-intensiv. Das kann in den Anfangsjahren von Windows 2000 und später noch ein Thema gewesen sein. Heute ist das wohl nur noch etwas für XXL-Firmen mit Tausenden von Einträgen. Sie können keinen genauen Zeitpunkt konfigurieren. Es ist der Abstand zwischen zwei Läufen, der zudem nie kürzer als 1h sein kann.

Scavenging period 
When automatic scavenging is enabled at the server, this period represents the time between repetitions of the automated scavenging process. The default value for this is seven days. To prevent deterioration of DNS server performance, the minimum allowed value for this is one hour.
 DNS Processes and Interactions https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197552(v=ws.10)#understanding-aging-and-scavenging

Wenn hier ein Leser Erfahrungswerte von sehr großen Umgebungen beisteuern kann, dann gerne per Mail an mich.

  • Manuell gesteuertes Aufräumen ist möglich

Ob und wie der DNS-Server ihre Befehle befolgt, können Sie wieder im DNS-Eventlog beobachten. 

Protokollname: Microsoft-Windows-DNSServer/Audit
Quelle:        Microsoft-Windows-DNSServer
Datum:         15.12.2025 00:21:53
Ereignis-ID:   552
Aufgabenkategorie:SERVER_OP
Ebene:         Informationen
Schlüsselwörter:(137438953472)
Benutzer:      FOREST3\Administrator
Computer:      DC-FOREST3.forest3.msxfaq.de
Beschreibung:
Ein Aufräumzyklus für Ressourceneinträge wurde auf dem DNS-Server gestartet.

Scavenging im Detail

Natürlich wollte ich schon genauer wissen, was Scavenging macht. Ich habe mir dazu einige DNS-Einträge anlegen lassen und verändert. Anhand der Tests mit einem Domain-Client als auch dem DHCP-Server als aktive Komponenten haben wir gesehen, dass Einträge in der DNS-Zone verschwinden aber im AD als LDAP-Objekt bestehen bleiben. Bislang habe ich aber immer gesehen, dass alle "überzähligen" Objekte ein "dNSTombstoned" haben. Wenn wir uns die Felder "whenCreated" und "whenChanged" anschauen, dann sehen wir, dass Objekte durchaus länger bestand haben. Als das Objekte im DNS noch vorhanden war, konnte ich mir den Timestamp anschauen.

Laut dem AD-Objekt wurde das Objekt aber schon am 3.12 angelegt und die letzte Änderung, vermutlich das Schreiben von dNSTombstoned ist 12.12 erfolgt.

 

So kommen doch einige Zeiten zusammen von denen die wichtigste, der "Resource Record Time Stamp" im Feld "dnsRecord" für die bereits als "dNSTombstone=TRUE" gekennzeichneten Fehler gar nicht einfach mehr ermittelt werden kann. Erschwerend bei einer Analyse kommt hinzu, dass die Zeiten und Intervalle natürlich in Stunden und nicht Minuten oder Sekunden gemessen werden. Die ganzen Testobjekte müssen erst einmal angelegt werden. Aber Microsoft hat in der Dokumentation das Verhalten durchaus beschrieben:

Record time stamp + No-refresh interval for zone + Refresh interval for zone
If the value of this sum is less than current server time, the record is deleted both from any zone data currently loaded in server memory and also from the applicable DnsZone object store in Active Directory for the directory-integrated “example.microsoft.com” zone.
Quelle: DNS Processes and Interactions https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197552(v=ws.10)#example-of-the-aging-and-scavenging-process-for-a-sample-record

Hier steht aber auch, dass der AD-Eintrag durch Scavenging mit entfernt wird.

  • Ein Eintrag wird angelegt und bekommt die aktuelle Zeit (abgerundet auf die Stunde) als Zeitstempel
  • In dem ersten Intervall kann ein Clients seine Daten natürlich aktualisieren und löschen aber der Zeitstempel bleibt unverändert.
  • Erst wenn das erste Zeitintervall abgelaufen ist, wird der Zeitstempel bei einem weiteren Update aktualisiert und das erste Intervall startet erneut
  • Wenn beide Intervalls abgelaufen sind, dann ist der Eintrag "löschbar"
  • Beim nächsten Scavenging-Lauf wird der Eintrag dann auch wirklich gelöscht

Bei der Standardeinstellung kann es also bis zu 21 Tage dauern.
7 Tage für das erste Intervall, in dem kein Client den Timestamp aktualisieren kann
+7 Tag für die Wartezeit, bis ein nicht weiter aktualisierter Eintrag veraltet ist
bis zu 7 Tage ist das Intervall des Scavenging-Prozess zum Start

Das sind natürlich sehr lange Zeiten

DNS Name Protection

Einen Punkt habe ich auf der Seite bislang ausgelassen. Sie können in der DHCP-Zone auch noch eine "Name Protection".

Die Funktion gibt es nur für Zonen mit der Einstellung "sicheren Updates" und bietet einen weiteren Schutz gegen Veränderungen von Einträgen. Der DHCP-Server addiert dazu einen weiteren DNS-Namen neben den eigentlichen A oder PTR-Record, welcher Informationen über den Client enthält. Stellen Sie sich mal folgendes vor:

  • Ein Client bekommt per DHCP eine Adresse und wird vom  DHCP-Server eingetragen
    Besitzer des DNS-Eintrags ist hier nicht der ClientComputer sondern das DHCP-Dienstkonto
  • Der Client meldet sich nicht mehr und der Lease verfällt
    Wir wissen nun, dass DHCP den Eintrag im DNS erst mit 4h Verzögerung löscht und selbst danach der Eintrag noch im AD als "dNSTombstoned=true" erhalten bleibt Berechtigt ist aber das DHCP-Konto
  • Ein anderer Client mit gleichem Namen fordert eine IP-Adresse an
    Der DHCP bestätigt diese und aktualisiert die DNS-Einträge, obwohl es ein ganz anderer Client ist.

Prozesse, die z.B. über Reverse-DNS zu einer IP-Adresse den Namen ermitteln, bekommen so falsche Daten. Das Verfahren wird auch "Name Squatting" genannt. Wenn der Client aber eine eindeutige ID mitsendet, die sonst niemand kennt und der DHCP-Server dieser "kryptisch" im DNS speichert, dann ist ein Fälschen zumindest deutlich erschwert. Wenn ich Name

In meinem Fall ist das "AAEBFAGXW8/8AmIAtv1HUPoPgyaVrgb/CYcpCRCgD9+z3qQ=" und wir sehen schon, dass hier was "Base64"-Codiert ist. Decodiert sind es 35 Bytes. Der Wert besteht aus einem Byte Optionen, der MAC-Adresse und dem FQDN, welche mit SHA265 verhashed und dann BASE64-codiert werden. Details zur Bildung dieser Zeichenkette finden sich in "RFC 4701 A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)" (https://www.rfc-editor.org/info/rfc4701)

Ein DHCP-Server kann so aber die meisten Versuche  erkennen, wenn ein anderer Client den gleichen Namen registrieren will

ACLs im AD

Wenn Sie DNS-Zonen im Active Directory ablegen und für sichere Updates konfigurieren, dann setzt der DNS-Dienste sowohl den Besitzer als auch die Rechte für das AD-Objekt auf das Konto, welches sich am DNS-Server authentifiziert hat. Das kann der Client-Computer sein, wenn er Mitglied der Domäne ist oder der DHCP-Server. Mögliche Konflikte habe ich direkt am Anfang schon beschrieben. So kann der DHCP-Server keine Einträge aktualisieren, wenn diese der Computer selbst angelegt hat.

Sie können diese Problem aber lösen, indem Sie dem DHCP-Dienstkonto einfach zusätzlich die Berechtigungen geben. Damit wird das Dienstkonto zwar kein Besitzer und die Berechtigungen des Computers sind nicht weg, aber der DHCP-Server kann zumindest die Updates vornehmen.

Gehen Sie dazu einfach im DNS-Manager auf die Eigenschaften der Zone und bearbeiten die die Berechtigungen. Dabei müssen Sie aber auf zwei Dinge achten.

  •  Per Default richtet die MMC das recht mit dem Scope „nur dieses Objekte“ ein
    Das hilft uns nicht weiter. Sie müssen den Scope auf „untergeordnete Objekte“ umstellen, damit das Recht auf die dnsNode-Einträge in der Zone wirken.
  • Ersetzt nicht das Computerrecht
    Das DHCP-Dienstkonto hat zwar nun das Recht die Einträge zu aktualisiere aber diese Konfiguration ändert nicht die ACLs. Das Computerkonto bleibt weiter der Besitzer und berechtigt. Sie können das Recht f+r das DHCP-Dienstkonto daher nicht wieder wegnehmen, sondern erst, wenn das Objekt per Tombstone gelöscht und komplett neu angelegt wurde.

So können Sie sehr schnell erreichen, dass der DHCP-Service seine Einträge immer schnell aktualisieren kann, auch wenn es bisher "Blockaden" durch Computer-ACEs gibt und noch nicht alle Computer per Gruppenrichtlinie o.ä. sich an die Vorgaben der RFC4702 halten.

Den Zustand könnten Sie sogar sehr lange betreiben. Das Problem ist eher, dass diese Einstellung schnell wieder in Vergessenheit Gerät und sie spätestens bei der Einrichtung einer neuen DNS-Zone die Anpassung vermutlich vergessen und das Problem wiederkehrt.

MSXFAQ Konfliktlösung

Mein Ziel sind akkurate Daten in meinem DNS. Ein Name eines Clients sollte möglichst schnell die richtige IP-Adresse liefern und auch ein Reverse-Lookup über die IP-Adresse sollte den richtigen Rechnernamen liefern. Leider ist genau das durch das Standardverhalten eines Windows Clients seit Version 8.1 nicht mehr sichergestellt, da der Client trotz anderer Anweisung durch den DHCP-Server weiterhin selbst seinen Namen registriert. Microsoft empfiehlt auch die Updates per DHCP-Server aber sagt hier nichts, wie dies auf den Clients unterbunden wird.

As a best practice, we should ensure that it is DHCP who should update both A and PTR records for all clients which are getting IP address from DHCP. To ensure that, please select this option: Always dynamically update DNS A and PTR records
Quelle: https://learn.microsoft.com/en-us/archive/technet-wiki/51810.windows-server-integration-between-dns-and-dhcp  

Kaum ein Kunde gibt sich damit zufrieden, wenn ich ihn bis zu 21 Tage vertröste. Eine radikale Reduzierung der Intervalle und Zeiten ist aber Risiko, da vielleicht zu schnell und zu viele Einträge gelöscht werden aber dennoch nicht alle Einträge, die mit falschen ACLs die Bereinigung behindern. Mit dem Wissen aus meiner Analyse habe ich mir folgendes überlegt.

  1. Löschen aller "dNSTombstoned=TRUE"-Einträge im AD und Reload des DNS-Servers
    Diese Einträge sind alle "verfallen" und wurden vom Client oder DHCP-Server gelöscht. Sicher mag eine spätere erneute Registrierung etwas mehr AD-Replikation und Last des DCs/DNS-Servers bedeuten, aber das ist ja eine einmalige Aktion.
  2. Anpassen der ACLs für aktive Einträge
    Die gültigen DNS-Records darf und will ich nicht löschen aber das DHCP-Dienstkonto muss diese Einträge verwalten können, wenn die Clients selbst es nicht mehr können. Daher möchte ich als DNS-Einträge im AD durchlaufen und wenn ein Computerkonto der Besitzer ist, dann ändere ich den Besitzer als Administrator auf das DHCP-Dienstkonto und addiere das Konto in die Berechtigungen.
    Damit kann der DHCP-Server den Eintrag überschreiben und löschen.

Als Ergebnis sollten wir in kurzer Zeit einen aktuellen DNS-Datenbestand haben, der alleine durch den DHCP-Server verwaltet werden kann. Hier ein Vorschlag, wie Sie dieses Ziel erreichen können:

Aktion  Erledigt

Dienstkonto für DHCP-Server anlegen

Legen sie ein Dienstkonto für die zukünftigen Updates an und addieren Sie es in die Gruppe "DNSUpdateProxy" und konfigurieren Sie es bei allen DHCP-Servern, damit alle Updates durch die DHCP-Server immer das gleiche Konto nutzen. Damit konfiguriert der DHCP-Server neue Einträge, bei denen er schneller als ein neuer Client ist, gleich richtig. 

   

Einträge mit dNSTombstoned=TRUE entfernen

Diese Einträge sind allesamt schon nicht mehr in Verwendung aber wenn Sie durch einen Computer angelegt wurden, dann verhindern sie die geplante Aktualisierung durch das DHCP-Dienstkonto. Das Löschen ist recht einfach möglich, wenn gleich direkte Änderungen im AD immer etwas mit Vorsicht vorzunehmen sind.

Get-DNSServerZone `
| where {$_.IsDsIntegrated} `
| ForEach {
   Write-Host "Checking $($_.DistinguishedName)"
   Get-ADObject `
      -LDAPFilter "(&(objectclass=dnsnode)(dNSTombstoned=TRUE))" `
      -Properties dnstombstoned,name `
      -SearchBase ($_.DistinguishedName) `
   | Remove-ADObject
}

Das Commandlet Get-DNSServerRessourceRecord ist nicht auf dNSTombstoned-Objekte anwendbar. Sie werden einfach nicht gefunden.

   

Anpassen der ACLs

Nun müssen wir auf die bestehenden Objekte, auf denen aktuell nur der Client-Computer selbst berechtigt ist, das DHCP-Dienstkonto berechtigen. Dazu gibt es zwei Wege:

  • Alle Objekte per LDAP durchlaufen  und ACLs anpassen
    Das ist per PowerShell durchaus mal schnell gemacht und ist "Beständig"
  • Dem DHCP-Dienstkonto die Rechte auf den Zonen geben
    Sie können einfach auf der Zone die Berechtigungen für untergeordnete Objekte geben. Damit kann DHCP die Einträge aktualisieren aber er änder nicht die Berechtigungen. Sie sollten die Berechtigungen nicht wieder entfernen und gut dokumentieren.

Beide Verfahren eigenen sich auch für "dNSTombstoned=True"-Objekte, aber diese würde ich sowieso erst einmal entfernen, wenn dies nicht durch Scavenging erfolgt ist.. Alle anderen Objekte, die noch nicht dNSTombstoned sind, können mit Get-DNSServerRessourceRecord abgerufen werden. So kann ein Script auch dem Timestamp ermitteln und damit mehr Details erhalten, ehe ich Rechte verändere.

$serviceaccount = "forest3\dnsupdater"

Get-DNSServerZone `
| where {$_.IsDsIntegrated} `
| Foreach {
   Write-Host "Checking $($_.Zonename)"
   Get-DNSServerResourceRecord `
      -ZoneName $_.Zonename `
   | Foreach {
        #
        # hier muss dann der Code zum Addieren der die ACL-Logik addiert werden
        # Ein passendes Skript habe ich schon fertig aber noch nicht ausreichend getestet
        #
     }
}

Durch die Erweiterung um das Dienstkonto kann der DHCP-Server auch die Einträge pflegen, die ursprünglich vom Client selbst erfolgt sind. Das Computerkonto wurde aber nicht aus den ACLs entfernt. Das könnten Sie später noch einmal angehen.

Tipp: Wenn Sie nicht die Rechte pro Eintrag addieren wollen, dann können Sie dem DHCP-Dienstkonto natürlich auch einfach die Berechtigungen auf den einzelnen Zonen geben. Das birgt natürlich etwas das Risiko, dass das Dienstkonto zu viele Berechtigungen hat und im Fehlerfall oder bei Kompromittierung auch andere DNS-Einträge verändert, die er nicht erreichen sollte.

   

Clients RFC4702-konformes Verhalten beibringen

Nun sollten wir alle Clients dazu bringen, sich RFC4702-konform zu verhalten und einfach den DHCP-Anweisungen zu folgen und keine eigenen DNS-Einträge mehr vorzunehmen. Wir können es leider auf dem DNS-Server nicht einfach zentral verbieten. Ich hatte versucht, z.B. der Gruppe "Domain Computer" ein DENY auf die Zone zu geben oder "Authenticated Users" zu entfernen. Beides hat nicht geholfen, da der DNS-Server die Eintragungen "im Auftrag des Clients" macht.

Ich rate dazu, diese Einstellungen über eine Gruppenrichtlinie zu setzen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
"RegistrationOverwrite"=dword:000"RegistrationOverwrite"=dword:00000002

Danach wertet der Client die Antwort des DHCP-Servers korrekt aus und versucht keine eigene Registrierung.

   

DNS-Server: Alle Zonen auf "Secure Updates Only" stellen

Nachdem die Clients keine eigenen Updates mehr machen und das DHCP-Dienstkonto die Berechtigungen hat, stellen wir die Zonen auf "Secure Updates Only" um, damit kein anonymer Client mehr eigene Einträge vornimmt, die eine Verwaltung durch den DHCP-Server unterbinden.

  

DNS Scavenging aktivieren

Die durchgeführten Einstellungen sollten verhindern, dass es falsche DNS-Einträge durch DHCP und Clients gibt. Aber ohne Scavenging werden sie immer mehr DNSnode-Objekte im Active Directory haben, die vielleicht niemand mehr braucht. Das Aufräumen ist nun aber nicht mehr so kritisch, da wir diese Funktion nicht zum Beseitigen von falsche berechtigten Einträgen benötigen. Dennoch kann der DNS-Server gerne einmal am Tag die Einträge entfernen, die schon viele Tage kein Update mehr erhalten haben.

   

Monitoring

Auch wenn sie nun alle Einstellungen vorgenommen haben, kann es immer noch Clients geben, die z.B. die Gruppenrichtlinie noch nicht umgesetzt haben. Eine Überwachung der Eventlogs und ggfls. eine Auswertung der DNS-Einträge auf Unstimmigkeiten kann die Zuverlässigkeit der DNS-Dienste verbessern und vielleicht weitere Unstimmigkeiten aufdecken.

   

Nacharbeiten

Wenn ihr System wieder sauber läuft, gibt es immer noch die Berechtigungen der Computer auf Einträgen, die seit dem nie komplett gelöscht wurden. Per Skripte könnten Sie diese ACes auch bereinigen.

   

Weitere Links