next up previous contents
Next: Kerberos im genannten Kontext Up: Lösungsideen und Alternativen Previous: Namensraum - Vereinheitlichung der   Contents


DNS - dynamisch versus statisch

Eine grundlegende Frage, die sich stellte, aber auch recht zügig und abschließend beantwortet werden kann, ist die nach den Vorgaben an das DNS-System, welches für die Windows-Umgebung bereitgestellt werden muss.
Grundsätzlich wird darauf hingewiesen, dass das Konzept von Active Directory ein dynamisches DNS-System (DDNS) voraussetzt, um die Wartung und Pflege zu vereinfachen und die große Zahl an Einträgen zu handhaben. Dieses System muss vor allem Software Ressource Records (kurz SRV-Einträge) unterstützen, um die Lokalisierung von Diensten auf Basis des DNS-Dienstes zu ermöglichen. Außerdem ist wohl eine Intension des DDNS, dass Clienten, die ihre Netzwerkeinstellungen per DHCP erhalten, ihre DNS-Einträge aktuell halten können. Wie im Theorieteil bereits angesprochen, werden standardmäßig eine Unzahl von Einträge erstellt, was wahrlich einen größeren Aufwand bei der Pflege eines statischen Systems bedeutete. Da innerhalb dieser aber viele Redundanzen an Informationen liegen, verringert sich der Bedarf an Einträgen auf eine überschaubare Anzahl notwendiger, wenn ein paar wenige DNS-Anfragen mehr kein Problem in der Netzkapazität darstellen beziehungsweise die Struktur der Domänen nicht durch viele Standorte mit zum Teil sehr schwacher Netzwerkanbindung geprägt ist.
Ein Grund für den Einsatz dynamischer Updates, der einem im Kontext von serverbasierten Diensten in verteilten Umgebungen einfällt, die Unterstützung von Failover-Szenarien, hat sich aus den Versuchen in diesem Zusammenhang nicht bestätigt. Die verschiedenen DNS-Einträge, die Dienste referieren, werden bei Ausfall eines Domaincontrollers nicht aktualisiert oder an die neue Umgebung angepasst. Vielmehr müssen Betriebsmasterausfälle manuell durch Verschieben der Rolle kompensiert, GC-Server-Ausfälle können durch redundante Bereitstellung abgefangen werden. Bei statischem DNS ist demnach nur ein Verschieben der PDC-Rolle nachzuvollziehen.
Aus der Kombination dieser Erkenntnis mit dem Umstand, dass im Netz des URZ eine feste Zuordnung von MAC- zu IP-Adressen stattfindet, somit das dynamische Update durch den Clienten hinfällig ist, lässt sich das Maß der notwendigen DNS-Einträge einschränken. Ein Einsatz von dynamischen Updates wird damit als nicht notwendig erachtet. Inwieweit sich dadurch die in der Literatur angesprochene Performanceeinbuße bemerkbar macht, kann hier nicht eingeschätzt werden, da sowohl die Netzgegebenheiten als auch die Rechneranzahl in der Testumgebung eine echte Einschätzung nicht zulässt.
Natürlich ist davon auszugehen, dass die recht große Anzahl der Windowsclienten im gesamten Campusnetz eine Lastverteilung auf alle im Netz verfügbaren Domaincontroller und insbesondere bei der Authentifizierung auf die GC-Server sinnvoll macht, eventuell auch die ortsgebundene Strukturierung über Campusteile. Die Werkzeuge des BIND-Systems oder anderer Netzbeeinflussungen bieten genügend Möglichkeiten dem gerecht zu werden. Der Einsatz von RoundRobin bei Anfragen oder Zuweisung eines GC-Servers je nach Subnetz wären hier denkbar.

Prinzipiell sind zwei Möglichkeiten der Umsetzung eines DNS-Konzepts denkbar, die beide im Rahmen der Teststellung getestet wurden. Die eine Möglichkeit besteht aus der Erstellung einer gesonderten DNS-Domain auf dem externen DNS-Server (BIND), welche neben den Hosteinträgen auch die notwendigen SRV-Records enthält und somit bereitstellt. Diese Variante ist der Aufgabenstellung folgend die sinnvollste zum Betrieb einer zentralen AD-Domäne.
Beim Betrieb weiterer Subdomänen beispielsweise ist eine weitere Konstellation der DNS-Struktur denkbar. So wird für die Domain im zentralen DNS-System nur ein Verweis auf einen domainspezifischen DNS-Server angelegt und innerhalb der Domäne wird ein eigenständiger DNS-Server betrieben, im Kontext der Aufgabe vorzugsweise ein MS-DNS-Dienst. Dadurch kann die Administration von Domainspezifika an diese delegiert werden. Etwa ist denkbar, dass ein zusätzlich auf dem Domaincontroller betriebener Dienst weitere Einträge im DNS der Domäne hinterlegt. Derartige Einträge können dann durch den Administrator der Subdomäne gepflegt werden. Auch kann an dieser Stelle keine Aussage über die Notwendigkeit von weiteren SRV-Einträge getroffen werden, die nicht im Zusammenhang mit dem grundlegenden Domaincontroller-Dienst stehen.

