Registrierung der SRV-DNS-Einträge von Domänencontrollern

Damit sich Clientcomputer erfolgreich an der Domäne anmelden können oder Applikationen den Verzeichnisdienst für Suchen kontaktieren können, müssen Domänencontroller ihre Dienste veröffentlichen und zeigen, dass sie erreichbar sind. Hierzu registrieren Domänencontroller in DNS sogenannte SRV-Records, nach denen Clients suchen und die von DCs zur Verfügung gestellten Dienste gefunden werden können. Näheres zu SRV-Records findet man hier: http://support.microsoft.com/kb/241515/de („Wie Überprüfen der Erstellung von SRV-Einträgen für einen Domäne-Controller“), http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsbc_nar_sdns.mspx?mfr=true („SRV Resource Records“).

Bleiben nur noch die Fragen zu klären, wann und wie Domänencontroller diese SRV-Records in DNS aktualisieren.

Das „wie“ ist einfach gelöst, da sehr gut dokumentiert: der NETLOGON-Dienst kümmert sich, neben der Verifikation von Anmeldungen an der Konsole und der Replikation mit NT4-DCs, auch um das Registrieren der Records. Die schwierigere Frage jedoch, das „wann“, bleibt offen. Im Internet finden sich mehrere Quellen, die teilweise widersprüchliche Aussagen machen:

Tim Springston macht in seinem Active Directory Blog (http://blogs.technet.com/ad/archive/2008/08/08/a-complicated-scenario-regarding-dns-and-the-dc-locator-srvs.aspx) Angaben darüber, dass die SRV-Records einmal in 24 Stunden (Server 2003) bzw. einmal stündlich (Server 2008) aktualisiert würden, Mark Minasi hingegen behauptet in seinen Onlinehörbüchern, es würde alle 8 Stunden geschehen. Zeit, das Ganze selbst zu testen: man bootet einen DC, löscht testweise einen seiner SRV-Records und wartet und misst dabei die Zeit. Das Ergebnis: nach etwa 15 Minuten erscheint er wieder in DNS. Ein Ergebnis, das keine der bisherigen Quellen genannt hat.

Ein zweiter Testaufbau ist angesagt. Diesmal etwas umfangreicher: zwei Domänencontroller einer Testdomäne werden gebootet. Auf einem der DCs wird ein Netzwerksniffer installiert, um den Netzwerktraffic zwischen den beiden DCs mitschneiden zu können. Für das Mitschneiden wird ein Trick angewandt: beide DCs werden so konfiguriert, dass sie als primären DNS den jeweils anderen DC konfiguriert bekommen. So werden sie versuchen, die Aktualisierung der SRV-Records beim Partner-DC durchzuführen und so das Mitschneiden der Netzwerkkommunikation für uns zu vereinfachen. Würden sie die SRV-Records bei sich selbst registrieren, würden wir das Registrieren gar nicht bemerken, da dann die Records via Active Directory Replikation verteilt würden.

Um nun nur die relevanten Netzwerknachrichten anzuzeigen, setzen wir noch einen Filter ein. Für Wireshark wählen wir beispielsweise den Filter dns.flags.opcode == 5, was soviel wie „DNS Update“ bedeutet. Die beiden DCs werden nach Neukonfiguration der DNS-Einstellungen neu gestartet. Direkt nach dem Reboot wird der Netzwerksniffer samt Filter aktiviert. Das Ergebnis ist wie folgt:

Server 2003 DC:

Und für Server 2008:

Wir können erkennen, dass in beiden Fällen, für 2003 und 2008 die Zeitintervalle, in der SRV Records neu in DNS registriert werden, ansteigen und schließlich zu einem maximalen Limit kommen. Während sich bei beiden Servervarianten die Zeit zwischen den SRV-Registrationen verdoppelt, ist die maximale Zeit, die zwischen den Registrationen liegen darf, unterschiedlich. Bei Server 2003-DCs liegt das Maximum bei 1440 Minuten, was genau 24 Stunden entspricht. Auf Server 2008-DCs liegt das Maximum bei 60 Minuten – SRV Records werden also stündlich aktualisiert.
Die sind somit die beiden Werte, die Tim Springston auf seinem Blogartikel schildert – er vergaß lediglich, die aufsteigenden Intervalle zu nennen. Die oben genannten Werte sind natürlich das Standardverhalten und können durch das Hinzufügen eines Schlüssels in der Registrierung verändert werden. Hierzu fügt man einen neuen DWORD-Schlüssel namens „DefaultRegistrationRefreshInterval“ in HKLM\System\CurrentControlSet\Services\TcpIp\Parameters. Als Wert gibt man die Maximalzeit des Registrierungsintervalle in Sekunden ein (Wichtig: die Zahlenbasis auf „Dezimal“ stellen). Der Schlüssel ist standardmäßig nicht vorhanden und muss somit händisch hinzugefügt werden.

Aus den Testergebnissen lässt sich auch ablesen, warum der erste Test mit der manuellen Löschung des SRV-Records ein wiedereinfügen nach 15 Minuten zur Folge hatte: Nach Start des Systems und dem Wiedereinloggen bis hin zum löschen war die erste Re-Registrierung nach 5 Minuten schon vorüber, die nächste Re-Registrierung erst zehn Minuten später fällig (nach insgesamt 15 Minuten nach dem Systemstart).

Ein besonderer Dank gilt zwei US-amerikanischen Kollegen, Eric und Mike, die mich in ihr Geek-Netzwerk aufnahmen und mit mir zusammen die Testläufe auf verschiedenen Testdomänen durchführten.