DNS & Namensauflösung

Warum DNS das Fundament von AD ist

Active Directory findet seine Dienste nicht über feste IP-Adressen, sondern über DNS. Ein Client, der sich anmelden will, fragt DNS nicht nach einer Adresse, sondern nach einem Dienst: „Wer ist hier ein Domain Controller für corp.example.com — am besten in meinem Standort?“ Diese Frage beantworten spezielle `SRV`-Records (Service-Location-Records).

Damit ist DNS keine Nebensache, sondern die Verzeichnis-Landkarte von AD: Anmeldung, GPO-Verarbeitung, Replikation zwischen DCs, Group-Policy und Zertifikatsdienste hängen alle daran, dass die richtigen Records da sind und die Clients den richtigen DNS-Server befragen. Fällt DNS falsch aus, fühlt sich das an wie ein AD-Ausfall — obwohl AD selbst gesund ist.

Zonen: AD-integriert oder datei-basiert — und wie weit sie replizieren

Eine Zone ist der Teil des Namensraums, für den ein DNS-Server autoritativ ist — also die verbindliche Quelle. Für die AD-Zone gibt es zwei Speicherarten, und die Wahl entscheidet über Replikation, Sicherheit und Betrieb:

AD-integrierte Zone

Die Zonendaten liegen in Active Directory und replizieren über die AD-Replikation — Multi-Master: jeder DNS-DC kann Records schreiben. Voraussetzung für Secure Dynamic Updates (ACL-geschützt). Für die AD-eigenen Zonen der Standard.

Datei-basierte Zone (Standard-Primary/Secondary)

Klassisches DNS: eine beschreibbare Primary-Kopie, weitere Server sind Secondaries, die per Zonentransfer eine Nur-Lese-Kopie ziehen. Single-Master, keine Secure Dynamic Updates. Sinnvoll dort, wo kein DC steht (z. B. eine DMZ-Zone).

Bei einer AD-integrierten Zone wählst du zusätzlich den Replikationsumfang — auf welche Server die Zone verteilt wird. Das steuert, wer die Records lokal beantworten kann:

• Alle DNS-Server der Domäne (Anwendungspartition DomainDnsZones): der Normalfall für die Zone einer Domäne.
• Alle DNS-Server der Gesamtstruktur (Anwendungspartition ForestDnsZones): für Zonen, die jede Domäne im Forest auflösen können muss — die _msdcs.<Forest-Root>-Zone repliziert per Default forest-weit.
• Alle Domain Controller der Domäne (Legacy, in der Domänenpartition): nur für Kompatibilität mit sehr alten DCs, die keine Anwendungspartitionen kennen — verteilt die Zone auch an DCs, die gar kein DNS betreiben.

DC-Locator: wie ein Client den richtigen DC findet

Der Mechanismus dahinter heißt DC-Locator. Der Client fragt DNS nach SRV-Records für den gesuchten Dienst (z. B. LDAP/Kerberos) unter Namen wie _ldap._tcp.dc._msdcs.<domäne>. Die Antwort ist eine Liste von DCs mit Priorität und Gewicht — so verteilt sich Last, und Ausweichkandidaten stehen bereit.

Die Zone `_msdcs.<Forest-Root>` ist dabei das Herzstück: Sie enthält die dienst- und standortbezogenen Locator-Records und die GUID-basierten CNAMEs, über die DCs ihre Replikationspartner finden. Weil sie forest-weit gebraucht wird, repliziert sie per Default forest-weit.

Entscheidend ist die Standort-Bewusstheit (Site-Awareness): AD registriert zusätzlich standortspezifische SRV-Records unter _sites. Ein Client bestimmt seinen eigenen Standort daran, dass seine IP in ein Subnetz-Objekt fällt, das in „Active Directory-Standorte und -Dienste“ einem Site zugeordnet ist. Passt keine Subnetz-Definition, kennt der Client seinen Standort nicht — und landet potenziell bei einem beliebigen, weit entfernten DC über die WAN-Strecke.

Dynamische Updates: wer darf Records schreiben?

