DNS & Namensauflösung: das Fundament, auf dem AD Dienste findet — Zonen, DC-Locator, Forwarding und Angriffsfläche
Einführung · 8 Abschnitte · ~8 Min Lesezeit · Stand
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.
Kurzcheck
Warum ist die AD-integrierte Zone die Standardwahl für die Domänen-Zone — und was schaltet erst sie frei?
- Sie repliziert Multi-Master über AD und ist Voraussetzung für Secure Dynamic Updates.
- Sie ist die einzige Zonenart, die überhaupt SRV-Records speichern kann.
- Sie braucht keine Domain Controller und läuft auf jedem Mitgliedsserver.
Genau. Multi-Master-Schreibfähigkeit und ACL-geschützte dynamische Updates gibt es nur AD-integriert — eine datei-basierte Primary hat genau eine beschreibbare Kopie und kennt keine sicheren Updates.
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. |
Kurzcheck
Du sollst eine Partnerfirma-Domäne auflösen. Deren DNS-Server-IPs sind stabil, einen Zonentransfer erlauben sie nicht. Was passt?
- Ein Conditional Forwarder für die Partnerdomäne auf deren feste DNS-Server-IPs.
- Eine Delegation für die Partnerdomäne in deiner Zone anlegen.
- Einen unbedingten Forwarder auf die Partner-DNS-Server setzen.
Richtig. Der Conditional Forwarder leitet gezielt nur diese eine Domäne weiter und braucht keinen Zonentransfer — genau der Fall bei stabilen Ziel-Servern ohne Transfer-Erlaubnis.
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 einenwpad-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), diewpadundisatapper 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.
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).