sir_melonchenandClaude Opus 5.5
91b243f05f
ci / Go (lint, test, vuln) (push) Successful in 6m39s
ci / Protobuf (push) Successful in 7s
ci / Shell and licence headers (push) Successful in 14s
ci / Release build (dry run) (push) Successful in 3m14s
ci / Integration (real BIND and Kea) (push) Successful in 2m54s
ci / Development environment (compose) (push) Successful in 14s
install / Installation (debian:12) (push) Successful in 3m23s
ci / Web (lint, test, audit, build) (push) Successful in 1m49s
ci / End-to-end (server, agents, BIND, Kea) (push) Successful in 3m30s
install / Installation (debian:13) (push) Successful in 3m26s
install / Installation (rocky:9) (push) Successful in 6m39s
install / Installation (ubuntu:22.04) (push) Successful in 3m35s
install / Installation (ubuntu:24.04) (push) Successful in 3m35s
dcdiag /test:dns needs the Windows DNS service and stays red with BIND; list the checks that work instead, explain the _msdcs delegation message and the DFSR state that blocks a second DC. Fix the script examples. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
130 lines
13 KiB
Markdown
130 lines
13 KiB
Markdown
# Active Directory mit dynamischen Zonen
|
||
|
||
Diese Anleitung beschreibt, wie die DNS-Zonen einer Active-Directory-Domäne (AD) auf den von der DDI Suite verwalteten BIND-Servern liegen. Grundlage sind [ADR 0023](adr/0023-cluster-und-zonen-m5.md) und [ADR 0026](adr/0026-eintraege-in-dynamischen-zonen.md).
|
||
|
||
## Grundsatz
|
||
|
||
Domain Controller (DC) registrieren ihre Einträge selbst per **RFC-2136-Update** (dynamisches DNS): A-Records der DCs, SRV-Records für LDAP, Kerberos und den globalen Katalog sowie die Einträge unter `_msdcs`. Die Zone der AD-Domäne muss deshalb eine **dynamische Zone** sein. Bei dynamischen Zonen gilt:
|
||
|
||
- Der DNS-Agent legt die Zone in BIND an und schreibt **nur beim ersten Mal** eine Anfangsdatei. Danach gehören Zonendatei und Journal BIND; die DDI Suite überschreibt sie nie.
|
||
- Die Records, die die DDI Suite für die Zone kennt – A/AAAA/PTR aus der Adresstabelle und die in der Oberfläche angelegten Records der Zone –, trägt der DNS-Agent auf dem Primary bei jeder Revision **per dynamischem Update** ein (`nsupdate` mit dem Systemschlüssel `ddi-agent-update`). Was in DDI gelöscht oder geändert wurde, entfernt er dabei genau als diesen Record. Records anderer Herkunft (von den DCs, von Clients, per Hand) fasst er nie an.
|
||
- Ändert oder löscht jemand einen von DDI verwalteten Record direkt in BIND, stellt die nächste Revision den Stand aus DDI wieder her.
|
||
- Updates werden nur von den eingetragenen Quellen angenommen: IP-Adressen bzw. Netze (`allow_update`), TSIG-Schlüssel der Zone und der Systemschlüssel des Agents.
|
||
|
||
**Nicht unterstützt (Version 1):** GSS-TSIG (Kerberos-gesicherte „sichere“ Updates, wie sie AD-integrierte Microsoft-DNS-Server verwenden). Updates werden daher über die IP-Adressen der DCs oder über TSIG abgesichert.
|
||
|
||
## Einrichtung
|
||
|
||
1. **Zone anlegen** (*Zonen → Neue Zone*): Name der AD-Domäne, z. B. `ad.example.com`, Modus **dynamisch**, DNS-Cluster wählen.
|
||
2. **Update-Quellen** eintragen: die IP-Adressen aller Domain Controller als `/32` bzw. `/128`, z. B. `192.0.2.10/32` und `192.0.2.11/32`. Keine ganzen Client-Netze eintragen – sonst kann jeder Rechner darin Einträge der Domäne überschreiben.
|
||
3. **`_msdcs`:** Die Einträge unter `_msdcs.ad.example.com` gehören in **dieselbe** dynamische Zone. Eine eigene Zone `_msdcs.…` ist nicht nötig (und wird nicht abgeleitet); die DCs legen die Records darin selbst an.
|
||
4. **Reverse-Zonen:** Sollen DCs oder Clients auch PTR-Records eintragen, die betroffene Reverse-Zone ebenfalls als dynamische Zone anlegen (z. B. `2.0.192.in-addr.arpa`) und dieselben Update-Quellen eintragen. Die PTR-Records der Adresstabelle hält der Agent darin ebenso aktuell. Reverse-Zonen, in die niemand außer DDI schreibt, bleiben besser `managed`.
|
||
5. **Revision erzeugen und ausrollen.** Der Primary des Clusters nimmt die Updates an, die Secondaries erhalten die Änderungen per NOTIFY und IXFR. Mit der ersten dynamischen Zone legt der Server den Systemschlüssel `ddi-agent-update` an; er steht in der Liste der TSIG-Schlüssel, lässt sich rotieren, aber nicht löschen.
|
||
6. **Windows-Seite:** Auf den DCs als DNS-Server die Adressen der BIND-Server eintragen. In den DNS-Einstellungen der Netzwerkkarte „Adressen dieser Verbindung in DNS registrieren“ aktiv lassen. Die DCs schicken Updates an den Server aus dem SOA-Record (MNAME) der Zone; das ist der Primary des Clusters (bzw. `primary_ns`).
|
||
|
||
Prüfen lässt sich die Registrierung nach einem Neustart des Dienstes „Netlogon“ auf einem DC (`nltest /dsregdns`) mit:
|
||
|
||
```sh
|
||
dig @<primary> SRV _ldap._tcp.dc._msdcs.ad.example.com
|
||
```
|
||
|
||
## Bestehende Windows-DNS-Zone nach DDI
|
||
|
||
So zieht eine AD-integrierte Zone eines Windows-DNS-Servers auf die BIND-Server der DDI Suite um. Beispiel: Domäne `ad.example.com`, DCs `192.0.2.10` und `192.0.2.11`, BIND-Primary `192.0.2.53`.
|
||
|
||
1. **Bestand sichern:** Auf einem DC die Zone exportieren, z. B. `dnscmd /zoneexport ad.example.com ad.example.com.dns` (Datei unter `%SystemRoot%\System32\dns`) oder `Get-DnsServerResourceRecord -ZoneName ad.example.com | Export-Csv records.csv`. Die Liste dient als Vorlage und zum Vergleich.
|
||
2. **Zone in DDI anlegen:** *Zonen → Neue Zone*, Name `ad.example.com`, Modus **dynamisch**, DNS-Cluster wählen, unter `allow_update` die Adressen aller DCs als `/32` bzw. `/128`. Gibt es unter Windows eine eigene Zone `_msdcs.ad.example.com` (Standard für die Stammdomäne einer Gesamtstruktur), entfällt sie: Ihre Records landen in der dynamischen Zone `ad.example.com`. Reverse-Zonen bei Bedarf ebenso dynamisch anlegen (Einrichtung, Punkt 4).
|
||
3. **Übrige Einträge übernehmen:** Mitgliedsserver, Drucker und andere feste Adressen aus dem Export als Einträge der Adresstabelle importieren (CSV-Import in ein Netz mit der Domain `ad.example.com`; DDI erzeugt dann A und PTR) oder, wenn sie zu keinem verwalteten Netz gehören, als Records der Zone anlegen. Die Einträge der DCs selbst (A, SRV, `_msdcs`) nicht übernehmen – die DCs tragen sie gleich selbst ein.
|
||
4. **Ausrollen** und prüfen, dass BIND die Zone bedient: `dig @192.0.2.53 SOA ad.example.com` und für einen übernommenen Eintrag `dig @192.0.2.53 A server1.ad.example.com`.
|
||
5. **DCs umstellen:** Auf jedem DC in den Einstellungen der Netzwerkkarte die BIND-Server als DNS-Server eintragen (der DC selbst bzw. `127.0.0.1` nicht mehr an erster Stelle). Die DCs schicken ihre Updates an den Server aus dem SOA-Record (MNAME) der Zone, also den Primary des Clusters. Alternativ behalten die DCs ihren eigenen DNS-Server, wenn dieser die Zone nicht mehr selbst hält, sondern per bedingter Weiterleitung an die BIND-Server verweist: Dann finden sie den Primary über den SOA-Record und schicken ihm die Updates direkt.
|
||
6. **Neu registrieren lassen**, auf jedem DC:
|
||
|
||
```bat
|
||
ipconfig /registerdns
|
||
nltest /dsregdns
|
||
```
|
||
|
||
`nltest /dsregdns` trägt die SRV-Records des DC-Locators neu ein; gleichwertig ist ein Neustart des Dienstes „Netlogon“ (`net stop netlogon && net start netlogon`). Die vollständige Liste der Records, die Netlogon registrieren will, steht in `%SystemRoot%\System32\config\netlogon.dns`.
|
||
7. **Prüfen:**
|
||
|
||
```sh
|
||
dig @192.0.2.53 SRV _ldap._tcp.dc._msdcs.ad.example.com
|
||
dig @192.0.2.53 SRV _kerberos._tcp.ad.example.com
|
||
dig @192.0.2.53 A dc1.ad.example.com
|
||
```
|
||
|
||
Auf einem DC zusätzlich `dcdiag /test:RegisterInDNS /DnsDomain:<domain>` (`dcdiag /test:dns` taugt nur, solange der Windows-DNS-Server noch läuft, siehe [Prüfen nach der Umstellung](#prüfen-nach-der-umstellung)). Fehlen Records, im Log des Primary (`named`) nach `update … denied` suchen: Meist passt die Quelladresse des DCs nicht zu `allow_update`.
|
||
8. **Clients umstellen:** Die DNS-Server der Clients auf die BIND-Server setzen – in DDI über die DNS-Server der Netze (DHCP-Option 6), bei festen Adressen per Hand oder Gruppenrichtlinie. Den Windows-DNS-Server mit der alten Zone erst abschalten bzw. die Zone dort löschen, wenn alle Leases erneuert sind; bis dahin beide Seiten vergleichen.
|
||
|
||
**Folgen ohne GSS-TSIG:** „Sichere“ Updates (GSS-TSIG/Kerberos) beherrscht BIND hier nicht. Updates sind nur über die Quelladresse (und TSIG, das Windows nicht kann) abgesichert; wer im Netz eine DC-Adresse fälschen kann, kann Einträge der Domäne ändern – die DCs deshalb in ein eigenes, gefiltertes Netz. Windows-Clients können sich nicht selbst registrieren (ihre Updates werden abgelehnt, solange ihre Netze nicht in `allow_update` stehen, und das sollen sie nicht); ihre Namen kommen aus der Adresstabelle. Namen dynamischer DHCP-Clients wären Aufgabe von Kea-DDNS (noch nicht umgesetzt). Ein Aufräumen veralteter Einträge (Scavenging) gibt es nicht.
|
||
|
||
## Updates mit TSIG
|
||
|
||
Statt über IP-Adressen lassen sich Updates mit einem TSIG-Schlüssel absichern, etwa für DHCP-Server, Skripte oder `nsupdate`:
|
||
|
||
1. *TSIG-Schlüssel → Neuer Schlüssel* (Algorithmus `hmac-sha256`).
|
||
2. In der dynamischen Zone den Schlüssel unter „Update-Schlüssel“ auswählen.
|
||
3. Geheimnis anzeigen (nur Administratoren, wird protokolliert) und beim Client hinterlegen, z. B. für `nsupdate`:
|
||
|
||
```text
|
||
key "updater.ad.example.com" {
|
||
algorithm hmac-sha256;
|
||
secret "<Geheimnis>";
|
||
};
|
||
```
|
||
|
||
```sh
|
||
nsupdate -k updater.key <<EOF
|
||
server <primary>
|
||
zone ad.example.com
|
||
update add host1.ad.example.com. 3600 A 192.0.2.50
|
||
send
|
||
EOF
|
||
```
|
||
|
||
Microsoft-Clients und -DCs beherrschen TSIG nicht; für sie bleibt nur die Freigabe per IP-Adresse.
|
||
|
||
## Hinweise
|
||
|
||
- Wird eine dynamische Zone gelöscht oder einem anderen Cluster zugeordnet, entfernt der Agent den Zonenblock aus der Konfiguration, löscht aber Zonendatei und Journal nicht. Die Daten liegen weiter im Zonenverzeichnis des Servers.
|
||
- Eine Zone von `managed` auf `dynamic` umzustellen ist möglich: Die vorhandene Zonendatei bleibt bestehen und wird ab dann von BIND gepflegt. Der umgekehrte Weg verwirft alle per Update angelegten Records.
|
||
- Scavenging (Aufräumen veralteter dynamischer Einträge) übernimmt BIND nicht; veraltete Records müssen per `nsupdate` entfernt werden.
|
||
- MX-Records einer dynamischen Zone, deren Ziel in der Zone liegt, brauchen dort einen A- oder AAAA-Record: Sonst lehnt BIND das Update des Agents ab (Prüfung `check-integrity`), und das Ausrollen der Revision scheitert.
|
||
|
||
## Skript für die Domain Controller
|
||
|
||
[`tools/windows/Set-DcDnsToDdi.ps1`](../tools/windows/Set-DcDnsToDdi.ps1) stellt einen DC (auch Server Core, Windows PowerShell 5.1) auf die BIND-Server um: prüft die Zone auf dem DDI-Server, setzt die DNS-Server der Netzwerkkarte, macht auf Wunsch eine DHCP-Adresse statisch (`-MakeStatic`), stoppt und deaktiviert den Windows-DNS-Server, registriert A-Record und Locator-Records neu (`ipconfig /registerdns`, `nltest /dsregdns`) und wartet, bis A-, SRV- und `_msdcs`-Einträge am DDI-Server antworten. Vorher die Adresse des DCs als Update-Quelle der Zone eintragen und ausrollen.
|
||
|
||
```powershell
|
||
.\Set-DcDnsToDdi.ps1 -DnsServer 10.10.10.151 -WhatIf # nur anzeigen
|
||
.\Set-DcDnsToDdi.ps1 -DnsServer 10.10.10.151 -MakeStatic -StartIsmServ -Sync
|
||
```
|
||
|
||
## Fehlersuche: `dcdiag /test:dns` meldet fehlende Einträge
|
||
|
||
- **A-Record des DCs da, SRV-Records fehlen:** Den A-Record trägt der DNS-Client ein (`ipconfig /registerdns`), die SRV-Records, den `<GUID>._msdcs`-CNAME, `gc._msdcs` und `DomainDnsZones` trägt **Netlogon** ein. Lief `nltest /dsregdns` (oder der Start von Netlogon), bevor die Update-Quellen stimmten, versucht Netlogon es erst Stunden später erneut. Abhilfe auf jedem DC: `nltest /dsregdns` oder `net stop netlogon && net start netlogon`, dann `dcdiag /test:dns` wiederholen.
|
||
- **`gc._msdcs` oder andere A-Records unter `_msdcs` fehlen:** BIND prüft in Primary-Zonen Hostnamen (`check-names`) und lehnt Unterstriche ab. Seit v0.9.1 erzeugt DDI für dynamische Zonen `check-names ignore;`; ältere Versionen nach dem Update neu ausrollen.
|
||
- **Updates werden abgelehnt:** Windows schickt Updates an den Server aus dem SOA der Zone (Primary). `nslookup -type=SOA <domain> <dns-server>` muss den BIND-Primary nennen, und dessen Name muss auflösen (z. B. als Eintrag in der Adresstabelle). Die Adressen der DCs müssen unter *Update-Quellen* der Zone stehen. Im Log von BIND (`journalctl -u named` bzw. `-u bind9`) steht bei jeder Ablehnung die Quell-IP (`update … denied`).
|
||
- **„invalid DNS server“ / keine Internet-Namen:** DDI betreibt BIND standardmäßig rein autoritativ. Zeigen DCs oder Clients ausschließlich auf BIND, unter *DNS/DHCP-Einstellungen* Rekursion einschalten, die eigenen Netze unter „Rekursion erlaubt für“ eintragen und Forwarder angeben (z. B. Router oder Resolver des Providers).
|
||
- **Domain Controller mit DHCP-Adresse:** dcdiag warnt zu Recht; DCs sollten ihre IP fest im Betriebssystem eingetragen haben.
|
||
- **„Broken delegated domain _msdcs“:** BIND führt `_msdcs` in der Zone selbst, ohne Delegation. Die Meldung stammt aus den Daten eines noch laufenden Windows-DNS-Servers (auf dem DC, auf dem dcdiag läuft); sie verschwindet, sobald dort der Dienst gestoppt ist. Eine eigene Zone `_msdcs.<domain>` in DDI ist nicht nötig – sie würde die vorhandenen `_msdcs`-Einträge der Hauptzone verdecken.
|
||
|
||
## Prüfen nach der Umstellung
|
||
|
||
`dcdiag /test:dns` setzt einen Windows-DNS-Server auf dem DC voraus. Ist dieser gestoppt, meldet der Test „DNS service is stopped“ bzw. „no DNS RPC connectivity“ und überspringt den Rest; mit BIND bleibt er daher rot. Ebenso erzeugt dcdiag selbst DCOM-Fehler (Ereignis 10028) im Systemprotokoll, weil es die DNS-Server per Microsoft-RPC verwalten will. Aussagekräftig sind stattdessen:
|
||
|
||
```powershell
|
||
dcdiag /test:RegisterInDNS /DnsDomain:ad.example.com # darf der DC seine Einträge registrieren?
|
||
nltest /dsgetdc:ad.example.com /force # DC-Locator
|
||
dcdiag # Standardtests ohne DNS-Test
|
||
repadmin /replsummary
|
||
```
|
||
|
||
Scheitern dabei *Advertising* und *NetLogons* (Freigabe `NETLOGON` fehlt, `SysvolReady` = 0), liegt das nicht an DNS, sondern an der SYSVOL-Replikation (DFSR). Konnten die DCs sich vor der Umstellung lange nicht erreichen, steht ein DC oft im Zustand 5 mit Ereignis 4012 (`MaxOfflineTimeInDays` überschritten) und der andere wartet mit 4612/4614 auf die Erstsynchronisation. Abhilfe ist eine autoritative SYSVOL-Synchronisation vom DC mit der gültigen Kopie (Microsoft KB 2218556). Zustand abfragen:
|
||
|
||
```powershell
|
||
Get-CimInstance -Namespace root\microsoftdfs -ClassName DfsrReplicatedFolderInfo | Select-Object ReplicatedFolderName,State # 4 = normal
|
||
```
|
||
|
||
Auf Server Core fehlt `dfsrdiag`; statt `dfsrdiag pollad` genügt `Restart-Service DFSR`.
|