Domänen-Mitglieder registrieren ihre eigenen A- (und oft PTR-)Records selbst per Dynamic DNS. Das hält die Zone ohne Handarbeit aktuell — bei DHCP-Adressen ändert sich die IP eines Hosts ja regelmäßig. Manuell gepflegte Records für Flottenrechner sind der Anti-Pattern: Sie veralten sofort.

Die Sicherheitsfrage lautet: Wer darf schreiben? Dafür gibt es drei Modi:

Keine dynamischen Updates

Nur manuelle Records. Sicher, aber unpraktikabel für Client-Flotten.

Unsicher und sicher (nonsecure)

Jeder kann Records anlegen und ändern — auch nicht authentifiziert. Ein offenes Scheunentor: fremde Hosts können Einträge überschreiben. Auf AD-Zonen nicht akzeptabel.

Nur sicher (secure only)

Nur AD-integriert verfügbar. Der Ersteller eines Records wird sein Eigentümer (per ACL) und darf ihn fortan ändern; andere nicht. Der Pflichtmodus für AD-Zonen.

Registriert ein DHCP-Server Records stellvertretend für Clients, wird der DHCP-Server zum Eigentümer — und andere (etwa ein zweiter DHCP-Server oder der Client selbst) können den Record dann nicht mehr aktualisieren. Die saubere Lösung ist ein dediziertes DHCP-DNS-Konto (ein niedrig privilegiertes Dienstkonto), unter dem alle DHCP-Server einheitlich registrieren. Die Alt-Gruppe `DnsUpdateProxy` löst zwar das Eigentümerproblem, hinterlässt die Records aber ohne schützende ACL — sie ist selbst eine Schwachstelle und kein Ziel-Design.

Nach außen auflösen: Forwarder, Conditional Forwarder, Stub, Delegation

Ein interner DNS-Server ist autoritativ nur für seine Zonen. Alles andere — das Internet, Partnerdomänen, andere Forests — muss er anders auflösen. Vier Werkzeuge, oft verwechselt:

Forwarder (unbedingt)

Leitet alle nicht lokal auflösbaren Anfragen an einen festen Upstream-Resolver (z. B. den des Providers). Alternativ ohne Forwarder: Root Hints — der Server rekursiert selbst ab den Root-Servern. Zweck: Internet-Auflösung.

Conditional Forwarder

Leitet nur Anfragen für eine bestimmte Domäne an feste Ziel-Server. Ideal, um eine Partner-/Fusionsdomäne aufzulösen, ohne Zonentransfer. Nachteil: die Ziel-IPs sind statisch gepflegt — ändern sich die Namensserver der Gegenseite, bricht es.

Stub-Zone

Eine automatisch aktuell gehaltene Mini-Kopie einer Zone — nur NS/SOA (plus Glue). Der Server lernt daraus die autoritativen Namensserver der Zielzone und fragt sie direkt. Vorteil gegenüber dem Conditional Forwarder: die NS-Liste aktualisiert sich selbst, wenn sich die Gegenseite ändert.

Delegation

Innerhalb deines eigenen Namensraums: die Elternzone übergibt einen Teilbereich (Subdomäne) per NS-Records an andere Namensserver. Kein Werkzeug für fremde Namensräume — dort bist du nicht autoritativ.

Split-Brain: ein Name, zwei Welten

Viele Organisationen nutzen denselben Namen innen und außen — corp.example.com ist die AD-Domäne und die öffentliche Web-Präsenz. Das ist Split-Brain-DNS (Split-DNS): Es gibt zwei völlig getrennte Zonen gleichen Namens — eine interne (autoritativ auf den DCs, mit den internen Records) und eine externe (beim öffentlichen Provider, mit www, mx usw.).

Der klassische Stolperstein folgt aus Autorität: Der interne DNS-Server ist für corp.example.com autoritativ und leitet für diese Zone nichts nach außen weiter. Fragt ein interner Client nach www.corp.example.com und dieser Record steht nur in der externen Zone, bekommt er NXDOMAIN — obwohl der Name „im Internet“ existiert. Konsequenz: Jeder extern gehostete Name, den interne Clients brauchen, muss manuell auch in die interne Zone gepflegt werden.

