Ausgangslage: DNS ist Teil der Identitaetskontrolle

Active Directory funktioniert nicht ohne DNS. Domain Controller werden ueber SRV-Records gefunden, Kerberos haengt an sauberen Namen, Clients suchen LDAP-, GC- und KDC-Endpunkte, Applikationen nutzen CNAMEs und Administratoren arbeiten mit Hostnamen, die seit Jahren niemand mehr bewusst angefasst hat. Wenn AD-integrierte DNS-Zonen unsauber gepflegt sind, ist das deshalb nicht nur ein Verfuegbarkeitsthema.

Typische Probleme sehen harmlos aus: dynamische Updates stehen noch auf NonsecureAndSecure, alte A-Records zeigen auf neu vergebene IP-Adressen, Reverse-Zonen wurden nie mitgehaertet, DHCP-Server besitzen Records, die andere DHCP-Server nicht mehr aktualisieren koennen, oder DNSAdmins ist zu einer bequemen Betriebsgruppe geworden. Dazu kommen Zone Transfers zu Systemen, die niemand mehr verantwortet, und manuelle Eintraege ohne Owner.

Das Sicherheitsrisiko entsteht nicht durch DNS allein. Es entsteht, wenn Namensdaten nicht mehr vertrauenswuerdig sind. Dann landen Clients bei falschen Zielen, Kerberos faellt auf Nebeneffekte zurueck, veraltete Systeme bleiben auffindbar, und kritische Dienste koennen ueber Namen erreichbar wirken, die fachlich laengst abgeschaltet sein sollten.

Zielbild: DNS-Zonen sind kontrollierte Infrastruktur

Ein sauberes Zielbild fuer AD-integrierte DNS-Zonen hat konkrete Eigenschaften:

  1. Produktive AD-Zonen akzeptieren nur sichere dynamische Updates. Unsichere Updates sind keine Standardoption fuer Domain-Zonen.
  2. Record-Owner sind nachvollziehbar. Es ist klar, ob Client, DHCP-Server oder Betriebsteam einen Record anlegt und aktualisiert.
  3. Zonenrechte sind eng vergeben. DNSAdmins, Domain Admins und breite Helpdesk-Gruppen sind nicht der normale Weg fuer Alltagsaenderungen.
  4. Zone Transfers sind aus oder allowlist-basiert. AD-integrierte Replikation ersetzt in vielen Umgebungen klassische AXFR-Pfade.
  5. Stale Records werden kontrolliert bereinigt. Aging und Scavenging sind geplant, pilotiert und dokumentiert, nicht blind global aktiviert.
  6. Kritische Records werden ueberwacht. Aenderungen an DC-, KDC-, LDAP-, CA-, Admin- und Management-Namen sind auswertbare Ereignisse.

Das Ziel ist nicht, DNS unflexibel zu machen. Das Ziel ist, Namensdaten als Teil der AD-Sicherheitsgrenze zu behandeln.

Umsetzung: Zone fuer Zone absichern

1) Zonenbestand und Einstellungen erfassen

Starte mit einer read-only Bestandsaufnahme. Wichtig sind nicht nur die Forward Lookup Zones, sondern auch Reverse-Zonen, _msdcs, delegierte Subzonen, alte Testzonen und eventuell vorhandene Secondaries.

Ein erster Blick auf Zonentyp, AD-Integration, Dynamic Updates und Transfer-Einstellungen:

Import-Module DnsServer

Get-DnsServerZone |
  Select-Object ZoneName,ZoneType,IsDsIntegrated,DynamicUpdate,ReplicationScope,SecureSecondaries,Notify |
  Sort-Object ZoneName

Fuer Aging und Scavenging lohnt sich eine separate Sicht:

Get-DnsServerZone |
  Where-Object { $_.ZoneType -eq 'Primary' } |
  ForEach-Object {
    Get-DnsServerZoneAging -Name $_.ZoneName -ErrorAction SilentlyContinue
  }

Die Ausgabe ist noch keine Bewertung. Sie zeigt aber schnell, welche Zonen nicht AD-integriert sind, wo unsichere Updates erlaubt sind, wo Zone Transfers offen stehen und wo Scavenging entweder fehlt oder unklar konfiguriert wurde.

