DNS unter Windows

In der Domäne ist DNS fast immer AD-integriert auf den Domain Controllern. Zonen liegen als Objekte, Replikation folgt AD. Ein zweiter DC ohne DNS-Rolle macht Clients bei Ausfall des ersten namensblind, auch wenn Kerberos „irgendwie“ noch da ist.

Was du anfasst

• Forward-Lookup-Zone der AD-Domäne, dynamische Updates sicher (nur AD-Mitglieder).
• Reverse-Zone, sonst bleiben PTR leer und manche Dienste meckern.
• Conditional Forwarder: die Zone des Partners geht an dessen Server, nicht ins Internet.
• Root-Hints vs. Forwarder nach außen. Ein Forwarder zu 8.8.8.8 umgeht interne Politik – begründen.
• Scavenging: veraltete dynamische Records, sonst gewinnt ein totes Notebook den Namen.

Resolve-DnsName intranet.firma.example
Resolve-DnsName 10.20.30.10 -NameServer 10.20.30.10
Get-DnsServerZone
Get-DnsServerResourceRecord -ZoneName firma.example -Name www
Clear-DnsClientCache
ipconfig /displaydns

Client Windows

Der DNS-Client-Cache lügt länger als dein Gefühl. Nach Zonenänderung zuerst Cache leeren, dann gegen den Server direkt auflösen, dann gegen den Client. nslookup ohne Serverangabe nutzt den konfigurierten Resolver und mischt den lokalen Cache nicht immer so, wie du denkst – Resolve-DnsName ist ehrlicher.

• Registerkarte Adapter: DNS-Server falsch, Suffix falsch, „Register in DNS“ aus bei einem Server der sich registrieren muss.
• GPO verteilt den falschen Resolver an eine OU.
• IPv6-Resolver ::1 oder ein totes fd00, Windows fragt AAAA zuerst und du suchst in A.
• Zeit falsch: dynamisches Update und Kerberos sterben gemeinsam.