Seite 2 - Zentraler Namensdienst

Lesezeit
4 Minuten
Bis jetzt gelesen

Seite 2 - Zentraler Namensdienst

10.09.2007 - 15:45
Veröffentlicht in:
Zonentypen und Eigenschaften
Sowohl für den Forward- wie auch für den Reverse-Lookup werden die Namensräume in Zonen verwaltet. Es gibt unterschiedliche Typen von Zonen, die ich hier erklären will:

Primäre Zonen dürfen Informationen in die Zone schreiben.Wenn ein Administrator einen geänderten oder einen neuen Eintrag schreiben möchte, wird dies in der Primären Zone gemacht. Im Allgemeinen darf es nur einen Server geben, der die Primäre Zone für einen Namensraum hält.

Sekundäre Zonen halten eine Kopie der Zone, die nur gelesen werden darf. Sekundäre Zonen erhalten Änderungen immer von einem Server, der eine primäre Kopie der Zone hält. Es kann beliebig viele Server geben, die eine Sekundäre Zone von einer Primären Zone halten. Damit eine Sekundäre Zone eine Kopie der Primären Zone erhalten kann, muss der Server definiert sein, der die Primäre Zone hält. Außerdem muss der Server, auf dem die Primäre Zone liegt, den Zonentransfer auf die Server erlauben, die die Sekundäre Zone erhalten sollen. Dies können Sie in den Eigenschaften der Zone überprüfen. Primäre und Sekundäre Zonen sind also vergleichbar mit dem PDC und den BDCs unter Windows NT 4.0.

Stub-Zonen sind beim Windows Server 2003 neu hinzugekommen. Eine Sekundäre Zone kopiert den gesamten Inhalt der Primären Zone. Dagegen speichert die Stub-Zone nur die Einträge einer Zone, die definieren, welche Server für die Namensauflösung der Zone zuständig sind. Die Vorteile hierbei liegen auf der Hand: Zum einem muss dafür kein Zonentransfer erlaubt werden (die Stub-Zone kann die Einträge einfach anfragen und speichert diese dann). Zum anderen müssen nicht so viele Daten gespeichert und übertragen werden. Allerdings bieten die Stub-Zonen damit auch keine Entlastung für die anderen DNSServer, da sie keine Host-Einträge außer denen der Namensserver für die Zone kennen. Der Zonentransfer zwischen Primären und Sekundären Zonen kann mit dem DNS-Server unter Windows 2000 Server oder Windows Server 2003 auch inkrementell erfolgen. Bisher wurden immer alle Inhalte der Zone bei einem Transfer übertragen. Jetzt ist es möglich, nur die Unterschiede seit dem letzten Transfer auszutauschen.

Wenn der DNS-Server-Dienst auf einem Active Directory Domänencontroller (DC) läuft, können Sie Active Directory- integrierte Primäre Zonen erstellen (oder existierende Zonen umstellen).
Das hat die folgenden Vorteile:
– Die Replikation der Zonendaten läuft über das Active Directory,
– alle DNS-Server, die auf DCs laufen, können auf die Zone schreibend zugreifen (Multi-Master),
– “Sichere Dynamische Updates” können benutzt werden.
Mehr zur Integration des Active Directory in DNS finden Sie in der nächsten Ausgabe des IT-Administrator.

Windows 2000, XP und Windows Server 2003 können außerdem die Daten in den DNS-Zonen über Dynamische Updates aktualisieren. Ohne dynamische Updates müsste der Administrator jede Änderung bei der Zuordnung von Netzwerknamen zu IP-Adressen manuell anpassen (und bei Active Directory Domänencontrollern noch dessen Services- Einträge). Über die dynamischen Updates informieren DNS-Clients und DHCP-Server die DNS-Server über Änderungen von IP-Adressen. Standardmäßig aktualisiert der Client die Zuordnung Hostname zu IP-Adresse (der Hostname ändert sich normalerweise nicht für den Client) in der Forward- Lookup-Zone. Der DHCP-Server aktualisiert die umgekehrte Zuordnung der IP-Adresse zum Hostnamen (der Client bekommt immer wieder eine andere IPAdresse, der DHCP-Server bleibt aber für die von ihm verwalteten IP-Adressen zuständig).Wenn man in einem Active Directory-integrierten DNS (nur sichere) dynamische Updates auf der Zone ermöglicht, kann über den Mechanismus für die Aktualisierung gewährleistet werden, dass der gleiche Computer immer die gleichen Einträge erneuert. Damit kann man anderen Computern Änderungen an fremden Einträgen verbieten und so zusätzliche Sicherheit erreichen.

Für die dynamischen Updates ist es noch notwendig zu erwähnen, dass die Dienste “Netlogon” und “DHCP-Client” auf dem DNS-Client für die Aktualisierungen der Einträge im DNS verantwortlich sind. Machen Sie daher nicht den Fehler, den DHCP-Client auf einem Server zu deaktivieren (man könnte ja meinen, dass dieser Dienst nicht gebraucht wird,wenn die TCP/IP-Eigenschaften manuell vorgegeben sind). Ansonsten sind keine dynamischen Updates mehr möglich.