2) Secure Dynamic Updates als Standard setzen

Fuer AD-integrierte Domain-Zonen ist Secure der Zielzustand. NonsecureAndSecure sollte nur eine bewusst befristete Legacy-Ausnahme sein, idealerweise in einer separaten Zone mit klarer Migrationsplanung.

Beispiel fuer eine geplante Aenderung mit Vorschau:

Set-DnsServerPrimaryZone `
  -Name "corp.example" `
  -DynamicUpdate Secure `
  -WhatIf

Vor dem produktiven Change muss klar sein, wer Records aktualisiert. Windows-Clients, Domain Controller, DHCP-Server, Cluster, Appliances und Monitoring-Systeme koennen unterschiedliche Update-Pfade nutzen. Wenn diese Pfade nicht verstanden sind, fuehrt die Haertung zu Fehlersuche statt zu Risikoreduktion.

Nicht jede Zone braucht dynamische Updates. Statische Infrastrukturzonen, Management-Zonen oder delegierte Spezialzonen koennen oft auf None stehen. Wichtig ist die bewusste Entscheidung pro Zone.

3) DHCP-Updates und Record-Ownership sauber modellieren

Viele DNS-Probleme entstehen nicht durch DNS-Server, sondern durch unklare DHCP-Registrierung. Mal registriert der Client seinen A-Record selbst und DHCP nur den PTR-Record. Mal registriert DHCP beide Records. Mal besitzen alte DHCP-Server Records, die neue Server nicht aktualisieren koennen.

Praktische Leitplanken:

  • DHCP-Server und Scopes dokumentieren, die DNS-Records aktualisieren duerfen.
  • Fuer DHCP-DNS-Updates ein dediziertes, normales Domaenenkonto nutzen, wenn mehrere DHCP-Server Records konsistent pflegen muessen.
  • Dieses Konto nicht mit administrativen Rechten ausstatten.
  • DHCP auf Domain Controllern besonders kritisch bewerten.
  • Alte DHCP-Server, Testscopes und Schatten-DHCPs aus dem Update-Pfad entfernen.
  • Fuer kritische statische Records Owner, Zweck und Aenderungsprozess dokumentieren.

Der Punkt ist nicht, ein einziges DHCP-Modell fuer jede Umgebung zu erzwingen. Der Punkt ist, dass Record-Ownership vor der Haertung bekannt sein muss.

4) Zonen- und Record-Rechte reduzieren

AD-integrierte DNS-Zonen liegen in Active Directory. Damit sind DNS-Rechte auch AD-Rechte. Breite Schreibrechte auf einer produktiven Zone sind deshalb ein Sicherheits- und Betriebsrisiko.

Pruefe besonders:

  • Wer ist Mitglied von DNSAdmins?
  • Gibt es Gruppen mit Schreibrechten auf der Zone, die eigentlich nur einzelne Records pflegen sollen?
  • Duerfen normale Betriebsgruppen Records fuer Tier-0-Systeme aendern?
  • Sind manuelle Delegationen dokumentiert?
  • Gibt es Records fuer DCs, CAs, Admin-Jumphosts, Backup-Server oder Management-Systeme mit auffaelligen ACLs?

Fuer den Alltag ist es meist besser, wenige klar delegierte Prozesse zu haben als viele Menschen mit Vollzugriff auf DNS. Ein Helpdesk braucht nicht automatisch Rechte auf die gesamte Domain-Zone, nur weil gelegentlich ein Alias gepflegt werden muss.

5) Zone Transfers und Notifications einschraenken

AD-integrierte Zonen replizieren ueber Active Directory. Klassische Zone Transfers sind deshalb oft nicht noetig. Wenn Secondaries, Appliances, Monitoring-Systeme oder Spezial-DNS-Server wirklich Zone Transfers brauchen, gehoeren sie auf eine Allowlist.

Beispiel fuer eine Zone ohne AXFR-Bedarf:

Set-DnsServerPrimaryZone `
  -Name "corp.example" `
  -SecureSecondaries NoTransfer `
  -Notify NoNotify `
  -WhatIf

Beispiel fuer definierte Secondaries:

Set-DnsServerPrimaryZone `
  -Name "corp.example" `
  -SecureSecondaries TransferToSecureServers `
  -SecondaryServers 10.10.20.53,10.10.20.54 `
  -Notify NotifyServers `
  -NotifyServers 10.10.20.53,10.10.20.54 `
  -WhatIf

Offene Zone Transfers sind selten fachlich begruendet. Sie erhoehen die Sichtbarkeit interner Namen und machen alte Architektur einfacher nachvollziehbar, als es fuer den Betrieb noetig ist.

6) Aging und Scavenging vorsichtig einfuehren

Scavenging ist sinnvoll, aber kein Quick Win ohne Nebenwirkungen. Es loescht Records. Falsch konfiguriert kann es kritische Namen entfernen oder alte Fehler sichtbar machen, die jahrelang durch statische oder stale Records kaschiert wurden.

Ein kontrollierter Ablauf:

  1. Stale Records zuerst auswerten, nicht sofort loeschen.
  2. Kritische statische Records markieren und Owner klaeren.
  3. No-refresh- und Refresh-Intervalle passend zu DHCP-Leases und Betriebsmodell waehlen.
  4. Aging pro Zone pilotieren.
  5. Scavenging nur auf definierten DNS-Servern aktivieren und das Ergebnis beobachten.
  6. Geloeschte Records und betroffene Systeme fuer die erste Phase aktiv reviewen.

Beispielhafte Pilotkonfiguration mit Vorschau:

$interval = New-TimeSpan -Days 7

Set-DnsServerZoneAging `
  -Name "corp.example" `
  -Aging $true `
  -NoRefreshInterval $interval `
  -RefreshInterval $interval `
  -WhatIf

