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 { ; }; |
}; |
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: Kerberos im genannten Kontext
Up: Lösungsideen und Alternativen
Previous: Namensraum - Vereinheitlichung der
  Contents
Marko Damaschke
2006-03-25