DNS-Clients und Server
Ein DNS-Client ist prinzipiell jede Maschine im Netzwerk (auch Mitgliedsserver, Domänencontroller oder DNS-Server), die auf einen DNS-Server zugreift. Der DNS-Client kümmert sich darum, dass die Applikationen auf dem Computer in der Lage sind, DNS-Namen zu IP-Adressen aufzulösen. Hierfür leitet er die Anfragen an einen DNS-Server weiter.Welchen DNS-Server der DNS-Client verwendet, kann in dem Dialogfeld “Eigenschaften von Internet Protocol (TCP/IP)” angegeben werden.

Clients, die ihre IP-Adressen über DHCP bekommen, können auch über DHCP TCP/IP-Eigenschaften wie die DNS-Server erhalten. Des Weiteren ist es wichtig, dass der Client seinen vollständigen Netzwerknamen (FQDN) kennt. Dies geschieht normalerweise beim Beitritt einer Active-Directory-Domäne automatisch. Wenn man eine Domäne erst noch aufbaut oder etwas “verkonfiguriert” hat, muss ein Administrator den Namen gegebenenfalls anpassen. Dies geschieht in den “Systemeigenschaften\Computername” über die Schaltflächen “Ändern” und “Weitere”. Passen Sie hier den “Primären Domänensuffix” an, zum Beipsiel bei dem “client1.firma.de” auf “firma.de”. Beachten Sie noch, dass das Auswahlfeld “Primäres DNS-Suffix bei Domänenmitgliedschaftsänderung ändern” gesetzt ist. Dann wird der “Primäre DNS-Suffix” bei einer neuen Änderung der Domäne automatisch angepasst.

Der DNS-Client speichert auch die Anfragen, die er getätigt hat, und deren Antworten zwischen. Hierbei werden auch Anfragen, die nicht aufgelöst werden konnten, zwischengespeichert. Mit dem Befehl
ipconfig /displaydns
können Sie sich den Inhalt des Auflösungscaches anzeigen lassen. Mit dem Befehl
ipconfig /flushdns
können Sie den Auflösungscache leeren.

Wenn Sie Zonen für Ihren internen Namensraum erstellt haben und die DNSClients richtig eingerichtet sind, funktioniert jetzt die Namensauflösung dieser Zone. Wie können aber Namen aus anderen Bereichen aufgelöst werden?

Delegationen
Eingangs hatten wir erwähnt, dass ein Server, der eine Zone hält, für deren Namensraum verantwortlich ist. Dies würde auch alle Namen beinhalten, die unterhalb dieses Namensraums liegen. Damit ein Server, der zum Beispiel die Zone “company.com.” hält, nicht auch alle Einträge für die untergeordnete DNS-Domäne “eu.company.com.” verwalten muss, kann man die Verwaltung von DNS-Domänen in neue DNS-Zonen delegieren. Bei einer Delegation wird in die Zone “company.com.” geschrieben, dass für den Namensraum “eu.company.com.” ein oder mehrere andere Server verantwortlich sind.Würde ein Client (oder ein anderer DNSServer) jetzt einen der DNS-Server von “company.com.” nach einem Namen in der DNS-Zone “eu.company.com.” fragen, so würde der Server nur antworten, welche Server für diesen Bereich zuständig sind.

Sowohl Stub-Zonen wie auch Delegationen enthalten die Einträge für Nameserver (NS-Einträge) der jeweiligen Zonen. Damit die IP-Adressen der Server auch gefunden werden, enthalten Delegationen und Stub-Zonen zusätzlich die Host-Einträge (A-Einträge) der Nameserver. Delegationen sind immer sehr zielorientiert: Fragt man einen DNS-Server nach einer untergeordneten Domäne, bekommt man immer zur Antwort, wer für diese zuständig ist (oder zumindest, wer mehr weiß – das kann bei mehreren Hierarchien vorkommen). Merken kann man sich das ganz einfach: Schließlich bedeutet eine Delegation, dass ich einen Teil meiner Verantwor tung (über den gesamten Namensraum) an jemand anderen abgebe. Ich weiß aber genau, an wen ich diese Verantwortung abgegeben habe. Wenn derjenige einen weiteren Teilbereich delegiert, muss er in der Lage sein, mir mitzuteilen, an wen er diesen delegiert hat. Genauso verhält es sich auch beim DNS. 

<<Vorherige Seite          Seite 2 von 3           Nächste Seite>>





Ausgabe 03/05 des IT-Administrator Magazins S. 36- 42, Autor: Ulf B. Simon-Weidner

Ähnliche Beiträge

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (3)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im dritten und letzten Teil gehen wir auf weitere Varianten ein, etwa die ZTP-Provisionierung ohne proprietären Server, die Boot-Loader-Variante iPXE oder das alte Verfahren AutoInstall.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (2)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im zweiten Teil der Workshopserie schildern wir den proprietären Cisco-Ansatz "Network-Plug-and-Play", der über eine GUI erfolgt und bei dem sich die ausgerollten Komponenten an die Gegebenheiten im Netzwerk anpassen lassen.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (1)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Sowohl die Installation von Betriebssystemen als auch Applikationen erfolgt meist automatisiert. Im Gegensatz dazu kommen diese Prozesse bei Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im ersten Teil skizzieren wir die möglichen Rollout-Verfahren und beschreiben, welche Ansätze und Möglichkeiten sich Unternehmen hier bieten.