In Umgebungen mit vielen mobilen Clients, VPNs, VDI, Clustern oder kurzlebigen Servern muss das Zeitmodell zum Betrieb passen. Sonst wird Scavenging entweder wirkungslos oder zu aggressiv.

7) Kritische Records ueberwachen

DNS-Aenderungen werden oft erst untersucht, wenn Namensaufloesung bricht. Fuer AD-Hardening ist das zu spaet. Kritische Records sollten wie andere Identitaets- und Tier-0-Aenderungen beobachtet werden.

Besonders relevant:

  • _ldap._tcp, _kerberos._tcp, _gc._tcp und _msdcs-Records,
  • A- und CNAME-Records von Domain Controllern,
  • CA-, NDES-, OCSP- und Enrollment-Endpunkte,
  • Admin-Jumphosts, PAWs, Backup- und Management-Systeme,
  • Fileserver- und Applikationsaliasse mit breiter Nutzung,
  • neue Zonen, geloeschte Zonen und geaenderte Zone-Transfer-Einstellungen.

Das Monitoring muss nicht mit Alarmen fuer jeden Client-Refresh starten. Sinnvoll ist eine Unterscheidung zwischen normalen dynamischen Client-Updates und Aenderungen an privilegierten Namen, Zonenrechten oder Servereinstellungen.

8) In Wellen ausrollen

Ein pragmatischer Ablauf:

  1. Alle AD-integrierten Zonen, Reverse-Zonen und Sonderzonen inventarisieren.
  2. Zonen mit NonsecureAndSecure, offenen Transfers oder unklaren ACLs priorisieren.
  3. DHCP-Update-Modell und Record-Ownership klaeren.
  4. Eine unkritische Zone oder Pilot-OU fuer Secure Updates und Scavenging waehlen.
  5. Kritische Records und statische Eintraege vorab sichern und dokumentieren.
  6. Zone Transfers auf NoTransfer oder definierte Secondaries umstellen.
  7. Aenderungen mit DNS-, DHCP-, Kerberos-, LDAP- und Applikationstests validieren.
  8. Zielzustand in Betriebsdokumentation, Monitoring und Change-Prozess uebernehmen.

Der wichtigste Punkt: DNS-Haertung ist kein einzelner Schalter. Sie ist eine Kombination aus Update-Sicherheit, Rechten, Ownership, Bereinigung und Ueberwachung.