DNS als Angriffsfläche: ADIDNS, WPAD, Spoofing

Weil AD sich auf DNS-Antworten verlässt, ist DNS auch ein Angriffsziel. Drei Muster, die du als Prinzip kennen solltest:

• ADIDNS-Missbrauch: Der oben erklärte Default — jedes authentifizierte Konto darf neue Records anlegen — erlaubt einem Angreifer, eigene Einträge in die AD-Zone zu schreiben. Besonders wirksam ist ein Wildcard-Record (`*`): Er beantwortet Anfragen nach Namen, die sonst nicht existieren — der Angreifer fängt so Namensauflösung ab und lenkt Verbindungen auf sein System.
• WPAD-Vergiftung: Clients suchen per Web Proxy Auto-Discovery nach einem Host wpad. Wer einen wpad-Record fälscht, unterschiebt eine Proxy-Konfiguration und liest/manipuliert Web-Verkehr (Man-in-the-Middle). Der Windows-DNS-Server hat dagegen die Global Query Block List (GQBL), die wpad und isatap per Default nicht beantwortet — selbst wenn ein Record existiert.
• Spoofing/Poisoning allgemein: Wer gefälschte Antworten unterschiebt oder Records überschreibt, lenkt Clients auf falsche Ziele. Die Gegenwehr ist Prinzip, nicht Produkt: sichere Updates, minimale Schreibrechte, Monitoring auffälliger Record-Änderungen und die schützenden Defaults nicht leichtfertig abschalten.

Aging und Scavenging: das Aufräumen, das zu viel aufräumt

Dynamische Registrierung füllt die Zone von allein — sie leert sie aber nicht. Ein Notebook, das ausgemustert wird, hinterlässt seinen A-Record auf unbestimmte Zeit. Über Jahre sammeln sich so tote Einträge, die auf inzwischen anderweitig vergebene Adressen zeigen. Dagegen gibt es Aging und Scavenging: Records bekommen einen Zeitstempel, und wer sich zu lange nicht meldet, wird gelöscht.

Gesteuert wird das über zwei Intervalle, die hintereinander laufen und beide standardmäßig sieben Tage betragen:

No-Refresh-Intervall

Nach einer Aktualisierung unterdrückt der Server weitere Zeitstempel-Aktualisierungen. Absicht laut Dokumentation: unnötige AD-Replikation zu vermeiden, denn jede Zeitstempel-Änderung wäre eine Verzeichnisänderung.

Refresh-Intervall

Danach werden Aktualisierungen wieder angenommen. Meldet sich der Eigentümer in dieser Zeit, beginnt der Zyklus von vorn.

Scavenging-Lauf

Erst wenn beide Intervalle seit dem Zeitstempel abgelaufen sind, gilt ein Record als veraltet. Der automatische Lauf prüft das standardmäßig einmal täglich, frühestens stündlich.

Wenn Records fehlen: Registrierung erzwingen und prüfen

Fehlt ein SRV-Record eines Domain Controllers, ist das selten ein DNS-Fehler im engeren Sinn — meistens hat der DC seine Registrierung nicht durchgebracht oder etwas hat sie entfernt. Die Reihenfolge der Prüfung folgt der Frage, wo der Bruch liegt: beim Registrierenden, beim Server oder beim Fragenden.

Durchgerechnet: „Anmeldung dauert plötzlich zwei Minuten“

Zusammenfassung — gleich im Check

Die Achsen dieses Moduls: Zonen-Speicherart (AD-integriert vs. datei-basiert) und Replikationsumfang; der DC-Locator mit SRV, _msdcs und Standort-Bewusstheit; dynamische Updates (secure only, Eigentümerschaft, DHCP); die vier Forwarding-Werkzeuge Forwarder / Conditional Forwarder / Stub / Delegation; Split-Brain-DNS; und DNS als Angriffsfläche (ADIDNS-Wildcard, WPAD/GQBL, Spoofing als Prinzip).