DNS und AD

Active Directory nutzt seit seiner Ausrichtung auf Internet-Standards den Domain Name Service als zentrales Werkzeug zum Auffinden von Ressourcen und der Lokalisierung von Diensten.
Wie schon angerissen, wird zu diesem Zwecke vorausgesetzt, dass der DNS-Dienst so genannte SRV-Einträge Software Ressource Records (SRV) unterstützt. Diese Funktionalität wird seitens des Clienten und des Servers benötigt. Alle Windows-Betriebssysteme, die mit Active Directory nativ zusammenarbeiten, unterstützen diese Funktionalität von Hause aus. Solche Einträge verbinden einen Dienstnamen innerhalb einer DNS-Domäne mit dem Namen eines Servers, dem TCP- beziehungsweise UDP-Port des Dienstes und einer Priorität des Dienstanbieters. Dadurch kann der Client mittels der DNS-Funktionalität dynamisch an wechselnde Gegebenheiten seitens der Serverlandschaft gebunden werden. Es wird also ermöglicht, ohne Änderungen der Konfiguration am Clienten, virtuelle Adressen wie bei Clustern ohne Broadcasts oder eine sinnvolle Lastverteilung durch die Server selbst zu realisieren oder bei Ausfall beziehungsweise Nichterreichbarkeit eines Servers die Backup-Variante ausfindig zu machen und anzusprechen.
Doch gerade um diese Aktualität zu gewährleisten und auf strukturelle Änderungen des Netzes zu reagieren, wird empfohlen, darüber hinaus einen Server einzusetzen, der dynamische Updates erlaubt. So können Windows-Clienten bei Adressvergabe mittels DHCP und dynamischen Adressbereichen ihre jeweilige Konfiguration aktuell an den Server vermitteln, aber auch die gegenseitige Überwachung zwischen den Domaincontrollern die Belastung oder Erreichbarkeit untereinander beeinflussen.

Für jede Domain werden viele verschiedene Einträge im DNS erstellt, die zum Auffinden des Verzeichnisses, des globalen Katalogs und des Authentifizierungsdienstes genutzt werden. Wie bereits in der Strukturdiskussion erwähnt, gibt es die Aufspaltung einer Domäne in verschiedene Standorte beziehungsweise die Möglichkeit dazu. Dies findet sich natürlich auch in den DNS-Einträgen wieder. Gleichzeitig wird jedem Objekt eine SID zugeordnet, die sich auch in manchen Einträgen wieder findet.
Die bei einer standardmäßigen Einrichtung angelegten DNS-Einträge werden in 2 Subdomainen strukturiert und finden sich in folgender Liste:

_msdcs.domain.tld.
	_ldap.Standortname._sites.dc	SRV	0	100	389	Domaincontroller
	_kerberos.Standortname._sites.dc	SRV	0	100	88	Domaincontroller
	_ldap._tcp.dc	SRV	0	100	389	Domaincontroller
	_kerberos._tcp.dc	SRV	0	100	88	Domaincontroller
	_ldap._tcp.DomainID.domains	SRV	0	100	389	Domaincontroller
	_ldap.Standortname._sites.gc	SRV	0	100	3268	Domaincontroller
	_ldap._tcp.gc	SRV	0	100	3268	Domaincontroller
	_ldap._tcp.pdc	SRV	0	100	389	Domaincontroller
	gc	A				DomaincontrollerIP

domain.tld.
	_ldap._tcp.Standortname._sites	SRV	0	100	389	Domaincontroller
	_kerberos._tcp.Standortname._sites	SRV	0	100	88	Domaincontroller
	_gc._tcp.Standortname._sites	SRV	0	100	3268	Domaincontroller
	_ldap._tcp	SRV	0	100	389	Domaincontroller
	_kerberos._tcp	SRV	0	100	88	Domaincontroller
	_gc._tcp	SRV	0	100	3268	Domaincontroller
	_kpasswd._tcp	SRV	0	100	464	Domaincontroller
	_kerberos._udp	SRV	0	100	88	Domaincontroller
	_kpasswd._udp	SRV	0	100	464	Domaincontroller
	_ldap._tcp.Standortname._sites.
	DomainDnsZones	SRV	0	100	389	Domaincontroller
	_ldap._tcp.DomainDnsZones	SRV	0	100	389	Domaincontroller
	DomainDnsZones	A				DomaincontrollerIP
	_ldap._tcp.Standortname._sites.
	ForestDnsZones	SRV	0	100	389	Domaincontroller
	_ldap._tcp.ForestDnsZones	SRV	0	100	389	Domaincontroller
	ForestDnsZones	A				DomaincontrollerIP
	Domaincontroller					DomaincontrollerIP

An die entsprechenden Einträge der Tabelle ist die übergeordnete DNS-Domäne anzuhängen, um den jeweiligen Eintrag zu erhalten.