Vorteile

  • Weniger unautorisierte Namensaenderungen: Produktive AD-Zonen akzeptieren keine beliebigen unsicheren Updates mehr.
  • Stabilere AD-Abhaengigkeiten: DC-Locator, Kerberos, LDAP, GPO und Applikationsnamen werden verlaesslicher.
  • Bessere Transparenz: Es wird sichtbar, wer Records anlegt, aktualisiert und verantwortet.
  • Weniger Altlasten: Stale Records und alte Testnamen verschwinden kontrolliert statt zufaellig.
  • Geringere Informationsabgabe: Zone Transfers liefern interne Namensdaten nur noch an definierte Systeme.
  • Besserer Betrieb: DNS-Fehler werden frueher erkannt, weil Ownership und Monitoring klarer sind.

Nachteile und Grenzen

  • Vorarbeit ist noetig: Ohne Inventar von Zonen, DHCP-Modell und Record-Ownern wird die Umstellung riskant.
  • Legacy kann brechen: Alte Appliances, Nicht-Windows-Systeme oder manuelle Prozesse koennen unsichere Updates erwartet haben.
  • Scavenging kann echte Ausfaelle ausloesen: Wenn kritische Records falsch altern, verschwinden Namen, die produktiv gebraucht werden.
  • Mehr Change-Disziplin: DNS-Aenderungen brauchen Owner, Ticket, Test und Rueckfallplan.
  • Nicht jedes Problem ist DNS: Kerberos-, SPN-, Zeit- und Firewall-Fehler sehen oft wie DNS-Probleme aus.
  • Delegation bleibt anspruchsvoll: Feingranulare DNS-Rechte sind sauberer, aber aufwaendiger als eine breite Admin-Gruppe.

Typische Stolperfallen

  • DNS nur als Infrastruktur behandeln: In AD ist DNS Teil der Identitaets- und Tier-0-Abhaengigkeit.
  • NonsecureAndSecure als Normalzustand dulden: Das ist bestenfalls eine befristete Legacy-Ausnahme.
  • Helpdesk in DNSAdmins aufnehmen: Vollzugriff ist selten die richtige Loesung fuer einzelne Alias-Aenderungen.
  • Reverse-Zonen vergessen: PTR-Records, DHCP und Troubleshooting haengen oft daran.
  • Scavenging global aktivieren: Ohne Pilot, Owner und Review kann das produktive Namen loeschen.
  • Zone Transfers an alle erlauben: Interne Namensdaten werden dadurch unnoetig leicht kopierbar.
  • DHCP-Ownership ignorieren: Mehrere DHCP-Server ohne klares Update-Modell erzeugen inkonsistente Records.
  • Kritische Records nicht ueberwachen: Aenderungen an DC-, KDC-, CA- oder Admin-Namen sind sicherheitsrelevant.

Projekt-Checkliste

  • [ ] Alle Forward-, Reverse-, _msdcs- und Sonderzonen erfassen.
  • [ ] Pro Zone IsDsIntegrated, DynamicUpdate, ReplicationScope, SecureSecondaries und Notify dokumentieren.
  • [ ] Zonen mit NonsecureAndSecure oder offenen Transfers priorisieren.
  • [ ] DHCP-Server, DHCP-DNS-Credentials und Record-Ownership klaeren.
  • [ ] Mitgliedschaften in DNSAdmins und delegierte Zonenrechte pruefen.
  • [ ] Kritische Records fuer DCs, CAs, Admin-, Backup- und Management-Systeme markieren.
  • [ ] Zone Transfers auf NoTransfer oder definierte Secondaries begrenzen.
  • [ ] Secure Dynamic Updates zuerst in Pilot-Scope testen.
  • [ ] Aging und Scavenging mit passenden Intervallen pilotieren.
  • [ ] DNS-, DHCP-, Kerberos-, LDAP- und Applikationstests nach Changes ausfuehren.
  • [ ] Monitoring fuer kritische DNS-Aenderungen und neue Zonen einrichten.
  • [ ] DNS-Aenderungen in Change-Prozess, Betriebsdokumentation und Review-Zyklus aufnehmen.