# DNS & Namensauflösung > DNS als Fundament von Active Directory verstehen und sicher betreiben: AD-integrierte vs. datei-basierte Zonen und ihr Replikationsumfang, wie Clients über SRV-Records und `_msdcs` standortbewusst einen DC finden, Forwarder gegen Conditional Forwarder gegen Stub-Zone gegen Delegation, Split-Brain-DNS, sichere dynamische Updates und DNS als Angriffsfläche (ADIDNS, WPAD, Spoofing als Prinzip). Track: [Active Directory](https://physar.tech/learn/active-directory) Kanonische Fassung: https://physar.tech/learn/active-directory/dns Stand: 2026-07-27 Interaktiver Teil: 14 Checks (nur im Browser) ## DNS & Namensauflösung: das Fundament, auf dem AD Dienste findet — Zonen, DC-Locator, Forwarding und Angriffsfläche ### 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. > **Merksatz:** AD lokalisiert Dienste, es adressiert sie nicht. Fast jede „AD ist langsam / DC nicht erreichbar“-Störung ist zuerst eine **DNS-Frage**: Fragt der Client den richtigen Server, und stehen die richtigen `SRV`-Records drin? ### 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.`-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? - [x] 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.`. Die Antwort ist eine Liste von DCs mit **Priorität** und **Gewicht** — so verteilt sich Last, und Ausweichkandidaten stehen bereit. Die Zone **`_msdcs.`** 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. > **Betriebssignal:** Trifft ein DC Anmeldungen von IPs, die keinem Subnetz/Standort zugeordnet sind, protokolliert der **Netlogon-Dienst Event 5807** und sammelt die betroffenen IPs in der `netlogon.log` unter `NO_CLIENT_SITE:`. Die Abhilfe ist nicht am DC, sondern in der **Standort-Topologie**: das fehlende Subnetz anlegen und einem Standort zuordnen. ### 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. | > **Feinheit mit Folgen:** „Nur sicher“ heißt **authentifiziert**, nicht **privilegiert**: Per Default darf **jedes** authentifizierte Konto **neue, noch nicht existierende** Records anlegen (nur fremde ändern nicht). Genau diese Erlaubnis ist später die Wurzel der ADIDNS-Angriffsfläche. 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. | > **Entscheidungshilfe:** **Internet** → Forwarder/Root Hints. **Fremde Domäne, stabile Server, kein Transfer möglich** → Conditional Forwarder. **Fremde Domäne, deren Namensserver sich oft ändern** → Stub-Zone (trackt NS automatisch). **Eigene Subdomäne abgeben** → Delegation. **Kurzcheck:** Du sollst eine Partnerfirma-Domäne auflösen. Deren DNS-Server-IPs sind stabil, einen Zonentransfer erlauben sie nicht. Was passt? - [x] 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. > **Prinzip:** Autorität kennt kein „fällt sonst nach außen durch“. Wer intern autoritativ für eine Zone ist, muss **jeden** dort benötigten Record selbst führen — Split-Brain tauscht Namensklarheit gegen laufende Doppelpflege. ### 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**. > **Gefährliche Feinheit:** Die GQBL entfernt `wpad`/`isatap` beim **ersten Start** aus der Sperrliste, wenn diese Namen **bereits als Record** in einer Zone stehen. Ein vorhandener (womöglich untergeschobener) `wpad`-Record wird dann **beantwortet** statt blockiert. Deshalb: GQBL aktiv und gefüllt halten, WPAD auf Clients bewusst abschalten, und keine ungewollten `wpad`-Records dulden. ### 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). > **Gleich im Check:** Du entscheidest für konkrete Situationen die beste Konfiguration oder Diagnose — und in einer Trace-Mission markierst du im Ablauf einer langsamen Anmeldung die Stelle, an der der DC-Locator die falsche Grenze überschreitet, und wählst die Abhilfe. Pro Option siehst du, warum sie die Wurzel trifft oder aus welchem benannten Grund sie nur ein Symptom kuriert. ## Quellen - Microsoft Learn — How DNS support for Active Directory works (SRV-Records, DC-Locator, _msdcs) - Microsoft Learn — Understanding Active Directory Domain Services integration / DNS zone replication scope (DomainDnsZones, ForestDnsZones) - Microsoft Learn — Understanding dynamic update (secure vs. nonsecure) und DnsUpdateProxy - Microsoft Learn — DNS Server Global Query Block List (wpad/isatap Defaults) - SpecterOps / Kevin Robertson — ADIDNS: Abusing Active Directory-Integrated DNS (Wildcard-Record, WPAD-Spoofing) - Microsoft Learn — Netlogon Event 5807 / NO_CLIENT_SITE (fehlende Subnetz-zu-Site-Zuordnung) - Microsoft Learn — Understanding Active Directory Domain Services integration (AD-integrierte Zonen, Multi-Master) - Microsoft Learn — Understanding dynamic update (Secure Dynamic Updates nur AD-integriert) - Microsoft Learn — Understanding dynamic update (Clients registrieren A/PTR selbst) - Microsoft Learn — DNS record management and DHCP integration (Client- vs. manuelle Registrierung) - Microsoft Learn — Active Directory domain controller location and site/subnet configuration - Microsoft Learn — How DNS support for Active Directory works (SRV records and Netlogon registration) - Microsoft Learn — DNS conditional forwarders - Microsoft Learn — DNS stub zones - Microsoft Learn — DNS delegation - Microsoft Learn — split-brain DNS deployment guidance - Microsoft Learn — Dynamic DNS updates and DHCP credentials - Microsoft Learn — DnsUpdateProxy security considerations - Microsoft Learn — DNS aging and scavenging - Microsoft Learn — DNS Global Query Block List - Microsoft security guidance — WPAD attack surface - Microsoft Learn — Secure dynamic update and DNS ACLs - Microsoft Learn — Active Directory site and subnet design - Microsoft Learn — DC Locator - Microsoft Learn — DNS conditional forwarders and delegation