Die Einträge der Tabelle werden für jeden Domaincontroller angelegt, einzig die Einträge des PDC und des GC sind auf eine Auswahl an Domaincontrollern beschränkt. Dadurch entsteht eine ziemlich lange Liste, die sich wahrlich mit statischem DNS auf Grund ihrer Unübersichtlichkeit und der Durchmischung mit Werten wie Domainen-IDs schlecht pflegen lässt.
Aber die Liste enthält auch große Mengen redundanter Daten, die erst in einem sehr stark strukturierten Ausbau von Active Directory Domänen Auswirkungen zeigen beziehungsweise ein paar DNS-Requests weniger verursachen. Solange sich eine Domain beispielsweise nicht über mehrere Standorte erstreckt, also keinerlei Unterschiede für den Clienten entstehen, welchen Domaincontroller er auch kontaktiert, solange sind auch die Einträge mit $Standortname$-Bestandteil vernachlässigbar und kürzen die Tabelle deutlich. Auch die typischen Windows-Einträge, die auf die DomainID aufsetzen, dienen zwar der internen Performance-Steigerung, können aber unter bestimmten Gesichtspunkten auch aus der Liste gestrichen werden. Wie bereits angesprochen, ist die DomainID die SID des Domain-Objektes im AD-Verzeichnis. Diese ist einmalig und eindeutig und ändert sich auch, wenn das Objekt gelöscht und mit selben Namen neu angelegt wird. Somit ist die DomainID-basierte DNS-Suche eindeutiger und wird von Clienten als erste versucht. Schlägt diese Suche nach der DomainID im DNS allerdings fehl, wird automatisch auf die namensbasierte Suche zurückgegriffen und der Zugriff auf AD-basierte Ressourcen nur um einen DNS-Request verzögert. Probleme oder Uneindeutigkeiten können natürlich nur entstehen, wenn eine Domäne gelöscht und eine Neue mit gleichem Namen angelegt wird, auf die dann mit den alten DNS-Einträgen verwiesen wird. Da aber auch alle Objekte der Domain eine neue SID haben, was sich aus dem Aufbau der IDs erklärt, wird nur dann im folgenden Schritt der Zugriff abgewiesen, da auch die Berechtigungen an SIDs gebunden sind.

Im Falle der Einbindung einer Subdomäne "`sub"' in den Domänenbaum von "`domain.tld"' werden folgende DNS-Einträge ergänzend für jede dieser Subdomänen angelegt:

_msdcs.domain.tld.
	_ldap._tcp.SubdomainenID.domains	SRV	0	100	389	Subdomaincontroller
_msdcs.sub.domain.tld.
	_ldap._tcp.Standortname._sites	SRV	0	100	389	Subdomaincontroller
	_kerberos._tcp.Standortname._sites	SRV	0	100	88	Subdomaincontroller
	_ldap._tcp.pdc	SRV	0	100	389	Subdomaincontroller
	_ldap._tcp.dc	SRV	0	100	389	Subdomaincontroller
	_kerberos._tcp.dc	SRV	0	100	88	Subdomaincontroller
sub.domain.tld.
	_ldap._tcp	SRV	0	100	389	Subdomaincontroller
	_kerberos._tcp	SRV	0	100	88	Subdomaincontroller
	_kpasswd._tcp	SRV	0	100	464	Subdomaincontroller
	_kerberos._udp	SRV	0	100	88	Subdomaincontroller
	_kpasswd._udp	SRV	0	100	464	Subdomaincontroller
	_ldap._tcp.Standortname._sites	SRV	0	100	389	Subdomaincontroller
	_kerberos._tcp.Standortname._sites	SRV	0	100	389	Subdomaincontroller
	Subdomaincontroller	A				SubdomaincontrollerIP

Auch hierbei sind die Redundanzen zu beachten, deren Notwendigkeit nicht in allen Fällen gegeben ist. In dieser Liste ist wieder ein Domaincontroller beispielhaft angegeben, bei mehreren finden sich entsprechende Einträge für jeden DC. Einzig der Eintrag des PDC-Emulators, der mit der Betriebsrolle korrespondiert und damit einmalig in der Domain ist, kann und darf nur einmalig vorhanden sein. Weiterhin ist zu bedenken, dass ein globaler Katalog immer für die Gesamtstruktur gültig ist, daher auch ein Domaincontroller einer Substruktur, der als GC-Server dient, einen DNS-Eintrag für den Katalog im DNS-Baum der Root-Domain erhält.
Welche Auswahl dieser DNS-Einträge für den Betrieb wirklich notwendig sind, wird im Kapitel der Lösungsideen unter 5.5 diskutiert. Wie erwähnt, dienen die Redundanzen nur bei starker Strukturierung und auch da vor allem der Performance-Steigerung und Lastverteilung und Minderung des Netzverkehrs.