Wenn man einen Blick in die DNS-Einträge wirft, die nach der Installation des Active Directory erstellt werden, findet man reichlich komplexe Strukturen vor. Das liegt daran, dass das Active Directory viele Daten für die Lokalisierung von Domänencontrollern und anderen Diensten in den DNS-Zonen speichert.
Als Microsoft das Active Directory entworfen hat, stand die Verwendung von Standards sehr weit oben auf der Prioritätenliste. DNS und LDAP sind solche Standards, die das Active Directory prägen, auch wenn mancher Kritiker Microsoft vorwirft, die Standards recht weit definiert zu haben. Mittlerweile sind aber frühe Interoperabilitätsprobleme weitgehend Geschichte, weil einerseits Microsoft die eine oder andere Modifikation im Active Directory durchgeführt hat und andererseits mancher Ansatz von Microsoft auch Eingang in die relevanten Standards gefunden hat.
Die DNS-Implementierung ab dem Windows 2000 Server unterscheidet sich grundlegend von derjenigen bei «konventionellen» DNS-Servern. Diese speichern die DNS-Informationen standardmässig in sogenannten Zonendateien. Bei der Microsoft-Variante ist das zwar auch möglich, als Redmonder Standardfall ist aber die Speicherung im Active Directory vorgesehen. Das bringt Vorteile in bezug auf die Sicherheit und Replikation: Zum einen gelten die differenzierten Zugriffsberechtigungen des Active Directory auch für die DNS-Informationen, zum anderen werden nur geänderte Einträge repliziert und nicht die gesamte Zonendatei. Eine solche teilweise Replikation ist mittlerweile über Erweiterungen auch mit anderen DNS-Implementierungen möglich, dennoch bietet die Integration mit dem Active Directory insgesamt Vorteile.
Allerdings hat hier auch Microsoft nachbessern müssen: Ab dem Windows Server 2003 werden die DNS-Informationen standardmässig in speziellen Verzeichnispartitionen, den sogenannten Application Directory Partitions, abgelegt. Diese Informationen müssen nur noch auf diejenigen Domänencontroller repliziert werden, die auch tatsächlich als DNS-Server fungieren, und nicht mehr auf
alle Domänencontroller in einer Domäne.
Die Active-Directory-integrierten Zonen sind übrigens voll interoperabel mit dem konventionellen Modell der DNS-Zonen. Die Umsetzung der Informationen aus dem Active Directory in Zonendateien und zurück wird vom DNS-Dienst automatisch durchgeführt.
Zwischen den beiden Varianten der Speicherung von DNS-Informationen gibt es keine funktionalen Unterscheide in bezug auf die zugreifenden Anwendungen. Ebenso können auch andere DNS-Server unterstützt werden, soweit diese dynamische Aktualisierungen und SRV-Records unterstützen. SRV-Records enthalten Informationen zu Diensten und werden vom Active Directory sehr intensiv genutzt. Diese Voraussetzungen sind bei allen aktuellen, professionellen DNS-Implementierungen gegeben.
Die Verbindung zwischen den DNS-Zonen und der Struktur des Active Directory erfolgt über die Domänennamen. Active-Directory-Domänen haben voll ausgeschrieben einen DNS-Namen, also beispielsweise kuppinger.de. Die Domänencontroller versuchen beim Start, Informationen aus dem Active Directory und über sich selbst in die DNS-Zonen zu schreiben respektive die vorhandenen Daten zu aktualisieren.
Dabei wird eine relativ komplexe Baumstruktur erzeugt, in der es neben den gängigen DNS-Einträgen wie dem SOA-Record (Source of Authority) und dem Hinweis auf den Namensserver vor allem eine Reihe von Host-Records gibt, also Einträgen für die einzelnen Computer. Zusätzlich finden sich in DNS-Zonen, die vom Active Directory verwendet werden, aber auch einige Subdomänen.
In der Domäne _msdcs – die Bezeichnung steht für Microsoft Domain Controllers – finden sich Informationen zu den Domänencontrollern. Die meisten Einträge beziehen sich auf die Domänencontroller in der lokalen Domäne, eine Ausnahme bilden die sogenannten Forest-Root-Domänen. So wird die erste in einem Forest angelegte Domäne genannt, in der die Aliase für alle Domänencontroller im Forest gespeichert sind. Diese wiederum werden verwendet, um die GUID (Globally Unique ID) des Domänencontrollers ermitteln zu können, die dann schliesslich für die Suche im Active Directory genutzt wird. Die GUID ist, wie der Name schon sagt, eine eindeutige ID, die es genau einmal geben kann.
Innerhalb der Subdomäne _msdcs gibt es vier weitere Subdomänen. In dc finden sich Informationen über die Domänencontroller, in domains sind Daten zu den eigentlichen Domänen und deren GUIDs abgelegt. Bei gc stehen weitere Einträge zu den Domänencontrollern, und bei pdc finden sich Verweise auf diejenigen Controller, die die Funktion eines PDC übernehmen. Diese sind beispielsweise für ältere Clients und für Kennwortänderungen wichtig, indem sie die Rolle des PDC-Betriebsmasters übernehmen.
In der Subdomäne _sites finden sich Daten, die nach den im Active Directory definierten Standorten strukturiert sind. Bei _tcp sind Serverdienste eingetragen, die über das TCP-Protokoll erreichbar sind, während es bei _udp diejenigen sind, die für Zugriffe über UDP benötigt werden.
Die auf den ersten Blick recht komplexen Strukturen sind bei näherer Betrachtung durchaus logisch. Unterhalb von _sites gibt es beispielsweise den Standort Chur, darunter das Protokoll _tcp und den Dienst _kerberos oder _ldap. Damit lässt sich einfach ein Kerberos-Dienst für die Authentifizierung (also ein Domänencontroller) am Standort Chur identifizieren. Der Eintrag für den Dienst verweist auf den DNS-Namen, der über den Host-Record aufgelöst werden kann.
Als fast einzige Einträge auf unterster Ebene finden sich die schon erwähnten SRV-Records. Diese wirken im ersten Moment etwas kryptisch. Sie enthalten eine Priorität und eine Gewichtung, die Portnummer sowie den DNS-Namen des Host, der den Dienst anbietet. Mit der Priorität wird festgelegt, ob ein Serverdienst überhaupt genutzt werden kann, wenn ein anderer Server mit höherer Priorität verfügbar ist. Mit der Gewichtung wird die Lastverteilung zwischen Servern, die den gleichen Dienst anbieten, gesteuert. SRV-Records gibt es für die schon genannten LDAP- und Kerberos-Dienste sowie für Kerberos Password Server (_kpasswd) und Global Catalog Server (_gc).
Die unterschiedlichen Subdomänen sind erforderlich, um auf verschiedene Weise auf die Informationen auf den Domänencontrollern zugreifen zu können. Wenn beispielsweise ein lokaler Domänencontroller gesucht wird, führt der Weg über _sites. Für andere Aufgaben muss dagegen über
_msdcs gearbeitet werden, um alle Domänencontroller innerhalb einer Domäne einfach ermitteln zu können.
Die Client-Komponenten, die auf die Active-Directory-spezifischen DNS-Einträge zugreifen, sind in erster Linie die Locator-Dienste. Diese gab es auch schon vor Windows 2000 und dem Active Directory. Mit Windows 2000 respektive den speziellen Active-Directory-Clients für ältere Windows-Plattformen sind sie aber so umgestellt worden, dass sie nun bevorzugt die Informationen in der DNS-Datenbank nutzen. Das gilt auch für Server, wenn diese beispielsweise die Replikationstopologie ermitteln müssen. Durch die umfassenden Informationen in den DNS-Records können die Systeme gezielt beispielsweise Kerberos Password Server für Kennwortänderungen oder Global Catalog Server ermitteln.
Wie so oft bei Windows-Servern gilt auch in bezug auf die von Domänencontrollern erstellten DNS-Einträge, dass man daran im Regelfall nichts machen muss. Domänencontroller passen die Einträge bei Bedarf während des Boot-Vorgangs selbständig an. Falls es aber Probleme bei der Lokalisierung von Domänencontrollern gibt, dann empfiehlt es sich, die Einträge daraufhin zu analysieren, ob wirklich alle erforderlichen Informationen vorhanden sind. Die Kenntnis der Strukturen ist vor allem für die Fehlersuche von Bedeutung, weil DNS-Probleme eine häufige Ursache für Probleme im Active Directory sind – sei es bei der Replikation oder bei der Authentifizierung.