Ausgehend von der im Theorieteil aufgeführten Tabelle können folgende Einträge für den Betrieb einer Domäne, wie es bei einer zentralen AD-Domain möglich wäre, generell als notwendig erachtet werden:

_msdcs.domain.tld.
  _ldap._tcp.dc SRV 0 100 389 Domaincontroller
  _kerberos._tcp.dc SRV 0 100 88 Domaincontroller
  _ldap._tcp.gc SRV 0 100 3268 Domaincontroller
  _ldap._tcp.pdc SRV 0 100 389 Domaincontroller

domain.tld.
  _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
  gc._msdcs A       IP des Domaincontrollers
  Domaincontroller A       IP des Domaincontrollers
Im Anhang A findet sich die beispielhafte Konfigurationsdatei des BINDs aus dem Betrieb einer AD-Domäne im Rahmen der Teststellung. Dabei ist "`ad.spielwiese.netz"' eine mittels statischem DNS konfigurierte Domäne, "`sub.ad.spielwiese.netz"' eine Subdomäne, die einen eigenen DNS-Server besitzt, auf welchen nur mittels eigener Zone und dem NS-Eintrag in der ad.spielwiese.netz-Zone verwiesen wird. Die SRV-Einträge in der Zone "`spielwiese.netz"' dienen der Abbildung von Hostnamen auf Kerberos-Realms und deren Dienstlokation. Auch Heimdal und MIT unterstützen die Lokalisierung ihrer Ressourcen per DNS.
Wird sich im Rahmen der Strukturdebatte für die komplette Zentralisierung der DNS-Verwaltung ausgesprochen, müssen auch die DNS-Einträge der Subdomänen eingepflegt werden. Ausgehend von der im Theorieteil aufgezeigten Tabelle sind folgende Einträge als notwendig anzusehen:
sub.domain.tld.
  _ldap._tcp.dc._msdcs SRV 0 100 389 Subdomaincontroller
  _kerberos._tcp.dc._msdcs SRV 0 100 88 Subdomaincontroller
  _ldap._tcp.pdc._msdcs SRV 0 100 389 Subdomaincontroller
  _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
  Subdomaincontroller A       IP des Subdomaincontrollers
Der Eintrag der DomainID, der im "`_msdcs"'-Bereich der Root-Domäne eingetragen wird, entfällt, da keinerlei ID-Einträge übernommen werden.
Alternativ, wie bereits angesprochen, ist es ebenfalls möglich, seitens der zentralen Struktur nur einen Verweis auf den zuständigen DNS-Server für die dezentrale Domäne einzurichten. Somit bliebe es in der Verantwortlichkeit der Subdomainenadministration, ob dort dynamisch oder statisch die DNS-Einträge gepflegt werden und der Betreiber eines solchen Windows-DCs in einer Struktureinheit kann entscheiden, ob er beispielsweise einen MS-DNS-Server auf seinem Domaincontroller betreibt.
Dazu wird zentral für die Domäne eine eigenständige Zone eingerichtet, die vom Typ "`forward"' ist und durch "`forward first"' die Anfragen direkt an den definierten Server weiterleiten. Ist die Domäne eine Substruktur einer auf dem zentralen System als "`master"' definierten Zone, ist in dieser zusätzlich ein "`NS"'-Eintrag für die Subdomäne einzutragen.
Dies könnte wie folgt aussehen:
zone "'sub.domain.tld"' IN {
type forward;
forward first;
forwarders { $DNS-Server-IP$; };
};

Es bleibt also festzuhalten, dass der grundlegende Betrieb einer AD-Domäne auch mit einem statischen externen DNS-System realisierbar ist. Auf dem externen System werden eine Unzahl von Log-Einträgen erzeugt, die auf den abgewiesenen Versuch hinweisen, durch einen Windows-Rechner seinen DNS-Eintrag dynamisch zu aktualisieren.
Inwieweit eine komplette Zentralisierung der DNS-Technologie für die Windows-Systeme gewünscht oder vorangetrieben wird, ist eine politische Entscheidung, die im Zusammenhang mit der zu führenden Strukturentscheidung zu sehen ist.


next up previous contents
Next: Kerberos im genannten Kontext Up: Lösungsideen und Alternativen Previous: Namensraum - Vereinheitlichung der   Contents
Marko Damaschke 2006-03-25