Das lernst du
- Zuständigkeiten für A- und PTR-Updates festlegen.
- Berechtigungs-, Besitz- und Alterungsprobleme diagnostizieren.
Voraussetzungen: G03 · Parameter und ihre AuswirkungenF07 · Reservierungen und ClientidentitätE04 · Hochverfügbarkeit und Failover
DHCP und DNS sind unterschiedliche Dienste, können aber zusammenarbeiten. Die Vergabe einer Adresse erzeugt nicht automatisch überall einen korrekten DNS-Eintrag.
- Dynamisches DNS-Update
- Ein autorisierter Client oder Dienst ändert DNS-Datensätze im Betrieb. DHCP kann solche Änderungen veranlassen; die erfolgreiche Leasevergabe beweist noch kein erfolgreiches Update.
Ein Name, zwei DNS-Richtungen
Grafik vergrößern
Name, Adresse und Zuständigkeit
Ein A-Eintrag ordnet einem Namen eine IPv4-Adresse zu; ein PTR-Eintrag unterstützt die Rückwärtsauflösung. Client und Server können die Updatezuständigkeit unter anderem über die Client-FQDN-Option abstimmen. Vorhandene Namen, Zonenberechtigungen und lokale Produktregeln beeinflussen das Ergebnis.
In einer AD-integrierten Windows-DNS-Zone können sichere Updates und der Besitzer eines Eintrags entscheiden, wer ihn ändern darf. Ein DHCP-Dienst mit ungeeigneten Anmeldedaten kann eine Lease vergeben, aber den DNS-Datensatz nicht aktualisieren. Das ist kein Grund, den gültigen Pool neu zu erstellen.
Partner, Migration und veraltete Daten
Bei Failover sollten Partner eine konsistente Updateberechtigung besitzen. Unterschiedliche Identitäten können dazu führen, dass ein Partner die Einträge des anderen nicht ändern darf. Gemeinsame, bewusst verwaltete Updatecredentials und geeignete Zonenregeln verhindern solche Besitzkonflikte besser als pauschal unsichere Updates.
Kea trennt die DHCP-Vergabe von D2, dem DHCP-DDNS-Dienst. Dort werden Änderungsanfragen zu DNS-Updates verarbeitet. DHCP-, D2- und DNS-Logs müssen gemeinsam betrachtet werden. Alterung/Scavenging und Lease-Ablauf sind verwandte Betriebsprozesse, aber nicht derselbe Timer.
A- und PTR-Datensätze getrennt prüfen
Ein A-Datensatz ordnet einem Namen eine IPv4-Adresse zu, ein PTR-Datensatz dient der Rückwärtsauflösung einer Adresse zu einem Namen. Eine korrekte Vorwärtsauflösung beweist daher noch keine passende Rückwärtszone. DHCP-gestützte Updates können je nach Konfiguration unterschiedliche Zuständigkeiten für diese Datensätze vorsehen. Option 81 liefert Kontext zur Abstimmung, ersetzt aber keine Berechtigung im DNS-Dienst.
Bei Nordlicht erhält pc01 die .10.120. Prüfe zuerst das bestätigte Lease, dann den A-Datensatz für pc01.nordlicht.test und gesondert den PTR für die Adresse. Wenn nur der PTR fehlt, ist eine völlig neue DHCP-Vergabe kein gezielter Lösungsansatz. Untersuche vielmehr Zuständigkeit, Zonenkonfiguration und Updateberechtigungen für genau den fehlenden Datensatz.
Lebensdauern und Berechtigungen verursachen verzögerte Fehler
DNS-Caches halten Antworten entsprechend ihrer TTL vor. Ein erfolgreiches Update am autoritativen Server muss deshalb nicht sofort in jedem zuvor befragten Cache sichtbar sein. Umgekehrt kann ein alter DNS-Eintrag länger bestehen als die dazugehörige Lease. Lease-Dauer und DNS-TTL sind verschiedene Zeitgrößen und müssen als solche gemessen werden.
Bei einem Serverwechsel können zudem andere Anmeldeinformationen oder Datensatzbesitzer relevant werden. Dann funktioniert die Adressvergabe weiter, während Updates scheitern. Vergleiche Updateprotokolle, Berechtigungen und direkte DNS-Abfragen statt lediglich den DHCP-Dienst neu zu starten. Die Abnahme umfasst Neuanlage, Änderung und berechtigtes Entfernen beziehungsweise Altern veralteter Daten, jeweils mit nachvollziehbarer Zuständigkeit.
Lease korrekt, DNS zeigt alte Adresse
- PC07 erhält .10.121. /all und Serverlease stimmen. DNS A-Eintrag pc07.nordlicht.test zeigt weiterhin .10.120.
- Zeitpunkt, Client-FQDN und Updatezuständigkeit ermitteln. DHCP-/DNS-Logs zeigen abgelehnte Änderung aufgrund des Eintragsbesitzers nach einer Migration.
- Im isolierten Labor Berechtigung bzw. Updateidentität gezielt korrigieren; A und PTR prüfen. Nicht als erste Maßnahme die gesamte Zone unsicher machen.
- Erneut einen kontrollierten Adresswechsel durchführen. Prüfen, dass neue Werte geschrieben und alte Zuordnungen nach dem vorgesehenen Verfahren entfernt werden.
Ergebnis: Ein vollständiger Betriebsnachweis verknüpft Lease, Vorwärtsauflösung, Rückwärtsauflösung und die autorisierte Updateidentität.
Typische Fehler
- A und PTR können unabhängig fehlerhaft sein.
- Lease-Ablauf löscht nicht in jeder Konfiguration sofort jeden DNS-Eintrag.
- Zwei Failoverpartner können trotz synchronisierter Leases unterschiedliche DNS-Berechtigungen haben.
Praktisch anwenden
Offizielle Quellen
Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.
- RFC 4702 · Client FQDN Option ↗Option 81, Zuständigkeit für DNS-Updates; Oktober 2006
- Microsoft · Dynamische DNS-Updates ↗Windows Server; sichere Updates in AD-integrierten Zonen
- ISC · DHCP-DDNS (D2) ↗Kea 3.0.2
- Microsoft · DHCP-Failover ↗Windows Server 2025; DHCPv4, nicht DHCPv6