Windows 2000-DNS

Windows 2000-DNS
Betriebssystem
Whitepaper
Zusammenfassung
Dieses Whitepaper beschreibt das Domänennamensystem (Domain Name System, DNS) des
Betriebssystems Microsoft® Windows® 2000 sowie Gesichtspunkte des Entwurfs, der
Implementierung und der Migration. Es erläutert neue Funktionen der Windows 2000Implementierung von DNS, bietet Beispiele von DNS-Implementierungen und beschreibt die
Architekturkriterien, die Netzwerkarchitekten und Administratoren beim Entwurf eines DNSNamespace für den Active Directory™-Verzeichnisdienst beachten sollten, um zuverlässige
Netzwerknamensdienste bereitzustellen.
Einführung
Die Entwickler des Betriebssystems Microsoft® Windows® 2000 haben sich für DNS
(Domain Name System) als Namensdienst für das Betriebssystem entschieden. Windows
2000 Server enthält einen auf dem IETF-Standard basierenden DNS-Dienst (Domain Name
System). Aufgrund seiner RFC-Kompatibilität ist er vollständig kompatibel mit allen anderen
RFC-kompatiblen DNS-Servern. Die Verwendung des Windows 2000-DNS-Servers ist nicht
obligatorisch. Jede Implementierung eines DNS-Servers, die Ressourceneinträge zur
Dienstidentifizierung (Service Location Resource Records, SRV RRs, beschrieben im Internet
Draft "A DNS RR for specifying the location of services (DNS SRV)") und dynamische
Aktualisierungen (Dynamic Update, RFC2136) unterstützt, ist ausreichend, um den
Namensdienst für Windows 2000–basierte Computer bereitzustellen1. Da diese DNSImplementierung jedoch so entwickelt wurde, dass der Active Directory-Dienst von Windows
2000 in vollem Umfang genutzt wird, stellt sie den empfohlenen DNS-Server für jede
vernetzte Organisation dar, die signifikante Investitionen in Windows getätigt hat oder
Extranetpartner mit auf Windows basierenden Systemen hat. Während beispielsweise
herkömmliche DNS-Server die Einzelmasterreplikation verwenden, kann Windows 2000-DNS
in Active Directory integriert werden und verwendet dann das Multimasterreplikationsmodul
von Windows 2000. (Beachten Sie, dass der Active Directory™-Verzeichnisdienst die
Multimasterreplikation unterstützt.) Für Netzwerk-Manager bedeutet dies eine
Vereinfachung der Systemadministration, da sie keine gesonderte Replikationstopologie für
DNS verwalten müssen.
DNS in Windows 2000 bietet eine einzigartige DNS-Server-Implementierung, die vollständig
interoperabel mit anderen standardbasierten Implementierungen von DNS-Servern ist.
Einige spezielle Interoperabilitätsaspekte werden weiter unten in diesem Dokument erörtert.
Der Zweck dieses Dokuments ist es, Netzwerkarchitekten und Administratoren bei der
Planung der Bereitstellungsstrategie von Windows 2000 Active Directory-DNS zu
unterstützen. Es behandelt die Entwurfs-, Implementierungs- und Migrationsgesichtspunkte,
die beim Entwickeln einer skalierbaren und robusten DNS-Lösung als globaler Namensdienst
zu beachten sind.
Dieses Dokument setzt Kenntnisse in DNS voraus, bietet jedoch in "DNS-Grundlagen" eine
kurze Übersicht über die Grundlagen von DNS. Die Windows 2000-Implementierung von
DNS unterstützt verschiedene neue Funktionen (im Vergleich zum Betriebssystem Windows
NT® 4.0), die in "Neue Funktionen von Windows 2000-DNS" beschrieben sind. Das
Dokument enthält eine Beschreibung der Integration in Active Directory, der inkrementellen
Zonenübertragung (IXFR), der dynamischen (und sicheren) Aktualisierung und der
Unterstützung von Unicode-Zeichen, des erweiterten Domänenlocators, des
Cacheauflösungsdienstes und des DNS-Managers. Es bietet eine ausführliche Übersicht über
den Vorgang der Namensauflösung. Es beschreibt die Unterstützung der sicheren DNSVerwaltung. Es enthält eine Übersicht über die verschiedenen Probleme im Zusammenhang
mit dem Entwerfen des Namespace für Active Directory. Es behandelt die Integration von
Active Directory mit der vorhandenen DNS-Struktur und die Migration zur Windows 2000Implementierung von DNS, den Entwurf privater Namespaces und die erforderliche DNSUnterstützung.
Namensdienste in Windows 2000
DNS ist der Namensdienst von Windows 2000. Es wurde als hochzuverlässige,
hierarchische, verteilte und skalierbare Datenbank entworfen. Windows 2000-Clients
verwenden DNS zur Namensauflösung und Dienstidentifizierung sowie zum Auffinden von
Domänencontrollern für die Anmeldung.
Clients mit Vorgängerversionen (Windows NT 3.5 und 3.51, Windows NT 4.0, Windows 95
und Windows 98) beruhen jedoch auf NetBIOS, das NBNS (WINS), Broadcasts oder eine
normale Datei LmHosts verwenden kann. Insbesondere wird der NetBIOS-Namensdienst
zum Auffinden von Domänencontrollern verwendet.
Da die DNS-Implementierung in Windows 2000 WINS (Windows Internet Name Services)
unterstützt, kann in einer gemischten Umgebung eine Kombination von DNS und WINS
verwendet werden, um größtmögliche Effizienz beim Auffinden verschiedener
Netzwerkdienste und Ressourcen zu erreichen. Darüber hinaus spielt WINS in einer
herkömmlichen oder gemischten Umgebung eine wichtige Rolle für die Interoperabilität und
hilft andererseits, Investitionen zu bewahren. Windows NT 4.0-basierte Clients können sich
selbst in Windows 2000-WINS registrieren, und Windows 2000-basierte Clients können sich
in Windows NT 4.0-WINS registrieren.
Standards und weiterführende Literatur
Die folgenden Dokumente sind im Zusammenhang mit der DNS-Server-Implementierung
von Windows 2000 relevant. Sie lassen sich in zwei Gruppen einteilen. Ein RFC (Request For
Comments) ist ein Standarddokument, wohingegen ein Draft einen Entwurf darstellt, der
zum Standard werden kann.
RFCs:
 1034 Domain Names - Concepts and Facilities
 1035 Domain Names - Implementation and Specification
 1123 Requirements for Internet Hosts - Application and Support
 1886 DNS Extensions to Support IP Version 6
 1995 Incremental Zone Transfer in DNS
 1996 A Mechanism for Prompt DNS Notification of Zone Changes
 2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
 2181 Clarifications to the DNS Specification
 2308 Negative Caching of DNS Queries (DNS NCACHE)
Drafts:
 Draft-ietf-dnsind-rfc2052bis-02.txt (A DNS RR for Specifying the Location of Services
(DNS SRV))
 Draft-skwan-utf8-dns-02.txt (Using the UTF-8 Character Set in the Domain Name
System)
 Draft-ietf-dhc-dhcp-dns-08.txt (Interaction between DHCP and DNS)



Draft-ietf-dnsind-tsig-11.txt (Secret Key Transaction Signatures for DNS (TSIG))
Draft-ietf-dnsind-tkey-00.txt (Secret Key Establishment for DNS (TKEY RR))
Draft-skwan-gss-tsig-04.txt (GSS Algorithm for TSIG (GSS-TSIG) )
Weitere Informationen zu diesen Dokumenten finden Sie unter http://www.ietf.org/
(englischsprachig).
Neben den aufgeführten RFCs und Drafts basiert die Implementierung der ATMA-DNSEinträge auf "ATM Name System Specification Version 1.0".
Weiterführende Literatur:
 Whitepaper "Microsoft DNS and Windows NT 4.0" (
http://www.microsoft.com/windows/downloads/bin/nts/DNSWP.exe
[englischsprachig])
 Kapitel "Designing the Active Directory Structure" im Deployment Planning Guide
 Whitepaper "Active Directory Technical Summary" (
http://www.microsoft.com/windows/server/Technical/directory/default.asp
[englischsprachig])
 "DNS and BIND" (Cricket Liu) erschienen bei O'Reilly and Associates, 3. Auflage,
ISBN: 1-56592-512-2
DNS-Grundlagen
Das Domänennamensystem besteht aus einer hierarchischen verteilten Datenbank und
einem zugehörigen Satz von Protokollen, durch die Folgendes definiert wird:
 Ein Mechanismus zum Abfragen und Aktualisieren der Datenbank
 Ein Mechanismus zum Replizieren der Informationen in der Datenbank zwischen
Servern
 Ein Schema der Datenbank
Verlauf von DNS
Der Ursprung von DNS liegt in der Anfangszeit des Internets, als das Internet ein kleines
Netzwerk war, das vom Department of Defense zu Forschungszwecken eingeführt wurde.
Die Hostnamen der Computer in diesem Netzwerk wurden in einer einzigen Datei HOSTS
auf einem zentral verwalteten Server geführt. Jeder Standort, der Hostnamen im Netzwerk
auflösen musste, führte einen Download dieser Datei durch. Mit wachsender Anzahl von
Hosts im Internet nahm das durch Aktualisierungen verursachte Datenaufkommen und
damit die Größe der Datei HOSTS zu. Die Erfordernis eines neuen Systems mit Funktionen
wie Skalierbarkeit, dezentraler Verwaltung und Unterstützung verschiedener Datentypen
wurde immer offensichtlicher.
Dieses neue System war das 1984 eingeführte DNS (Domain Name System). Bei DNS sind
die Hostnamen in einer Datenbank gespeichert, die auf mehrere Server verteilt werden
kann, wodurch die Last für jeden einzelnen Server verringert und die partitionsweise
Verwaltung des Namensystems ermöglicht wurde. DNS unterstützt hierarchische Namen
und ermöglicht neben der Zuordnung von Hostnamen zu IP-Adressen, die in der Datei
HOSTS verwendet wird, die Registrierung verschiedener Datentypen. Dank der verteilten
Speicherung der DNS-Datenbank ist ihre Größe unbeschränkt und die Leistung nimmt durch
Hinzufügen weiterer Server nicht merklich ab.
Das ursprüngliche DNS basierte auf RFC 882 (Domain names: Concepts and facilities) und
RFC 883 (Domain Names–Implementation and Specification), die ersetzt wurden durch RFC
034 (Domain Names–Concepts and Facilities) und RFC 035 (Domain Names–
Implementation and Specification). Später wurden diese erweitert durch RFCs, die
Sicherheits-, Implementierungs- und Verwaltungsaspekte von DNS beschreiben.
Die DNS-Implementierung BIND (Berkeley Internet Name Domain) wurde ursprünglich für
das Betriebssystem 4.3 BSD UNIX entwickelt.
Microsofts Implementierung des DNS-Servers wurde Teil des Betriebssystems Windows NT
Server 4.0. Der Windows NT 4.0-DNS-Server geht wie die meisten DNS-Implementierungen
auf die RFCs 1034 und 1035 zurück.
Die neueste Version des Betriebssystems Windows 2000 enthält eine neue Version von DNS.
Dieser Version liegen die RFCs 1034, 1035, 1886, 1996, 1995, 2136, 2308 und 2052
zugrunde.
Die Struktur von DNS
Das Domänennamensystem ist als hierarchische und verteilte Datenbank implementiert, die
verschiedene Typen von Daten wie unter anderem Hostnamen und Domänennamen enthält.
Die Namen in einer DNS-Datenbank bilden eine hierarchische Baumstruktur, den
Domänennamespace.
Die Hierarchie von DNS: Domänennamen
Domänennamen bestehen aus einzelnen, durch Punkte getrennten Bezeichnungen.
Zum Beispiel: mydomain.microsoft.com.
Ein vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN)
kennzeichnet eindeutig die Position des Hosts innerhalb der hierarchischen DNSStruktur. Er besteht aus einer Liste von durch Punkte getrennten Namen, die den
Pfad von dem Host zum Stamm der Struktur bilden. Die folgende Abbildung zeigt
ein Beispiel einer DNS-Struktur mit einem Host mydomain in der Domäne
microsoft.com. Der FQDN des Hosts lautet mydomain.microsoft.com.
DNS und Internet
Das Domänennamensystem des Internets wird verwaltet durch eine
Namensregistrierungsinstanz im Internet, die die Organisationen und Ländern zugewiesenen
Domänen der obersten Ebene verwaltet. Diese Domänennamen entsprechen dem
International Standard 3166. In der folgenden Tabelle sind definierte Abkürzungen, die für
Organisationen reserviert sind, sowie 2- und 3-buchstabige Abkürzungen für Länder
aufgeführt.
DNS-Domänenname
Art der Organisation
Organisationen aus dem
Wirtschaftsbereich
Institutionen aus dem Bildungsbereich
Nichtkommerzielle Organisationen
Netzwerke (Backbone des Internets)
Nichtmilitärische Organisationen aus
dem Regierungsbereich
Organisationen aus dem militärischen
Regierungsbereich
Telefonnummern
Reverse-DNS
2-buchstabiger Ländercode
com
edu
org
net
gov
mil
num
arpa
xx
Ressourceneinträge
Eine DNS-Datenbank besteht aus Ressourceneinträgen (Resource Records, RRs). Jeder
Ressourceneintrag kennzeichnet eine bestimmte Ressource in der Datenbank. Es gibt
verschiedene Typen von Ressourceneinträgen in DNS.
In der folgenden Tabelle sind ausführliche Informationen zur Struktur gängiger
Ressourceneinträge aufgeführt (Anmerkung Die Liste ist nicht vollständig):
Beschreibu
ng
Klasse
Gültigkeitsdaue
r (Time To Live,
TTL)
Typ
Autoritätsurs
Internet
prung (Start
(IN)
of Authority)
Standard-TTL
beträgt 60
Minuten
SOA
Internet
(IN)
TTL der SOAZone
A
Host
Daten
Besitzername,
DNS-Name des
primären
Namenservers,
Seriennummer,
Erneuerungsinter
vall,
Wiederholungsint
ervall,
Ablaufzeit,
Minimum TTL
Besitzername
(Host-DNSName),
Namenserver
Internet
(IN)
TTL der SOAZone
NS
MailExchanger
Internet
(IN)
TTL der SOAZone
MX
Kanonischer
Internet
Name
(IN)
(ein Alias)
TTL der SOAZone
CNAME
Host-IP-Adresse
Besitzername,
DNS-Name des
Namenservers
Besitzername,
DNS-Name des
Mail Exchange
Servers,
Vorrangnummer
Besitzername
(Aliasname),
Host-DNS-Name
Verteilen der Datenbank: Zonendateien und Delegierung
Eine DNS-Datenbank kann in mehrere Zonen eingeteilt werden. Eine Zone ist ein Teil der
DNS-Datenbank, der die Ressourceneinträge mit den Besitzernamen enthält, die zum
zusammenhängenden Teil des DNS-Namespace gehören. Zonendateien werden auf DNSServern verwaltet. Ein einzelner DNS-Server kann keine, eine oder mehrere Zonen
enthalten.
Jede Zone ist unter einem bestimmten Domänennamen, der Stammdomäne der Zone,
verankert. Eine Zone enthält Informationen zu allen Namen, die mit dem
Stammdomänennamen der Zone enden. Ein DNS-Server gilt als autorisierend für einen
Namen, wenn er die Zone, die den Namen enthält, lädt. Der erste Eintrag in jeder
Zonendatei ist ein Start of Authority (SOA)-Ressourceneintrag. Der SOA-Ressourceneintrag
gibt einen primären DNS-Namenserver für die Zone an, der die beste Informationsquelle für
die Daten in der Zone und die Entität, die die Aktualisierungen für die Zone verarbeitet,
darstellt.
Namen in einer Zone können auch an andere Zonen delegiert werden. Die Delegierung ist
ein Vorgang, bei dem einer anderen Entität die Verantwortung für einen Teil eines DNSNamespace zugewiesen wird. Diese andere Entität kann eine andere Organisation, Abteilung
oder Arbeitsgruppe in dem Unternehmen sein. Technisch gesehen bedeutet die Delegierung
das Zuweisen von Autorität über Teile des DNS-Namespace an andere Zonen. Eine solche
Delegierung wird durch den NS-Eintrag repräsentiert, der die delegierte Zone und den DNSNamen des Servers angibt, der autorisierend für die Zone ist. Die Delegierung über mehrere
Zonen hinweg war Teil des ursprünglichen Entwurfsziels von DNS. Für die Delegierung eines
DNS-Namespace gibt es im Wesentlichen folgende Gründe:
 Die Notwendigkeit, die Verwaltung einer DNS-Domäne an eine Reihe von
Organisationen oder Abteilungen in einer Organisation zu delegieren.

Die Notwendigkeit, die Last der Wartung einer großen DNS-Datenbank auf
mehrere Namenserver zu verteilen, um die Leistung der Namensauflösung zu
verbessern und andererseits eine fehlertolerante DNS-Umgebung zu
erstellen.
 Die Notwendigkeit, die organisatorische Zuordnung der Hosts durch ihre
Aufnahme in geeignete Domänen zu ermöglichen.
Die NS-Ressourceneinträge ermöglichen die Delegierung durch Festlegen von DNSServern für jede Zone. Sie werden in allen Forward- und Reverse-Lookups
angezeigt. Immer wenn ein DNS-Server eine Delegierung verarbeiten muss, werden
dem NS-Ressourceneintrag die DNS-Server in der Zielzone entnommen.
In der folgenden Abbildung wird die Verwaltung der Domäne microsoft.com. an
zwei Zonen, microsoft.com. und mydomain.microsoft.com. delegiert.
Anmerkung Wenn für eine delegierte Zone in mehreren NS-Einträgen mehrere für die
Abfrage zuständige DNS-Server angegeben sind, ist der Windows 2000-DNS-Server in der
Lage, basierend auf den für jeden DNS-Server gemessenen Antwortzeiten den
nächstgelegenen DNS-Server auszuwählen.
Replizieren der DNS-Datenbank
Es ist möglich, dass ein Teil des Namespace durch mehrere Zonen repräsentiert wird. Diese
Zonen lassen sich in zwei Arten einteilen:
 Primär
 Sekundär
An der primären Zone werden alle Aktualisierungen für zur Zone gehörige Einträge
vorgenommen. Eine sekundäre Zone wird durch eine schreibgeschützte Kopie der primären
Zone repräsentiert. Änderungen an der Datei der primären Zone werden dann in die Datei
der sekundären Zone repliziert.
Wie erwähnt kann ein Namenserver mehrere Zonen verwalten. Ein Server kann somit
primär für eine Zone sein (er verfügt über die Masterkopie der Zonendatei) und sekundär
für eine andere Zone sein (er erhält eine schreibgeschützte Kopie der Zonendatei).
Der Vorgang, eine Zonendatei auf mehrere Namenserver zu replizieren, wird als
Zonenübertragung bezeichnet. Die Zonenübertragung erfolgt durch Kopieren der
Informationen der Zonendatei vom Masterserver auf den sekundären Server.
Ein Masterserver ist die Quelle der Zoneninformationen. Beim Masterserver kann es sich um
einen primären oder sekundären Server handeln. Falls der Masterserver primär ist, kommt
die Zonenübertragung direkt von der Quelle. Ist der Masterserver sekundär, ist die vom
Masterserver bei einer Zonenübertragung erhaltene Datei eine Kopie der schreibgeschützten
Zonendatei.
Die Zonenübertragung wird durch eine der folgenden Aktionen ausgelöst:
 Der Masterserver sendet eine Benachrichtigung (RFC 1996) bezüglich einer Änderung
der Zone an den bzw. die sekundären Server.
 Wenn der DNS-Dienst des sekundären Servers gestartet wird oder das
Erneuerungsintervall des sekundären Servers abgelaufen ist (standardmäßig im
SOA-Ressourceneintrag auf 15 Minuten festgelegt), fragt er den primären Server auf
Änderungen ab.
Es gibt zwei Typen der Zonendateireplikation. Beim ersten Typ, der vollständigen
Zonenübertragung (AXFR), wird die gesamte Zonendatei repliziert. Beim zweiten Typ, der
inkrementellen Zonenübertragung (IXFR), werden nur die geänderten Einträge der Zone
repliziert. Das IXFR-Protokoll wird in "Inkrementelle Zonenübertragung" erläutert.
BIND 4.9.3-DNS-Server unterstützen ebenso wie Windows NT 4.0-DNS ausschließlich die
vollständige Zonenübertragung (AXFR). Es gibt zwei Arten von AXFR: Die eine erfordert
jeweils einzelne Einträge pro Paket, die andere lässt mehrere Einträge pro Paket zu. Der
Windows 2000-DNS-Server unterstützt beide. Standardmäßig verwendet er mehrere
Einträge pro Paket, es sei denn, er wurde zugunsten der Kompatibilität mit den BINDVersionen 4.9.4 und früher, die dies nicht zulassen, anders konfiguriert. Der Windows 2000DNS-Server unterstützt die inkrementelle Zonenübertragung (IXFR).
Abfragen der Datenbank
DNS-Abfragen können von einem Client (Resolver, Auflöser) an einen DNS-Server (einen
Namenserver) oder von einem Namenserver an einen anderen Namenserver gesendet
werden.
Eine Abfrage ist lediglich eine Anforderung von Einträgen eines bestimmten Typs mit einem
bestimmten Namen. Beispielsweise kann eine Abfrage alle Hostressourceneinträge mit
einem bestimmten Namen anfordern.
An einen DNS-Server können zwei Arten von Abfragen gestellt werden:
 Rekursiv
 Iterativ
Eine rekursive Abfrage zwingt einen DNS-Server, auf eine Anforderung entweder mit einem
Fehler oder mit einer erfolgreichen Antwort zu reagieren. Auflöser stellen in der Regel
rekursive Abfragen. Bei einer rekursiven Abfrage muss der DNS-Server alle anderen DNSServer kontaktieren, die zum Auflösen der Anforderung erforderlich sind. Wenn er eine
erfolgreiche Antwort von dem bzw. den anderen Servern erhält, sendet er eine Antwort an
den Client. Die rekursive Abfrage ist typisch für einen Auflöser, der einen Namenserver
abfragt, und für einen Namenserver, der seinen Weiterleitungsserver (ein anderer
Namenserver, der zur Behandlung von an ihn weitergeleiteten Anforderungen konfiguriert
ist) abfragt.
Wenn ein DNS-Server eine rekursive Abfrage verarbeitet und eine Abfrage anhand der
lokalen Zonendateien nicht aufgelöst werden kann, muss die Abfrage an einen Stamm-DNSServer weitergeleitet werden. Jede standardbasierte Implementierung von DNS umfasst
eine Cachedatei (die Stammserverhinweise), die Einträge für Stammserver (Root Servers)
von Internetdomänen enthält. Die neueste Version der Cachedatei kann von InterNIC unter
ftp://rs.internic.net/domain/named.cache gedownloadet werden.
Bei einer iterativen Abfrage wird erwartet, dass der Namenserver die bestmöglichen
Informationen, die aus lokalen Zonendateien oder zwischengespeicherten Einträgen
ermittelbar sind, liefert (falls der Server nicht autorisierend für den Namen ist, werden diese
Informationen auch als Referenz bezeichnet). Wenn ein Namenserver über keinerlei
Informationen verfügt, um die Abfrage zu beantworten, sendet er eine negative Antwort.
Ein nicht weiterleitender DNS-Server stellt diese Art von Abfrage, wenn er versucht, Namen
außerhalb seiner lokalen Domäne(n) zu finden. Unter Umständen muss er mehrere DNSServer außerhalb der Domäne abfragen, um den Namen aufzulösen.
Die folgende Abbildung zeigt ein Beispiel für beide Abfragearten.
In dem Beispiel werden folgende Abfragen verwendet, um die IP-Adresse für
http://www.whitehouse.gov zu ermitteln:
 Rekursive Abfrage für http://www.whitehouse.gov (A-Ressourceneintrag)
 Iterative Abfrage für http://www.whitehouse.gov (A-Ressourceneintrag)
 Referenz auf den Namenserver für gov (NS-Ressourceneinträge für gov); zur
Vereinfachung wurden iterative A-Abfragen durch den DNS-Server (auf der linken
Seite) zur Auflösung der IP-Adressen der Hostnamen der Namenserver, die von
anderen DNS-Servern zurückgegeben wurden, weggelassen.
 Iterative Abfrage für http://www.whitehouse.gov (A-Ressourceneintrag)
 Referenz auf den Namenserver für whitehouse.gov (NS-Ressourceneintrag für
whitehouse.gov)
 Iterative Abfrage für http://www.whitehouse.gov (A-Ressourceneintrag)
 Antwort des Servers von whitehouse.gov (IP-Adresse von www.whitehouse.gov)
 Antwort vom lokalen DNS-Server an den Auflöser (IP-Adresse von
www.whitehouse.gov)
Gültigkeitsdauer von Ressourceneinträgen
Ein Auflöser speichert die Informationen, die er beim Auflösen von Abfragen empfängt, in
einem Cache. Mithilfe der zwischengespeicherten Antworten können nachfolgende Abfragen
nach denselben Informationen beantwortet werden. Die zwischengespeicherten Daten
haben jedoch eine beschränkte Gültigkeitsdauer, die im mit den Daten gelieferten
Parameter Gültigkeitsdauer (Time To Live, TTL) angegeben ist. Durch die Gültigkeitsdauer
wird sichergestellt, dass der DNS-Server Informationen nicht länger speichert als sie aktuell
sind. Die Gültigkeitsdauer für den Cache kann ebenso in der DNS-Datenbank (pro
Ressourceneintrag durch Angeben des TTL-Feldes des Eintrags und pro Zone durch das
Minimum TTL-Feld des SOA-Eintrags) festgelegt werden wie auf der Auflöserseite (durch
Angeben der maximalen Zeit, für die der Auflöser das Speichern der Ressourceneinträge
zulässt).
Beim Festlegen der Gültigkeitsdauer sind zwei konkurrierende Faktoren zu berücksichtigen.
Einerseits die Genauigkeit der zwischengespeicherten Informationen und andererseits die
Auslastung der DNS-Server und des Netzwerks. Bei einer kurzen Gültigkeitsdauer sinkt die
Wahrscheinlichkeit, dass die Informationen veraltet sind, erheblich, während die Auslastung
der DNS-Server und des Netzwerks steigt. Bei einer langen Gültigkeitsdauer werden die
zwischengespeicherten Antworten möglicherweise veralten, so dass der Auflöser unter
Umständen falsche Antworten auf Abfragen gibt. Gleichzeitig senkt eine lange
Gültigkeitsdauer die Auslastung der DNS-Server und des Netzwerks. Wenn eine Abfrage mit
einem Eintrag aus dem Cache beantwortet wird, wird mit der Antwort die Gültigkeitsdauer
des Eintrags geliefert. Auf diese Weise wissen die Auflöser, die die Antwort erhalten, wie
lang der Eintrag gültig ist. Die Auflöser akzeptieren die Gültigkeitsdauer vom antwortenden
Server und legen sie nicht entsprechend ihrer eigenen Gültigkeitsdauer neu fest. Somit
verfallen Einträge wirklich, statt durch die Bewegung von Server zu Server mit einer
aktualisierten Gültigkeitsdauer unbegrenzt erhalten zu bleiben.
Aktualisieren der DNS-Datenbank
Da die Ressourceneinträge in den Zonendateien Änderungen unterliegen, müssen sie
aktualisiert werden. Die Implementierung von DNS in Windows 2000 unterstützt sowohl
statische als auch dynamische Aktualisierungen der DNS-Datenbank. Einzelheiten der
dynamischen Aktualisierung werden weiter unten in diesem Dokument erörtert.
Neue Funktionen von Windows 2000-DNS
Windows 2000-DNS bietet folgende neue Funktionen:
 Integration des Active Directory-Dienstes
 Inkrementelle Zonenübertragung (IXFR)
 Dynamische Aktualisierung und sichere dynamische Aktualisierung
 Unterstützung von Unicode-Zeichen
 Erweiterter Domänenlocator
 Erweiterter Cacheauflösungsdienst
 Erweiterter DNS-Manager
Integration der Active Directory-Speicherung und Replikation
Die Implementierung von DNS in Windows 2000 unterstützt nicht nur die konventionelle Art
der Wartung und Replikation von DNS-Zonendateien, sondern bietet auch die Option, die
Active Directory-Dienste als Datenspeicherungs- und Replikationsmodul zu verwenden.
Dieser Ansatz hat folgende Vorteile:
 Da die DNS-Replikation vom Active Directory-Dienst ausgeführt wird, muss keine
gesonderte Replikationstopologie für DNS-Server unterstützt werden.
 Die Replikation durch den Active Directory-Dienst ermöglicht die Replikation
einzelner Eigenschaften.
 Die Replikation durch den Active Directory-Dienst ist sicher.
 Ein primärer DNS-Server kann kein Einzelpunkt-Versagen mehr verursachen. Die
ursprüngliche DNS-Replikation beruht als Einzelmasterreplikation auf einem primären
DNS-Server, von dem alle sekundären Server aktualisiert werden. Im Gegensatz zur
ursprünglichen DNS-Replikation handelt es sich bei der Replikation des Active
Directory-Dienstes um eine Multimasterreplikation; Änderungen können an jedem
Domänencontroller vorgenommen werden und werden an andere Domänencontroller
verbreitet. Somit synchronisiert das Replikationsmodul, wenn DNS in den Active
Directory-Dienst integriert ist, immer die DNS-Zoneninformationen.
Auf diese Weise vereinfacht die Integration in den Active Directory-Dienst die Verwaltung
eines DNS-Namespace. Gleichzeitig wird die standardmäßige Zonenübertragung auf andere
Server (andere DNS-Server als Windows 2000-DNS und frühere Versionen von Microsoft
DNS-Servern) weiterhin unterstützt.
Das Speichermodell des Active Directory-Dienstes
Der Active Directory-Dienst ist eine objektorientierte X.500-kompatible Datenbank, die im
Netzwerk verfügbare Ressourcen in einer hierarchischen Baumstruktur organisiert. Diese
Datenbank wird durch die Domänencontroller (DC) verwaltet. Der Teil der Active DirectoryDatenbank, für den ein bestimmter Domänencontroller autorisierend ist, befindet sich
physisch auf demselben Computer wie der Domänencontroller. Jede Ressource in Active
Directory wird durch ein Objekt repräsentiert. Zwei Typen von Objekten werden vom Active
Directory-Dienst unterstützt:
 Container: Objekte, die andere Container- und Endknotenobjekte enthalten können
 Endknoten: Objekte, die eine bestimmte Ressource in der Active Directory-Struktur
darstellen
Mit jedem Objekt des Active Directory-Dienstes sind Attribute verknüpft, die bestimmte
charakteristische Eigenschaften des Objekts definieren.
Die Objektklassen in der Active Directory-Datenbank sind ebenso wie die Attribute jedes
Objekts im Schema des Active Directory-Dienstes definiert. Anders ausgedrückt, enthält das
Schema Definitionen für jedes im Active Directory-Dienst verfügbare Klassenobjekt.
Beispiele für Klassenobjekte des Active Directory-Dienstes:
 Benutzer
 Gruppe
 Organisationseinheit
 DnsZone
 DnsNode
Bei einem verzeichnisdienstintegrierten DNS wird jede DNS-Zone zu einem Active DirectoryContainerobjekt (DnsZone). Das DnsZone-Objekt enthält ein DnsNode-Endknotenobjekt
für jeden eindeutigen Namen in dieser Zone. Das DnsNode-Objekt hat ein mehrwertiges
DnsRecord-Attribut mit einer Instanz eines Wertes für jeden mit dem Objektnamen
verknüpften Eintrag.
Im oben abgebildeten Bildschirmabbild besitzt das Objekt mail.mydomain.microsoft.com.
möglicherweise das A-Attribut mit der IP-Adresse für mail.mydomain.microsoft.com. und
das MX-Attribut mit den Mail-Exchange-Server-Informationen für
mail.mydomain.microsoft.com.
Anmerkung Nur ein DNS-Dienst, der auf einem Domänencontroller ausgeführt wird, kann
verzeichnisdienstintegrierte Zonen laden.
Das Replikationsmodell
Da die DNS-Zoneninformationen jetzt im Active Directory-Dienst gespeichert werden, kann
ein DNS-Server, auf dem eine Aktualisierung vorgenommen wird, einfach die Daten in das
Active Directory schreiben und seine normale Funktion fortsetzen. Der Active DirectoryDienst ist jetzt für die Replikation der Daten auf die anderen Domänencontroller zuständig.
Die DNS-Dienste auf anderen Domänencontrollern rufen die Aktualisierungen vom
Verzeichnisdienst ab.
Da Active Directory das Multimasterreplikationsmodell verwendet, können DNSAktualisierungen auf jeden verzeichnisdienstintegrierten DNS-Server geschrieben werden,
und die Daten werden automatisch auf alle Domänencontroller repliziert. Das
Multimasterreplikationsmodell birgt allerdings einige erwähnenswerte Probleme. Die
Möglichkeit, von mehreren Domänencontrollern aus gleichzeitig in das Active Directory zu
schreiben, kann zu einer Konfliktsituation führen, bei der auf zwei verschiedenen DNSServern Änderungen an demselben Objekt vorgenommen werden. Der Konflikt wird
schließlich entsprechend den Zeitstempeln der Aktualisierungen zugunsten der letzten an
dem Objekt vorgenommenen Aktualisierung gelöst. Die gleiche Regel wird angewendet,
wenn zwei oder mehr Knoten mit demselben Namen auf zwei oder mehr DNS-Servern
erstellt werden. Bis der Konflikt gelöst wird und der DNS-Server, der eine ungültige
Aktualisierung enthält, die gültigen Daten vom Verzeichnisdienst abruft, werden
möglicherweise Anforderungen für dasselbe Objekt, die an zwei verschiedene DNS-Server
gestellt werden, unterschiedlich aufgelöst. Aus diesem Grund wird die Active DirectoryDatenbank als lose konsistent bezeichnet.
Anmerkung In diesem Unterabschnitt wurde nur das Modell der Replikation zwischen
verschiedenen Kopien der verzeichnisdienstintegrierten Zonen beschrieben. Implementiert
sind zwei weitere Replikationsmodelle, die der Zonenübertragung zwischen nicht
verzeichnisdienstintegrierten primären und sekundären Zonendateien und zwischen
verzeichnisdienstintegrierten primären und sekundären Zonendateien entsprechen. Diese
werden weiter unten in den Abschnitten "Protokollbeschreibung" bzw. "IXFR und
Verzeichnisdienstintegration" beschrieben.
Zonentypkonvertierungen
Jeder Typ einer vorhandenen DNS-Zone kann in jeden anderen Typ konvertiert werden. Die
Aspekte der Konvertierung der primären Zone sind am meisten von Interesse.
Wenn eine verzeichnisdienstintegrierte Zone in eine ursprüngliche (nicht
verzeichnisdienstintegrierte) primäre Zonendatei konvertiert wird, muss der DNS-Server,
der die neue primäre Zone lädt, für die Aktualisierung zum einzigen primären Server der
Zone werden. Daher muss die konvertierte Zone aus dem Active Directory-Dienst gelöscht
werden (von allen Domänencontroller-Datenbanken, die zuvor autorisierend für diese Zone
waren), so dass die veralteten oder fehlerhaften Informationen nicht repliziert
werden.
Steuern des Zugriffs auf Zonen
Die Integration in Active Directory bringt eine weitere wertvolle Funktion mit sich: sichere
dynamische DNS-Aktualisierungen. Der Verzeichnisdienst verwaltet Zugriffssteuerungslisten
(Access Control Lists, ACLs), in denen Gruppen oder Benutzer angegeben sind, die die
verzeichnisdienstintegrierten Zonen ändern können.
Anmerkung Beachten Sie, dass nur der DNS-Server sichere dynamische Aktualisierungen
für die verzeichnisdienstintegrierten Zonen unterstützt. Die Windows 2000-Implementierung
ermöglicht eine noch feinere Granularität, da sie die Angabe einzelner Namen in ACLs
zulässt. Weitere Informationen zu ACLs und bestimmten administrativen Gruppen finden Sie
weiter unten in "Steuern des Aktualisierungszugriffs auf Zonen und Namen".
Inkrementelle Zonenübertragung
Um die Verzögerung bei der Verbreitung von Änderungen an einer DNS-Datenbank zu
verringern, muss ein Algorithmus eingeführt werden, der Namenserver aktiv von der
Änderung benachrichtigt. Dies wird durch die NOTIFY-Erweiterung von DNS erreicht. Das
von einem Masterserver gesendete NOTIFY-Paket enthält keine Informationen zu
Zonenänderungen. Es benachrichtigt lediglich die andere Partei darüber, dass Änderungen
an einer Zone vorgenommen wurden und dass eine Zonenübertragung durchgeführt werden
muss.
Der Mechanismus der vollständigen Zonenübertragung (AXFR) stellt kein effizientes Mittel
zur Verbreitung von Änderungen an einer Zone dar, da die gesamte Zonendatei übertragen
wird. Die inkrementelle Zonenübertragung (IXFR) ist effizienter, da sie nur den geänderten
Teil der Zone überträgt. Das IXFR-Protokoll ist in RFC 1995 definiert.
Protokollbeschreibung
Wenn ein IXFR-fähiger Slavenamenserver (IXFR-Client) eine Zonenübertragung auslöst,
sendet er eine IXFR-Nachricht mit der SOA-Seriennummer seiner Kopie der Zone.
Ein Masternamenserver, der auf die IXFR-Anforderung antwortet (IXFR-Server), führt eine
Aufzeichnung der neuesten Version der Zone und der Unterschiede zwischen dieser Kopie
und mehreren älteren Versionen. Wenn der IXFR-Server eine IXFR-Anforderung mit einer
älteren Seriennummer empfängt, sendet er nur die Änderungen, die erforderlich sind, um
die Version des IXFR-Clients auf den neuesten Stand zu bringen. Unter den folgenden
Voraussetzungen ist jedoch eine vollständige Zonenübertragung einer inkrementellen
vorzuziehen:
 Der Umfang der Änderungen ist größer als die gesamte Zone.
 Aus Leistungsgründen wird nur eine begrenzte Anzahl der letzten Änderungen an der
Zone auf dem Server aufbewahrt. Falls die Seriennummer des Clients niedriger ist
als die in den Änderungsaufzeichnungen des Servers vorhandenen, wird eine
vollständige Zonenübertragung ausgelöst.
 Falls ein Namenserver, der auf die IXFR-Anforderung antwortet, den Abfragetyp nicht
erkennt, löst der IXFR-Client stattdessen automatisch eine vollständige Übertragung
(AXFR) aus.
Im folgenden Diagramm ist der Mechanismus der inkrementellen Übertragung im Einzelnen
dargestellt.
IXFR und Verzeichnisdienstintegration
Wie erwähnt handelt es sich bei IXFR um ein reihenfolgenbasiertes Protokoll, bei dem die
Zonenänderungen entsprechend den Unterschieden in den Seriennummern der Zonen
gesendet werden. In einer verzeichnisdienstintegrierten Multimasterumgebung können die
Änderungen an einer DNS-Zone auf jedem beliebigen Masterserver angewendet werden. Auf
diese Weise enthalten die verschiedenen Masterserver die angewendeten Zonenänderungen
in einer unterschiedlichen Reihenfolge. Dies kann zu Problemen führen, wenn ein MasterIXFR-Server, der beim letzten Mal die Zonenänderungen an einen IXFR-Client geliefert hat,
nicht verfügbar ist. Falls der IXFR-Client einen anderen Masterserver auswählt, auf dem die
Zonenänderungen in einer anderen Reihenfolge angewendet wurden, ist nach der
inkrementellen Übertragung unter Umständen die Integrität der Zone des IXFR-Clients
verletzt. In diesem Fall fordert der Server, der eine Zonenübertragung auslöst, eine
vollständige Übertragung (AXFR) an.
Zusammengefasst kann der DNS-Server gleichzeitig sowohl Slave als auch Master für
dieselbe Zone sein. Dieser Fall tritt ein, wenn die Zone vom Master, Server1, zum Slave,
Server2, und weiter vom Master, Server2, zum Slave, Server3, repliziert wird. (Die Kette
könnte weiter fortgesetzt werden, unterliegt jedoch unabhängig von ihrer Länge den in
diesem Abschnitt beschriebenen Regeln.) In diesem Szenario unterstützt Server2
inkrementelle Übertragungen (IXFR) an Server3, solange er inkrementelle Übertragungen
von Server1 empfängt.
Dynamische Aktualisierung
In einer herkömmlichen DNS-Implementierung muss der Administrator die Zonendatei
manuell bearbeiten, wenn Autorisierungsinformationen geändert werden müssen. DNS
wurde ursprünglich für Abfragen einer statisch konfigurierten Datenbank konzipiert. Da
Datenänderungen relativ selten erwartet wurden, erfolgten alle Aktualisierungen durch
externes Bearbeiten der primären Masterdatei einer Zone.
Durch die Einführung der dynamischen, automatisierten IP-Adressierung mithilfe von DHCP
und verwandten Protokollen wurde die manuelle Aktualisierung von DNS-Informationen
unzureichend und unbrauchbar. Selbst in einer Netzwerkumgebung mittlerer Größe kann
von keinem menschlichen Administrator erwartet werden, dynamische Adresszuweisungen
nachzuverfolgen. Die automatische Adresszuweisung musste in die dynamische DNSAktualisierung integriert werden. Diese Funktionalität, die dynamische Aktualisierung
(Dynamic Update), ist in RFC 2136 definiert.
Protokollbeschreibung
Der Windows 2000-DNS-Dienst unterstützt dynamisches DNS (DDNS) nach RFC 2136. Der
RFC führt einen neuen Opcode bzw. ein neues Nachrichtenformat UPDATE ein. Mit der
Aktualisierungsnachricht können Ressourceneinträge zu einer angegebenen Zone
hinzugefügt oder daraus gelöscht werden sowie auf Bedingungen überprüft werden. Die
Aktualisierung ist atomar, eine Aktualisierung findet also nur dann statt, wenn alle
Voraussetzungen erfüllt sind.
Wie in jeder herkömmlichen DNS-Implementierung muss die Zonenaktualisierung auf einem
primären Namenserver für diese Zone ausgeführt werden. Wenn ein sekundärer Server eine
Aktualisierung empfängt, wird sie entlang der Replikationstopologie weitergeleitet, bis sie
den primären Server erreicht. Beachten Sie, dass im Fall einer verzeichnisdienstintegrierten
Zone eine Aktualisierung eines Eintrags in der Zone an jeden DNS-Dienst gesendet werden
kann, der auf einem Domänencontroller, dessen Verzeichnisdienst die Zone enthält,
ausgeführt wird.
Bei der Zonenübertragung wird immer eine Zone gesperrt, so dass ein sekundärer Server
während der Übertragung der Zonendaten eine konsistente Zonenansicht erhält. Eine
gesperrte Zone kann keine dynamischen Aktualisierungen entgegennehmen. Wenn eine
Zone groß ist und sehr häufig wegen Zonenübertragungen gesperrt wird, werden Clients
dynamischer Aktualisierungen blockiert, und das System kann instabil werden. Der Windows
2000-DNS-Server speichert die Aktualisierungsanforderungen, die während der
Zonenübertragung eintreffen, in einer Warteschlange und verarbeitet sie nach Abschluss der
Zonenübertragung.
Aktualisierungsalgorithmus
Die Aktualisierungssequenz besteht aus folgenden Schritten:
 Ein Client sucht mithilfe einer SOA-Abfrage den primären DNS-Server und
Zonenautorisierenden für den zu registrierenden Eintrag.


Der Client sendet an den gefundenen DNS-Server eine Assertion oder
Voraussetzungsaktualisierung, um das Vorhandensein einer Registrierung zu
überprüfen. Falls die Registrierung nicht vorhanden ist, sendet der Client das
entsprechende Paket für die dynamische Aktualisierung, um den Eintrag zu
registrieren.
Schlägt die Aktualisierung fehl, versucht der Client den Eintrag auf einem anderen
primären DNS-Server zu registrieren, sofern die autorisierende Zone eine
Multimasterzone ist. Falls keiner der primären DNS-Server die dynamische
Aktualisierung verarbeiten konnte, wird die dynamische Aktualisierung nach 5
Minuten und gegebenenfalls nach weiteren 10 Minuten wiederholt. Schlug die
Registrierung noch immer fehl, wird das beschriebene Muster von
Registrierungsversuchen 50 Minuten nach dem letzten Versuch wiederholt.
Dynamische Aktualisierung von DNS-Einträgen
Jeder Computer unter Windows 2000 versucht seine A- und PTR-Einträge zu registrieren.
Der Dienst, der die dynamischen Aktualisierungen von DNS tatsächlich generiert, ist der
DHCP-Client. Der DHCP-Clientdienst wird auf jedem Computer ausgeführt, unabhängig
davon, ob er als DHCP-Client konfiguriert ist.
Der Algorithmus der dynamischen Aktualisierung unterscheidet sich je nach dem Typ des
Clientnetzwerkadapters, der an der dynamischen Aktualisierung beteiligt ist. Die folgenden
drei Szenarios werden untersucht:
 DHCP-Client
 Statisch konfigurierter Client
 RAS-Client
DHCP-Client
Beim Bootstrapping eines Windows 2000-DHCP-Clients handelt dieser das dynamische
Aktualisierungsverfahren mit einem DHCP-Server aus. Standardmäßig schlägt der DHCPClient immer vor, den A-Ressourceneintrag zu aktualisieren, während der DHCP-Server den
PTR-Ressourceneintrag aktualisiert.
Der Windows 2000-DHCP-Server kann entweder so konfiguriert werden, dass er aufgrund
von Clientanforderungen aktualisiert wird (Standardeinstellung) oder dass Forward- und
Reverse-Lookups immer aktualisiert werden.
Falls der DHCP-Server mit Immer Forward- und Reverse-Lookups aktualisieren
konfiguriert ist, werden unabhängig von der Anforderung des DHCP-Clients sowohl A- als
auch PTR-Ressourceneinträge aktualisiert.
Falls der DHCP-Server für dynamische Aktualisierungen deaktiviert ist, versucht der DHCPClient sowohl A- als auch PTR-Ressourceneinträge selbst zu aktualisieren.
Bei Ablauf des IP-Adresslease müssen diese Einträge aus den betreffenden Zonen entfernt
werden. Das dynamische Cleanup erfordert, dass die Einträge durch den/die registrierenden
Computer gelöscht werden (in diesem Fall durch den DHCP-Client bzw. den DHCP-Server
oder beide) durch den/die sie erstellt wurden. Somit kann es vorkommen, dass ein A- oder
PTR-Ressourceneintrag veraltet ist, da der Computer, der ihn erstellt hat, vor Ablauf des
Lease vom Netzwerk getrennt wurde. Da der DHCP-Server der Besitzer der IP-Adresse ist,
sollten möglichst DHCP-Server die Registrierung von PTR-Einträgen durchführen.
Gemischte Umgebung
Unter Umständen versucht ein Windows 2000-DHCP-Client das dynamische
Aktualisierungsverfahren mit dem Windows NT 4.0-DHCP-Server (oder einem anderen
DHCP-Server, der keine dynamische Aktualisierung von DNS unterstützt) auszuhandeln. Da
der Windows NT 4.0-DHCP-Server dynamische Aktualisierungen nicht unterstützt, muss der
Windows 2000-DHCP-Client dann sowohl die A- als auch die PTR-Ressourceneinträge selbst
aktualisieren.
Im umgekehrten Fall, bei Clients mit Vorgängerversionen (z. B. Windows 95, Windows 98
und Windows NT 4.0), registriert der Windows 2000-DHCP-Server nach der Aushandlung
eines Lease mit einem Client die A- und PTR-Einträge in DNS, falls die Option
Aktualisierung für DNS-Clients, die dynamisches Aktualisieren nicht unterstützten,
aktivieren in der Konfiguration des DHCP-Servers aktiviert ist.
Anmerkung zum DHCP-Server
Wenn das Lease des DHCP-Clients abläuft, entfernt der DHCP-Server den PTRRessourceneintrag des Clients. Falls auf dem DHCP-Server Forward-Lookups (Name zu
Adresse) bei Ablauf des Lease löschen aktiviert ist, entfernt er die entsprechenden AEinträge ebenfalls.
Statisch konfigurierter Client
Ein statisch konfigurierter Client kommuniziert nicht mit dem DHCP-Server und aktualisiert
dynamisch die A- und PTR-Ressourceneinträge bei jedem Start sowie bei jeder Änderung
seiner IP-Adresse oder des netzwerkadapterspezifischen Domänennamens.
RAS-Client
Ein RAS-Client verhält sich insofern wie ein statisch konfigurierter Client, als keine
Interaktion zwischen dem Client und dem DHCP-Server stattfindet. Der Client ist
verantwortlich für die dynamische Aktualisierung der A- und PTR-Ressourceneinträge. Der
RAS-Client versucht vor dem Schließen der Verbindung beide Einträge zu löschen; falls die
Aktualisierung jedoch aus irgendeinem Grund fehlschlägt (z. B. weil der DNS-Server zu dem
Zeitpunkt nicht aktiv ist), bleiben die Einträge als veraltete Einträge bestehen. Auch wenn
die Leitung unerwartet unterbrochen wird, veralten die Einträge. In diesen Fällen versucht
ein RAS-Server, die Registrierung des entsprechenden PTR-Eintrags aufzuheben.
Erneutes Registrieren von Clients
Einer der Vorteile der dynamischen Aktualisierung ist die Möglichkeit, Ressourceneinträge in
DNS erneut zu registrieren. Auf diese Weise wird ein gewisser Grad an Fehlertoleranz für
den Fall erzielt, dass einige Einträge in einer Zone beschädigt werden. Ein DHCP-Server
registriert automatisch die DNS-Einträge erneut, die er beim Erneuern des Lease registriert
hat. Die Windows 2000-basierten Clients registrieren ihre DNS-Einträge alle 24 Stunden
erneut. Dieser Wert kann durch die Angabe des REG_DWORD-Wertes
DefaultRegistrationRefreshInterval unter dem Registrierungsschlüssel
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters geändert werden.
Anmerkung Wenn ein Client eine Registrierung in DNS vornimmt, enthalten die
zugehörigen Ressourceneinträge standardmäßig eine Gültigkeitsdauer (TTL) von 20
Minuten. Dieser Wert kann durch die Angabe des REG_DWORD-Wertes
DefaultRegistrationTtl unter dem Registrierungsschlüssel
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters geändert werden.
Behandeln von Namenskonflikten
Falls bei der dynamischen Aktualisierungsregistrierung ein Client feststellt, dass sein Name
bereits mit einer zu einem anderen Computer gehörigen IP-Adresse in DNS registriert ist,
löscht der Client standardmäßig die vorhandene Registrierung und registriert stattdessen
seine eigenen Ressourceneinträge. Dieses Verhalten kann mithilfe des betreffenden
Registrierungsschlüssels deaktiviert werden, so dass der Client den Registrierungsvorgang
abbricht und den Fehler in der Ereignisanzeige protokolliert. Das erste Szenario ermöglicht
Ihnen das Entfernen veralteter Einträge, ist jedoch anfällig für missbräuchliche Eingriffe.
Das zweite Szenario hat den gegenteiligen Effekt. Das Problem, dass bei Namenskonflikten
vorhandene Einträge gelöscht werden, wird gelöst durch die im nächsten Abschnitt
beschriebenen sicheren dynamischen Aktualisierungen. In diesem Fall kann nur der Besitzer
des vorhandenen Eintrags diesen aktualisieren.
Sichere dynamische Aktualisierung
Die verzeichnisintegrierten Zonen können zur Verwendung einer sicheren dynamischen
Aktualisierung konfiguriert werden. Zugriffssteuerungslisten geben, wie in "Steuern des
Zugriffs auf Zonen" erläutert, die Liste von Gruppen oder Benutzern an, die
Ressourceneinträge in solchen Zonen aktualisieren dürfen. Die Windows 2000Implementierung der sicheren dynamischen Aktualisierung basiert auf dem Algorithmus, der
im Internet Draft "GSS Algorithm for TSIG (GSS-TSIG)" definiert ist. Dieser Algorithmus
basiert auf der GSS-API (Generic Security Service Application Program Interface), die in RFC
2078 spezifiziert ist. Sie stellt unabhängig vom zugrunde liegenden Sicherheitsmechanismus
Sicherheitsdienste bereit und teilt die Sicherheitsdienste in folgende Vorgänge auf:
 Einrichten eines Sicherheitskontextes durch Übergeben von Sicherheitstokens.
 Ein eingerichteter Sicherheitskontext hat eine begrenzte Gültigkeitsdauer, während
derer er zum Erstellen und Überprüfen von Transaktionssignaturen in Nachrichten
zwischen den beiden Parteien verwendet werden kann.
Im Folgenden wird die Sequenz der Ereignisse bei der sicheren dynamischen Aktualisierung
beschrieben.
In Schritt 1 fragt der Client den lokalen Namenserver ab, um den autorisierenden Server für
den Namen, den er zu aktualisieren versucht, zu ermitteln. Der lokale Namenserver
antwortet mit der Referenz auf den autorisierenden Server.
In Schritt 2 fragt der Client den autorisierenden Server ab, um zu überprüfen, ob er
autorisierend für den Namen ist, den der Client zu aktualisieren versucht. Der Server
bestätigt dies.
In Schritt 3 versucht der Client eine nicht sichere Aktualisierung, die der Server verweigert.
Wäre der Server statt für sichere für nicht sichere dynamische Aktualisierungen der
betreffenden Zone konfiguriert, hätte er stattdessen versucht, die Aktualisierung
auszuführen.
In Schritt 4 beginnen Client und Server mit der Aushandlung des Sicherheitskontextes. Sie
tauschen ein oder mehrere Sicherheitstokens aus (in Abhängigkeit vom zugrunde liegenden
Sicherheitsanbieter), wobei der TKEY-Ressourceneintrag als Mittel zur Übertragung von
Sicherheitstokens zwischen Client und Server dient. Der TKEY-Ressourceneintrag ist im
Internet Draft "Secret Key Establishment for DNS (TKEY RR)" spezifiziert.
Zunächst handeln Client und Server einen zugrunde liegenden Sicherheitsmechanismus aus.
Clients und Server, die die dynamische Aktualisierung unter Windows 2000 verwenden,
schlagen Kerberos vor; somit würde in diesem Fall Kerberos verwendet. Anschließend
überprüfen sie mithilfe von Kerberos gegenseitig ihre Identität.
Nachdem der Sicherheitskontext aufgebaut wurde, wird er verwendet, um
Transaktionssignaturen in Nachrichten zwischen Client und Server zu erstellen und zu
überprüfen.
In Schritt 5 sendet der Client die signierte Anforderung der dynamischen Aktualisierung an
den Server. Zur Übertragung der Signaturen verwenden Client und Server den TSIGRessourceneintrag, der im Internet Draft "Secret Key Transaction Signatures for DNS"
(TSIG) spezifiziert ist.
In Schritt 6 versucht der Server die Aktualisierung an Active Directory vorzunehmen. Ob er
dabei erfolgreich ist, hängt davon ab, ob der Client über die erforderlichen Berechtigungen
zum Ausführen der Aktualisierung verfügt und ob die Voraussetzungen erfüllt sind.
In Schritt 7 sendet der Server eine mit dem TSIG-Ressourceneintrag signierte Antwort an
den Client, die besagt, ob die Aktualisierung durchgeführt werden konnte. Falls der Client
eine gefälschte Antwort empfängt, verwirft er diese und wartet auf eine signierte Antwort.
Richtlinien der sicheren dynamischen Aktualisierung
Wenn ein Client eine dynamische Aktualisierung auf dem DNS-Server versucht, kann er je
nach Konfiguration einen der folgenden Ansätze verfolgen:
 Zunächst eine nicht sichere dynamische Aktualisierung versuchen und, falls diese
fehlschlägt, eine sichere dynamische Aktualisierung aushandeln
(Standardkonfiguration)
 Immer eine sichere dynamische Aktualisierung aushandeln
 Nur eine nicht sichere dynamische Aktualisierung versuchen
Der Standardansatz wird empfohlen, da er dem Client eine Registrierung auf einem DNSServer erlaubt, der nicht zu einer sicheren dynamischen Aktualisierung in der Lage ist. Die
Standardeinstellung kann in der Registrierung geändert werden.
Steuern des Aktualisierungszugriffs auf Zonen und Namen
Active Directory steuert den Zugriff auf die sicheren DNS-Zonen und die darin enthaltenen
Namen über Zugriffssteuerungslisten (ACLs). Die ACLs können entweder für eine gesamte
Zone angegeben werden oder für einzelne Namen geändert werden. Standardmäßig kann
jeder authentifizierte Benutzer A- oder PTR-Ressourceneinträge in jeder Zone erstellen.
Sobald jedoch ein Besitzername erstellt wurde (unabhängig vom Typ des Eintrags), können
nur Benutzer oder Gruppen, die in der Zugriffssteuerungsliste für den Namen mit der
Berechtigung Schreiben aufgeführt sind, Einträge zu diesem Namen ändern. Dieses
Verhalten ist in den meisten Szenarios erwünscht, dennoch müssen einige besondere
Situationen getrennt betrachtet werden.
"DnsUpdateProxy"-Gruppe
Wie im Abschnitt "Gemischte Umgebung" dieses Dokuments beschrieben, kann ein DHCPServer so konfiguriert werden, dass er A- und PTR-Ressourceneinträge für Clients mit
Vorgängerversionen dynamisch registriert. In dieser Situation kann eine
Standardkonfiguration der sicheren Aktualisierung zu veralteten Einträgen führen. Das
folgende Beispiel erläutert dies. Wenn ein DHCP-Server eine sichere dynamische
Aktualisierung für einen Namen durchführt, wird der DHCP-Server zum Besitzer dieses
Namens, und nur dieser DHCP-Server kann den Namen aktualisieren. Dies kann in einigen
wenigen Situationen Probleme verursachen. Angenommen, der DHCP-Server DHCP1 hat ein
Objekt für den Namen myname.mycompany.com. erstellt und wurde dann
heruntergefahren, und der DHCP-Sicherungsserver DHCP2 versuchte den Namen zu
aktualisieren. Er könnte den Namen nicht aktualisieren, da er nicht der Besitzer ist. Ein
ähnliches Beispiel: Angenommen, DHCP1 hätte ein Objekt für den Namen
myname.mycompany.com. hinzugefügt und dann hätte der Administrator den Host
myname.mycompany.com. auf Windows 2000 aktualisiert. Da der Host
myname.mycompany.com. nicht Besitzer des Namens ist, könnte er seinen eigenen Namen
nicht aktualisieren.
Die Lösung für dieses Problem besteht in der Einführung einer neuen Gruppe mit dem
Namen DnsUpdateProxy. Ein von Mitgliedern dieser Gruppe erstelltes Objekt hat keine
Sicherheitsattribute, und der erste Benutzer (außer Mitgliedern von DnsUpdateProxy), der
auf einen Namen zugreift, wird sein Besitzer. Somit wird das Problem beseitigt, wenn jeder
DHCP-Server, der A-Einträge für Clients mit Vorgängerversionen registriert, Mitglied von
DnsUpdateProxy ist. Die DnsUpdateProxy-Gruppe ist über die Active DirectoryVerwaltung konfigurierbar. Gleichzeitig verursacht diese Lösung Sicherheitslücken, da alle
DNS-Namen, die von dem Computer registriert werden, auf dem der DHCP-Server
ausgeführt wird, nicht sicher sind. Der A-Ressourceneintrag für den Computer stellt
beispielsweise einen solchen Eintrag dar. Die Sicherheitslücken werden bedeutsamer, wenn
ein DHCP-Server (ein Mitglied der DnsUpdateProxy-Gruppe) auf einem Domänencontroller
installiert ist. In diesem Fall sind alle vom Anmeldedienst NetLogon registrierten SRV-, Aund CNAME-Einträge für diesen Domänencontroller nicht sicher. Um das Problem zu
minimieren, wird empfohlen, DHCP-Server nicht auf einem Domänencontroller zu
installieren. Ein weiteres starkes Argument gegen die Ausführung eines DHCP-Servers auf
einem Domänencontroller ist, dass ein solcher DHCP-Server Vollzugriff auf alle im Active
Directory gespeicherten DNS-Objekte besitzt, da der DHCP-Server unter dem
Computerkonto (in diesem Fall des Domänencontrollers) ausgeführt wird.
"DnsAdmins"-Gruppe
Standardmäßig hat die DnsAdmins-Gruppe Vollzugriff auf alle Zonen und Einträge in einer
Windows 2000-Domäne, in der sie angegeben ist. Damit ein Benutzer Zonen in einer
bestimmten Windows 2000-Domäne auflisten kann, muss er (oder eine Gruppe, der er
angehört) in der DnsAdmins-Gruppe aufgeführt sein. Andererseits ist es denkbar, dass ein
Domänenadministrator nicht allen Benutzern in der DnsAdmins-Gruppe eine so hohe
Ebene an Verwaltungsrechten (Vollzugriff) erteilen möchte. Üblicherweise möchte ein
Domänenadministrator einer Gruppe von Benutzern Vollzugriff für eine bestimmte Zone und
Nur Lesen-Zugriff für andere Zonen in der Domäne erteilen.
Erstellen Sie die Gruppen Zone1Admins, Zone2Admins usw. für die Zonen Zone1,
Zone2 usw. Dann enthält die Zugriffssteuerungsliste für ZoneN eine Gruppe
ZoneNAdmins mit Vollzugriff. Gleichzeitig werden die Gruppen Zone1Admins,
Zone2Admins usw. in die DnsAdmins-Gruppe aufgenommen. Die DnsAdmins-Gruppe
sollte ausschließlich über Lese-Berechtigung verfügen. Da die Zugriffssteuerungsliste einer
Zone immer die DnsAdmins-Gruppe enthält, besitzen alle in Zone1Admins,
Zone2Admins usw. aufgeführten Benutzer Lesezugriff für alle Zonen in der Domäne.
Die DnsAdmins-Gruppe ist über Active Directory-Benutzer und -Computer
konfigurierbar.
Reservieren von Namen
Die Standardkonfiguration, bei der jeder authentifizierte Benutzer einen neuen Namen in
einer Zone erstellen kann, ist für Umgebungen mit hohen Sicherheitsanforderungen
unzureichend. In solchen Fällen kann die Standard-ACL so geändert werden, dass das
Erstellen von Objekten in einer Zone nur bestimmten Gruppen oder Benutzern vorbehalten
bleibt. Die Pro Name-Granularität von Zugriffssteuerungslisten bietet eine andere Lösung für
das Problem. Ein Administrator kann einen Namen in einer Zone reservieren und den Rest
der Zone für die Erstellung neuer Objekte durch alle authentifizierten Benutzer geöffnet
lassen. Hierzu muss der Administrator einen Eintrag für den reservierten Namen erstellen
und die entsprechende Liste von Gruppen oder Benutzern in die Zugriffssteuerungsliste
aufnehmen. Dann können ausschließlich die in der Zugriffssteuerungsliste aufgeführten
Benutzer einen anderen Eintrag unter dem reservierten Namen registrieren.
Alterung (Aging) und Aufräumvorgang (Scavenging)
Bei der dynamischen Aktualisierung werden automatisch Einträge zur Zone hinzugefügt,
wenn Computer und Domänencontroller hinzugefügt werden. In manchen Fällen werden die
Einträge jedoch nicht automatisch gelöscht.
Durch veraltete Ressourceneinträge können unterschiedliche Probleme entstehen. Veraltete
Ressourceneinträge belegen einerseits Speicherplatz auf dem Server, andererseits
beantwortet ein Server eine Abfrage unter Umständen mit einem veralteten
Ressourceneintrag. Dies beeinträchtigt die Leistung des DNS-Servers.
Zur Lösung dieser Probleme kann der Windows 2000-DNS-Server veraltete Einträge
aufräumen, er kann die Datenbank nach veralteten Einträgen durchsuchen und diese
löschen. Administratoren können die Alterung und den Aufräumvorgang durch folgende
Angaben steuern:
 Welche Server Zonen aufräumen können
 Welche Zonen aufgeräumt werden können
 Welche Einträge aufgeräumt werden müssen, wenn sie veralten
Der DNS-Server verwendet einen Algorithmus, der sicherstellt, dass nicht versehentlich ein
noch benötigter Eintrag aufgeräumt wird (vorausgesetzt, Sie haben alle Parameter richtig
konfiguriert). Standardmäßig ist der Aufräummechanismus deaktiviert. Aktivieren Sie ihn
nur, wenn Sie absolut sicher sind, dass Sie die Bedeutung aller Parameter verstehen.
Andernfalls konfigurieren Sie den Server unter Umständen versehentlich so, dass Einträge
gelöscht werden, die beibehalten werden sollten. Wird ein Name versehentlich gelöscht,
können Benutzer keine Abfragen für den Namen mehr stellen. Zudem kann dann jeder
Benutzer diesen Namen in DNS erstellen und den Besitz übernehmen, auch in Zonen, die für
sichere dynamische Aktualisierungen konfiguriert sind.
Sie können die Alterung und den Aufräumvorgang pro Server, pro Zone oder pro Eintrag
manuell aktivieren bzw. deaktivieren. Mithilfe von Dnscmd.exe können Sie die Alterung
auch für Sätze von Einträgen aktivieren. Bedenken Sie jedoch Folgendes: Wenn Sie den
Aufräumvorgang für einen nicht dynamisch aktualisierten Eintrag aktivieren, wird dieser
gelöscht, sofern er nicht regelmäßig aktualisiert wird, und Sie müssen ihn gegebenenfalls
neu erstellen.
Ist der Aufräumvorgang für eine Standardzone deaktiviert und Sie aktivieren ihn, räumt der
Server Einträge, die vor dem Aktivieren des Aufräumvorgangs vorhanden waren, nicht auf.
Der Server räumt diese Einträge auch dann nicht auf, wenn Sie die Zone zuvor in eine
Active Directory-integrierte Zone konvertieren. Verwenden Sie Dnscmd.exe, um den
Aufräumvorgang für solche Einträge zu aktivieren.
Parameter für Alterung und Aufräumvorgang
Der Windows 2000-DNS-Server verwendet den Zeitstempel der Einträge zusammen mit von
Ihnen konfigurierten Parametern, um den Zeitpunkt des Aufräumvorgangs zu bestimmen.
In der folgenden Tabelle sind die Zonenparameter aufgeführt, die den Zeitpunkt des
Aufräumvorgangs beeinflussen. Sie konfigurieren diese Eigenschaften in der Zone.
Zonenparameter für Alterung und Aufräumvorgang
Zonenparamet Beschreibung Konfigurations Anmerkungen
er
tool
Zeitintervall
nach der letzten
Aktualisierung
des Zeitstempels
eines Eintrags,
während dessen
der Server keine
DNS-Konsole
NoRefreshInterv Erneuerungen
und
al
(Refresh) des
Dnscmd.exe
Eintrags
akzeptiert. (Der
Server
akzeptiert
jedoch weiterhin
Aktualisierungen
.)
Das
RefreshInterval
folgt auf das
NoRefreshInterv
al. Nach Ablauf
des
NoRefreshInterv
al beginnt der
Server,
Erneuerungen
für den Eintrag DNS-Konsole
RefreshInterval zu akzeptieren. und
Nachdem das
Dnscmd.exe
RefreshInterval
abgelaufen ist,
kann der DNSServer Einträge
aufräumen, die
während oder
nach dem
RefreshInterval
nicht erneuert
wurden.
Dieses Flag gibt DNS-Konsole
EnableScavengin
an, ob Alterung und
g
und
Dnscmd.exe
Der Parameter
wird beim
Erstellen einer
Active Directoryintegrierten
Zone auf den
Parameter
DefaultNoRefr
eshInterval
des DNSServers
festgelegt.
Der Parameter
wird durch
Active Directory
repliziert.
Der Parameter
wird beim
Erstellen einer
Active Directoryintegrierten
Zone auf den
Parameter
DefaultRefresh
Interval des
DNS-Servers
festgelegt.
Der Parameter
wird durch
Active Directory
repliziert.
Der Parameter
wird beim
Erstellen einer
Aufräumvorgang
für die Einträge
in der Zone
aktiviert sind.
Dieser
Parameter
bestimmt,
ScavengingServ welche Server
ers
Einträge in
dieser Zone
aufräumen
können.
Dieser
Parameter
bestimmt, wann
StartScavenging
ein Server mit
dem Aufräumen
dieser Zone
beginnen kann.
Active Directoryintegrierten
Zone auf den
Parameter
DefaultEnableS
cavenging des
DNS-Servers
festgelegt.
Der Parameter
wird durch
Active Directory
repliziert.
Nur
Dnscmd.exe
Der Parameter
wird durch
Active Directory
repliziert.
Nicht
konfigurierbar
Der Parameter
wird nicht durch
Active Directory
repliziert.
In der folgenden Tabelle sind die Serverparameter aufgeführt, die den Zeitpunkt des
Aufräumvorgangs beeinflussen. Sie legen diese Parameter auf dem Server fest.
Serverparameter für Alterung und Aufräumvorgang
Serverparamet
Konfigurations
Beschreibung
Anmerkungen
er
tool
Dieser Wert gibt
das
DNS-Konsole
erneuerungsfreie
(angezeigt als
Intervall an, das
Der
DefaultNoRefres
Kein
standardmäßig
Standardwert
hInterval
Aktualisierung
für eine auf
beträgt 7 Tage.
sintervall) und
diesem Server
Dnscmd.exe
erstellte Active
Directory-
integrierte Zone
verwendet wird.
Dieser Wert gibt
das
Aktualisierungsin
tervall an, das
DNS-Konsole
standardmäßig (angezeigt als
DefaultRefreshIn
für eine auf
Aktualisierung
terval
diesem Server
sintervall) und
erstellte Active Dnscmd.exe
Directoryintegrierte Zone
verwendet wird.
Dieser Wert gibt
den Parameter
DNS-Konsole
EnableScaveng
(angezeigt als
ing an, der
Aufräumvorga
standardmäßig
DefaultEnableSc
ng bei
für eine auf
avenging
veralteten
diesem Server
Einträgen
erstellte Active
aktivieren) und
DirectoryDnscmd.exe
integrierte Zone
verwendet wird.
Dieses Flag gibt
an, ob der DNSServer den
Aufräumvorgang
für veraltete
DNS-Konsole,
Einträge
Erweiterte
durchführen
Ansicht
kann. Wenn auf
(angezeigt als
einem Server
EnableScavengin
Aufräumvorga
der
g
ng bei
Aufräumvorgang
veralteten
aktiviert ist, wird
Einträgen
dieser
aktivieren) und
automatisch so
Dnscmd.exe
oft wiederholt,
wie im
Parameter
Zeitraum des
Aufräumvorga
Der
Standardwert
beträgt 7 Tage.
Standardmäßig
ist der
Aufräummechani
smus
deaktiviert.
Standardmäßig
ist der
Aufräummechani
smus
deaktiviert.
ngs angegeben
ist.
Dieser
Parameter gibt
ScavengingPerio an, wie oft ein
d
DNS-Server den
Aufräumvorgang
durchführt.
DNS-Konsole
(angezeigt als
Der
Zeitraum des
Standardwert
Aufräumvorga
beträgt 7 Tage.
ngs) und
Dnscmd.exe
Lebensdauer eines Eintrags
Die folgende Abbildung zeigt die Lebensdauer eines aufräumbaren Eintrags.
Wenn ein Eintrag in einer Active Directory-integrierten Zone oder in einer standardmäßigen
primären Zone, für die der Aufräumvorgang aktiviert ist, erstellt oder aktualisiert wird, wird
der Eintrag mit einem Zeitstempel versehen.
Aufgrund des hinzugefügten Zeitstempels unterscheidet sich das Format einer
standardmäßigen primären Zonendatei, für die der Aufräumvorgang aktiviert ist, geringfügig
von dem einer Standard-DNS-Zonendatei. Dies verursacht keine Probleme bei der
Zonenübertragung. Es ist jedoch nicht möglich, eine Standardzonendatei, für die der
Aufräumvorgang aktiviert ist, auf einen nicht Windows 2000-basierten DNS-Server zu
kopieren.
Der Wert des Zeitstempels gibt den Zeitpunkt an, zu dem der Eintrag erstellt oder zuletzt
aktualisiert wurde. Falls der Eintrag zu einer Active Directory-integrierten Zone gehört, wird
der Eintrag bei jeder Aktualisierung des Zeitstempels auf andere Domänencontroller in der
Domäne repliziert.
Standardmäßig werden die Zeitstempel von Einträgen, die mit anderen Verfahren als der
dynamischen Aktualisierung erstellt werden, auf Null (0) gesetzt. Ein Wert von Null zeigt an,
dass der Zeitstempel nicht aktualisiert werden darf und der Eintrag nicht aufgeräumt
werden darf. Ein Administrator kann die Alterung solcher Einträge manuell aktivieren.
Nachdem der Eintrag erneuert wurde, kann er innerhalb des Zeitraums, der durch das
erneuerungsfreie Intervall festgelegt ist, nicht erneuert werden. Der Zonenparameter Kein
Aktualisierungsintervall dient dazu, unnötiges Datenaufkommen durch die Active
Directory-Replikation zu verhindern.
Der Eintrag kann jedoch auch während des erneuerungsfreien Intervalls weiterhin
aktualisiert werden. Wenn eine dynamische Aktualisierungsanforderung eine Änderung eines
Eintrags erfordert, wird dies als Aktualisierung bezeichnet. Erfordert sie keine Änderung des
Eintrags, wird sie als Erneuerung bezeichnet. Daher werden auch
Voraussetzungsaktualisierungen (die eine Liste von Voraussetzungen, jedoch keine
Zonenänderungen enthalten) als Erneuerungen betrachtet.
Dem erneuerungsfreien Intervall folgt das Erneuerungsintervall. Nach Ablauf des
erneuerungsfreien Intervalls beginnt der Server, Erneuerungen zu akzeptieren. Der Eintrag
kann erneuert werden, sobald die aktuelle Zeit hinter dem durch Zeitstempel plus
erneuerungsfreies Intervall angegebenen Zeitpunkt liegt. Wenn der Server eine Erneuerung
oder eine Aktualisierung akzeptiert, wird der Wert des Zeitstempels in den aktuellen
Zeitpunkt geändert.
Anschließend kann der Server den Eintrag nach Ablauf des Erneuerungsintervalls
aufräumen, falls der Eintrag nicht erneuert wurde. Der Eintrag kann aufgeräumt werden,
falls die aktuelle Zeit hinter dem Zeitpunkt liegt, der durch den Wert des Zeitstempels plus
erneuerungsfreies Intervall plus Erneuerungsintervall gegeben ist. Der Server räumt den
Eintrag jedoch nicht notwendigerweise zu diesem Zeitpunkt auf. Die Zeit, zu der Einträge
aufgeräumt werden, hängt von verschiedenen Serverparametern ab.
Aufräumalgorithmus
Der Server kann so konfiguriert werden, dass der Aufräumvorgang automatisch in
regelmäßigen Abständen durchgeführt wird. Darüber hinaus können Sie den
Aufräumvorgang manuell auf einem Server auslösen, um ihn sofort auszuführen. Wenn der
Aufräumvorgang gestartet wird, versucht der Server alle primären Zonen aufzuräumen. Er
ist dabei erfolgreich, wenn die folgenden Bedingungen ausnahmslos erfüllt sind:
 Der EnableScavenging-Parameter ist auf dem Server auf 1 festgelegt.
 Der EnableScavenging-Parameter ist in der Zone auf 1 festgelegt.
 Die dynamische Aktualisierung ist in der Zone aktiviert.
 Der ScavengingServers-Zonenparameter ist nicht angegeben oder enthält die IPAdresse dieses Servers.
 Die aktuelle Zeit liegt hinter dem durch den StartScavenging-Zonenparameter
angegebenen Zeitpunkt.
Der Server legt StartScavenging fest, sobald eines der folgenden Ereignisse eintritt:
 Die dynamische Aktualisierung wird aktiviert.
 EnableScavenging wird in der Zone von 0 auf 1 festgelegt.
 Die Zone wird geladen.
 Die Zone wird fortgesetzt.
StartScavenging entspricht der Zeit, zu der eines der obigen Ereignisse eintritt, plus der
Zeit, die im Erneuerungsintervall für die Zone angegeben ist. Dies verhindert ein Problem,
das auftreten kann, wenn der Client Einträge nicht erneuern kann, weil die Zone nicht
verfügbar ist (beispielsweise wenn die Zone unterbrochen wurde oder der Server nicht in
Betrieb ist). Würde der Server in diesem Fall nicht StartScavenging verwenden, könnte
der Server die Zone aufräumen, bevor der Client die Gelegenheit zum Aktualisieren des
Eintrags hat.
Wenn der Server eine Zone aufräumt, überprüft er nacheinander alle Einträge in der Zone.
Ist der Zeitstempel nicht Null und liegt die aktuelle Zeit hinter dem Wert des Zeitstempels
für den Eintrag plus des erneuerungsfreien Intervalls und des Erneuerungsintervalls für die
Zone, wird der Eintrag gelöscht. Alle anderen Einträge sind vom Aufräumvorgang nicht
betroffen.
Konfigurieren der Parameter für den Aufräumvorgang
In diesem Abschnitt werden Gesichtspunkte erörtert, die Sie beim Konfigurieren der
Parameter für den Aufräumvorgang beachten müssen.
Damit Einträge nicht gelöscht werden, bevor der Client sie mit der dynamischen
Aktualisierung erneuern kann, muss das Erneuerungsintervall größer sein als der
Erneuerungszeitraum jedes Eintrags, der in einer Zone dem Aufräumvorgang unterworfen
ist. Zahlreiche Dienste erneuern Einträge in unterschiedlichen Intervallen. Beispielsweise
erneuert der Anmeldedienst Einträge stündlich, Clusterserver erneuern Einträge im
Allgemeinen alle 15 bis 20 Minuten, DHCP-Server erneuern Einträge bei der Erneuerung von
IP-Adressleases, und Windows 2000-basierte Computer erneuern ihre A- und PTRRessourceneinträge alle 24 Stunden.
Üblicherweise erfordert der DHCP-Dienst von allen Diensten das längste
Erneuerungsintervall. Wenn Sie den Windows 2000-DHCP-Dienst verwenden, können Sie die
Standardwerte für Alterung und Aufräumvorgang übernehmen. Falls Sie einen anderen
DHCP-Server verwenden, müssen Sie unter Umständen die Standardwerte ändern.
Je länger erneuerungsfreies Intervall und Erneuerungsintervall eingestellt sind, desto länger
bleiben veraltete Einträge bestehen. Daher scheint es ratsam, diese Intervalle so kurz wie
möglich einzustellen. Allerdings kann ein zu kurzes erneuerungsfreies Intervall unnötige
Replikationen durch Active Directory verursachen.
Unterstützung von Unicode-Zeichen
Original-DNS-Namen sind auf den in den RFCs 1123 und 952 angegebenen Zeichensatz
beschränkt. Er enthält die Zeichen "a-z", "0-9" und "-". Außerdem kann das erste Zeichen
des DNS-Namens eine Zahl sein (um Firmennamen wie 3Com oder 3M zu ermöglichen).
Für NetBIOS-Namen steht ein wesentlich umfassenderer Zeichensatz als für DNS-Namen
zur Verfügung. Der unterschiedliche Zeichensatz der beiden Namensdienste kann beim
Aktualisieren von NetBIOS-Namen (Windows NT 4.0) in DNS-Namen (Windows 2000) ein
Problem darstellen.
Eine Lösung besteht darin, NetBIOS-Namen in DNS-Namen umzubenennen, so dass sie den
bestehenden DNS-Namenstandards entsprechen. Dies ist ein Zeit raubender Vorgang, der in
vielen Fällen nicht durchführbar ist.
In RFC 2181 (Clarifications to the DNS Specification) wird der in DNS-Namen zulässige
Zeichensatz erweitert. Diese Spezifikation gibt an, dass eine DNS-Bezeichnung eine
beliebige binäre Zeichenfolge sein kann, die nicht notwendigerweise als ASCII-Zeichenfolge
interpretiert werden muss. Ausgehend von dieser Definition hat Microsoft vorgeschlagen, in
die DNS-Namenspezifikation einen umfassenderen Zeichensatz aufzunehmen - die UTF-8Zeichencodierung (RFC 2044), eine Obermenge von ASCII und eine Übersetzung der UCS2-Zeichencodierung (Unicode). Die Windows 2000-Implementierung von DNS unterstützt
die UTF-8-Zeichencodierung.
Der UTF-8-Zeichensatz umfasst Zeichen aus den meisten Schriftsprachen der Welt und
erlaubt ein wesentlich größeres Spektrum an Namen, die länderspezifische Zeichen
enthalten können. Durch diesen Zeichensatz wird das Problem des Übergangs von NetBIOSNamen (Windows NT 4.0) zu DNS-Namen (Windows 2000) gelöst.
Dennoch ist beim Implementieren eines DNS-Systems mithilfe der UTF-8-Zeichencodierung
Vorsicht geboten, da in einigen Protokollen Einschränkungen bezüglich der in Namen
zulässigen Zeichen gelten. Darüber hinaus sollten Namen, die global sichtbar sein sollen
(RFC 1958), nur die in RFC 1123 spezifizierten Zeichen enthalten.
Gesichtspunkte der Interoperabilität
Der Windows 2000-DNS-Server kann dahingehend konfiguriert werden, die Verwendung von
UTF-8-Zeichen serverspezifisch oder zonenspezifisch zuzulassen bzw. nicht zuzulassen. Ein
UTF-8 nicht unterstützender DNS-Server akzeptiert unter Umständen eine
Zonenübertragung einer Zone, die UTF-8-Namen enthält, ist jedoch möglicherweise nicht in
der Lage, diese Namen in eine Zonendatei zurückzuschreiben oder diese Namen aus einer
Zonendatei wieder zu laden. Administratoren sollten beim Übertragen einer Zone, die UTF8-Namen enthält, auf einen UTF-8 nicht unterstützenden DNS-Server Vorsicht walten
lassen.
Der Domänenlocator
Der Windows 2000-Domänenlocator, der im Anmeldedienst NetLogon implementiert ist,
ermöglicht dem Client (dem Computer, der einen Domänencontroller sucht), einen
Domänencontroller zu finden. Er enthält die IP/DNS-kompatiblen und Windows NT 4.0kompatiblen Locators, die in einer gemischten, auf Windows 2000 und Windows NT 4.0
basierenden Umgebung Interoperabilität bereitstellen.
Der Suchalgorithmus für Domänencontroller, der im folgenden Flussdiagramm dargestellt
ist, ist folgendermaßen implementiert:
Vom Client werden die erforderlichen Informationen zum Auswählen eines
Domänencontrollers gesammelt:
 Der DNS-Domänenname der Active Directory-Domäne, der der Computer
angehört.
 Der Domänen-GUID der abgefragten Domäne. Üblicherweise ist dieser nur
bekannt, falls die abgefragte Domäne die primäre Domäne des Computers ist.
Ist der Domänen-GUID nicht bekannt, bleibt er leer.
 Der Standortname. Er ist entweder aus einer vorherigen Abfrage oder aus
einer festen Konfiguration bekannt. Ist keine der beiden Angaben verfügbar,
bleibt der Standortname leer.
 Der Anmeldedienst ruft den DNS-Server zunächst mithilfe des IP/DNS-kompatiblen
Locators.
 Wenn der Computer, auf dem der Anmeldedienst ausgeführt wird, nicht für die
Verwendung von IP oder DNS konfiguriert ist oder der IP/DNS-kompatible Locator
keinen Domänencontroller finden konnte, führt der Anmeldedienst eine
Domänencontrollersuche mithilfe des Windows NT 4-kompatiblen Domänenlocators
durch.
 Die Informationen zum gefundenen Domänencontroller werden an den anfordernden
Client zurückgeliefert.
Die Beschreibung des Windows NT 4-kompatiblen Domänenlocators wurde ausgelassen, da
dieser für DNS keine Rolle spielt und in "Windows 2000 Domain Controller Locator"
beschrieben ist.
IP/DNS-kompatibler Locator
Der Algorithmus, der dem IP/DNS-kompatiblen Locator zugrunde liegt, besteht im
Wesentlichen aus zwei Teilen. Erstens müssen der bzw. die Domänencontroller bei einem
DNS-Server registriert werden. Zweitens muss der Locator eine DNS-Abfrage an den DNSServer senden, um einen Domänencontroller in der angegebenen Domäne zu finden.
Nachdem diese Abfrage aufgelöst wurde, wird eine LDAP UDP (User Datagram Protocol)Abfrage an einen oder mehrere in der Antwort aufgeführte(n) Domänencontroller gesendet,
um ihre Verfügbarkeit sicherzustellen. Schließlich speichert der Anmeldedienst die
gefundenen Domänencontroller im Cache, um zukünftige Anforderungen aufzulösen. Der
Algorithmus wird weiter unten im Detail beschrieben.
Registrierung von DNS-Einträgen und Anforderungen von Auflösern
Eine Windows 2000-Domäne wird durch einen DNS-Domänennamen repräsentiert (z. B.
nt.microsoft.com.). Jeder Domänencontroller registriert seine Adresse bei DNS mithilfe der
standardmäßigen dynamischen DNS-Aktualisierung. Neben seinem Hostnamen (A-Eintrag)
registriert der Domänencontroller Pseudonyme (SRV- oder CNAME-Einträge), die das
Auffinden des Domänencontrollers nach vorhersehbaren Kriterien (z. B. einem bestimmten
Standort) ermöglichen. Falls mehrere Domänencontroller dieselben Kriterien erfüllen, gibt es
mehrere Einträge mit demselben Pseudonym. Ein Client, der mit diesen Kriterien nach
einem Domänencontroller sucht, erhält vom DNS-Server alle anwendbaren Einträge.
Beispielsweise würde ein Domänencontroller mit dem Namen phoenix in der Domäne
nt.microsoft.com. mit der IP-Adresse 157.55.81.157 die folgenden Einträge bei DNS
registrieren
phoenix.nt.microsoft.c
A
om.
_ldap._tcp.nt.microsoft
SRV
.com.
_kerberos._tcp.nt.micr
SRV
osoft.com.
_ldap._tcp.dc._msdcs.
SRV
nt.microsoft.com.
_kerberos._tcp.dc._ms
SRV
dcs.nt.microsoft.com.
157.55.81.157
0 0 389 phoenix.nt.microsoft.com.
0 0 88 phoenix.nt.microsoft.com.
0 0 389 phoenix.nt.microsoft.com.
0 0 88 phoenix.nt.microsoft.com.
Wenn alle diese Einträge (und ähnliche Einträge von allen anderen Domänencontrollern in
derselben Domäne) registriert sind, liefert eine einfache DNS-Abfrage nach
"_ldap._tcp.dc._msdcs.nt.microsoft.com." die Namen und Adressen aller Domänencontroller
in der Domäne.
Der Anmeldedienst auf jedem Windows 2000-Domänencontroller registriert nach Bedarf
einen oder mehrere der folgenden SRV-Einträge bei DNS-Servern. Die folgende Liste
definiert den mit dem registrierten Eintrag verbundenen Namen, beschreibt die von diesem
Eintrag unterstützten Suchkriterien und definiert Prüfungen, die vom Anmeldedienst beim
Registrieren des jeweiligen Eintrags durchgeführt werden.
Der Anmeldedienst registriert nach Bedarf die folgenden SRV-DNS-Einträge:
_ldap._tcp.<DnsDomainName>.
Ermöglicht einem Client, einen LDAP-Server in der durch <DnsDomainName> angegebenen
Domäne zu finden. Zum Beispiel _ldap._tcp.nt.microsoft.com. Der LDAP-Server ist nicht
notwendigerweise ein Domänencontroller. Alle Windows NT-Domänencontroller registrieren
diesen Namen.
_ldap._tcp.<SiteName>._sites.<DnsDomainName>.
Ermöglicht einem Client, einen LDAP-Server in der durch <DnsDomainName> angegebenen
Domäne am Standort <SiteName> zu finden. Zum Beispiel
_ldap._tcp.redmond._sites.nt.microsoft.com. Alle Windows NT-Domänencontroller
registrieren diesen Namen.
_ldap._tcp.dc._msdcs.<DnsDomainName>
Ermöglicht einem Client, einen Domänencontroller der durch <DnsDomainName>
angegebenen Domäne zu finden. Alle Windows NT-Domänencontroller registrieren diesen
Namen.
_ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>
Ermöglicht einem Client, einen Domänencontroller der durch <DnsDomainName>
angegebenen Domäne am Standort <SiteName> zu finden. Alle Windows NTDomänencontroller registrieren diesen Namen.
_ldap._tcp.pdc._msdcs.<DnsDomainName>.
Ermöglicht einem Client, den primären Domänencontroller (PDC) der durch
<DnsDomainName> angegebenen Domäne zu finden. Nur der primäre Domänencontroller
der Domäne registriert diesen Namen. Es ist Aufgabe des PDCs, alle anderen
Registrierungen dieses Namens zu entfernen.
_ldap._tcp.gc._msdcs.<DnsForestName>.
Ermöglicht einem Client, einen globalen Katalogserver für diese Domäne zu finden. Nur ein
Domänencontroller, der den globalen Katalog der Gesamtstruktur mit dem Namen
<DnsForestName> bedient, registriert diesen Namen. Zum Beispiel
_ldap._tcp.gc._msdcs.microsoft.com.
_ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsForestName>.
Ermöglicht einem Client, einen globalen Katalogserver für diese Domäne zu finden, der sich
am Standort <SiteName> befindet. Nur ein Domänencontroller, der den globalen Katalog
der Gesamtstruktur mit dem Namen <DnsForestName> bedient, registriert diesen Namen.
Zum Beispiel _ldap._tcp.redmond._sites.gc._msdcs.microsoft.com.
_gc._tcp.<DnsForestName>.
Ermöglicht einem Client, einen globalen Katalogserver für diese Domäne zu finden. Nur ein
LDAP-Server, der den globalen Katalog der Gesamtstruktur mit dem Namen
<DnsForestName> bedient, registriert diesen Namen. Zum Beispiel
_gc._tcp.microsoft.com. Der LDAP-Server ist nicht notwendigerweise ein
Domänencontroller.
_gc._tcp.<SiteName>._sites.<DnsForestName>.
Ermöglicht einem Client, einen globalen Katalogserver für diese Domäne zu finden, der sich
am Standort <SiteName> befindet. Nur ein LDAP-Server, der den globalen Katalog der
Gesamtstruktur mit dem Namen <DnsForestName> bedient, registriert diesen Namen. Zum
Beispiel _gc._tcp.redmond._sites.microsoft.com. Der LDAP-Server ist nicht
notwendigerweise ein Domänencontroller.
_ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName>.
Ermöglicht einem Client, einen Domänencontroller in einer Domäne mit einem GUID
<DomainGuid> zu finden. Dieser Vorgang wird nur ausgeführt, wenn der DNS-Name
<DnsDomainName> der Domäne geändert wurde und der DNS-Name <DnsForestName>
der Gesamtstruktur bekannt ist. Dieser Vorgang findet erwartungsgemäß nur gelegentlich
statt. Er kann nur dann erfolgreich ausgeführt werden, wenn der DNS-Name der
Gesamtstruktur nicht ebenfalls geändert wurde. Beispielsweise _ldap._tcp.4f9044807c78-11cf-b057-00aa006b4f8f.domains._msdcs.microsoft.com. Alle Windows NTDomänencontroller registrieren diesen Namen.
_kerberos._tcp.<DnsDomainName>
Ermöglicht einem Client, ein Kerberos-Schlüsselverteilungscenter (Key Distribution Center,
KDC) für die Domäne zu finden. Alle Domänencontroller, die den Kerberos-Dienst anbieten,
registrieren diesen Namen. Bei diesem Dienst handelt es sich mindestens um ein RFC 1510kompatibles Kerberos 5 KDC. Das KDC ist nicht notwendigerweise ein Domänencontroller.
Alle Windows NT-Domänencontroller, auf denen der Kerberos KDC-Dienst ausgeführt wird,
registrieren diesen Namen.
_kerberos._udp.<DnsDomainName>
Entspricht _kerberos._tcp.<DnsDomainName>, nur wird UDP impliziert.
_kerberos._tcp.<SiteName>._sites.<DnsDomainName>
Ermöglicht einem Client, ein Kerberos-Schlüsselverteilungscenter für die Domäne mit dem
Namen <DnsDomainName> zu finden, das sich am Standort <SiteName> befindet. Bei
diesem Dienst handelt es sich mindestens um ein RFC 1510-kompatibles Kerberos 5 KDC.
Das KDC ist nicht notwendigerweise ein Domänencontroller. Alle Windows NTDomänencontroller, auf denen der Kerberos KDC-Dienst ausgeführt wird, registrieren diesen
Namen.
_kerberos._tcp.dc._msdcs.<DnsDomainName>
Ermöglicht einem Client, einen Domänencontroller zu finden, auf dem ein KerberosSchlüsselverteilungscenter für die Domäne mit dem Namen <DnsDomainName> ausgeführt
wird. Alle Windows NT-Domänencontroller, auf denen der Kerberos KDC-Dienst ausgeführt
wird, registrieren diesen Namen.
_kerberos._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>
Ermöglicht einem Client, einen Domänencontroller zu finden, auf dem ein KerberosSchlüsselverteilungscenter für die Domäne mit dem Namen <DnsDomainName> ausgeführt
wird und der sich am Standort mit dem Namen <SiteName> befindet. Alle Windows NTDomänencontroller, auf denen der Kerberos KDC-Dienst ausgeführt wird, registrieren diesen
Namen.
_kpasswd._tcp.<DnsDomainName>
Ermöglicht einem Client, einen Kerberos-Kennwortänderungsserver für die Domäne zu
finden. Alle Server, die den Kerberos-Kennwortänderungsdienst anbieten, registrieren
diesen Namen. Dieser Server entspricht mindestens der Spezifikation in draft-ietf-catkerb-chg-password-02.txt. Der Server ist nicht notwendigerweise ein
Domänencontroller. Alle Windows NT-Domänencontroller, auf denen der Kerberos KDCDienst ausgeführt wird, registrieren diesen Namen.
_kpasswd._udp.<DnsDomainName>
Entspricht _kpasswd._tcp.<DnsDomainName>, nur wird UDP impliziert.
Der Anmeldedienst NetLogon registriert die folgenden A-DNS-Einträge:
<DnsDomainName>.
Ermöglicht einem Client, einen beliebigen Domänencontroller in der Domäne über eine
normale A-Eintragssuche zu finden. Ein Name wie dieser wird über eine LDAP-Referenz an
den LDAP-Client zurückgegeben.
gc._msdcs.<DnsForestName>
Ermöglicht einem Client, einen beliebigen globalen Katalog in der Gesamtstruktur über eine
normale A-Eintragssuche zu finden. Ein Name wie dieser wird über eine LDAP-Referenz an
den LDAP-Client zurückgegeben.
Der Anmeldedienst NetLogon registriert die folgenden CNAME-DNS-Einträge:
<DsaGuid>._msdcs.<DnsForestName>
Ermöglicht einem Client, einen beliebigen Domänencontroller in der Gesamtstruktur über
eine normale A-Eintragssuche zu finden. Die einzigen bekannten Informationen zum
Domänencontroller sind der GUID des MSFT-DSA-Objekts für den Domänencontroller und
der Name der Gesamtstruktur, in der sich der Domänencontroller befindet. Dieser Name
wird verwendet, um die mögliche Umbenennung eines Domänencontrollers zu vereinfachen.
Der Anmeldedienst versucht die von anderen Domänencontrollern in der Domäne
registrierten Namen auf Gültigkeit zu überprüfen. Insbesondere zählt der PDC der Domäne
vor dem Registrieren eines Namens alle anderen Registrierenden des Namens durch
(mithilfe von DNS) und überprüft, ob alle anderen Registrierenden tatsächlich
Domänencontroller dieser Domäne sind und die Voraussetzungen zum Registrieren des
Namens erfüllen. Falls ein Eintrag ungültig ist, wird im Ereignisprotokoll eine Beschreibung
des Problems verzeichnet. Wenn der PDC der Domäne beispielsweise den Namen
_ldap._tcp.<SiteName>._sites.<DnsDomainName> registriert, zählt er
_ldap._tcp.<SiteName>._sites.<DnsDomainName> für jeden Standort durch und
überprüft, ob die gelieferten Einträge Domänencontroller für den betreffenden Standort
darstellen.
Algorithmus des IP/DNS-kompatiblen Domänenlocators
Der IP/DNS-kompatible Domänenlocatoralgorithmus wird im Kontext des Anmeldedienstes,
der üblicherweise auf dem Client läuft, ausgeführt. Der im Flussdiagramm dargestellte
Algorithmus arbeitet folgendermaßen:
DnsQuery wird unter Angabe eines der Kriterien, die DNS-Hostnamen kennzeichnen,
aufgerufen.
Falls IP oder DNS nicht unterstützt wird, wird der Algorithmus unter Angabe dieses Grundes
beendet.
Falls der angegebene Name nicht gefunden wird (z. B. weil die Domäne umbenannt wurde),
wird der Algorithmus unter Angabe dieses Grundes beendet.
Nach dem Abruf der Liste der Domänencontroller von DNS sendet der Client Ping-Signale in
einer gewichteten zufälligen Reihenfolge an die verschiedenen Domänencontroller. Nach
jedem Ping-Signal wartet der Client 1/10 Sekunde auf eine Antwort. Die Auswahl der
Domänencontroller in zufälliger Reihenfolge stellt eine erste Stufe des Lastenausgleichs dar.
Durch Senden mehrerer Ping-Signale in rascher Folge wird sichergestellt, dass der
Suchalgorithmus in einer akzeptablen Zeit terminiert. Die Signale werden so lange
gesendet, bis entweder alle von DNS gemeldeten Domänencontroller ausprobiert wurden
oder bis eine positive Antwort vom kontaktierten Domänencontroller empfangen wurde - je
nachdem, welches Ereignis zuerst eintritt.
Wenn ein Domänencontroller auf das Ping-Signal antwortet, werden die in der Antwort
gelieferten Parameter mit den vom Client geforderten Parametern verglichen. Stimmen die
Informationen nicht überein, wird die Antwort ignoriert.
Der erste Domänencontroller, der auf ein Ping-Signal antwortet und die Anforderungen des
Clients erfüllt, wird vom Client verwendet.
Suchen von Domänencontrollern an bestimmten Standorten
Wenn kein anderer Standort angegeben wird, sucht ein Locator einen Domänencontroller an
dem Standort, an dem sich der Client befindet. Ist dem Locator zu Beginn der Suche der
Standort des Clients nicht bekannt, fragt er einen DNS-Server auf die Einträge der
Domänencontroller in der angegebenen Domäne ab. Anschließend wendet er sich an die
gefundenen Domänencontroller, um den Standort zu ermitteln, dem der Client angehört.
Falls sich der gefundene Domänencontroller nicht an demselben Standort befindet,
wiederholt der Locator die DNS-Abfrage unter Angabe des Standortes des Clients.
Ein Client kann über mehrere Netzwerkkarten und somit mehrere IP-Adressen verfügen.
Theoretisch kann der Client somit mehreren Standorten angehören. Diese Möglichkeit wird
im obigen Algorithmus vernachlässigt. Stattdessen wird angenommen, dass sich der Client
an dem Standort befindet, der der Netzwerkkarte entspricht, über die einer der
Domänencontroller mit Ping kontaktiert wurde. Sollte diese Mehrdeutigkeit in einem
speziellen Fall nachteilig sein, kann der Standortname manuell konfiguriert werden, indem
unter dem Registrierungsschlüssel
HKLM\System\CurrentControlSet\Services\NetLogon\Parameters der REG_SZWert SiteName festgelegt wird. Falls dieser Parameter definiert ist, muss der
Standortname des Computers dem angegebenen Wert entsprechen, und der durch den
Locator dynamisch von Active Directory ermittelte Standortname wird nie verwendet.
Cacheauflösungsdienst
Die Windows 2000-Implementierung von DNS enthält einen clientseitigen
Cacheauflösungsdienst für die DNS-Namensauflösung. Der Cacheauflösungsdienst ist ein
Windows 2000-Dienst mit dem einzigen Zweck, die Leistung von Namensabfragen zu
verbessern und die damit verbundene Netzwerklast durch Minimieren der Anzahl von
Rundsendungen zu verringern.
Der Cacheauflösungsdienst wird im Kontext des Prozesses Services.exe (DienststeuerungsManager) ausgeführt und kann wie jeder andere Dienst aktiviert und deaktiviert werden.
Der Windows 2000-DNS-Cacheauflösungsdienst zeichnet sich durch folgende Funktionen
aus:
Allgemeine Zwischenspeicherung von Abfragen.
Negative Zwischenspeicherung.
Entfernen zuvor aufgelöster Namen aus dem Cache nach negativer Bestätigung.
Protokollieren kurzzeitig vorhandener Netzwerkadapter (Plug & Play) und ihrer IPKonfiguration.
Protokollieren des Domänennamens jedes Adapters.
Verwaltung nicht reagierender Namenserver.
Der Cache des Cacheauflösungsdienstes kann mithilfe des IPCONFIG-Befehls gelöscht
werden.
Möglichkeit, mehrere vom DNS-Server gelieferte A-Ressourceneinträge anhand ihrer IPAdresse mit Prioritäten zu versehen. Wenn der Auflöser eine Abfrage sendet, die eine solche
Einstufung fordert, sucht der DNS-Server die A-Einträge mit IP-Adressen von den
Netzwerken, an die der Computer direkt angeschlossen ist, und gibt sie in der Antwort
zuerst an. Diese Funktion verhindert die ordnungsgemäße Ausführung von Round Robin. Es
kann über die Registrierung deaktiviert werden.
Akzeptieren einer Antwort von einer nicht abgefragten IP-Adresse. (Die Funktion ist
standardmäßig aktiviert. Sie kann über die Registrierung deaktiviert werden.)
Möglichkeit zum automatischen Neuladen der aktualisierten lokalen Datei HOSTS in den
Auflösungscache. Auf diese Weise wird der Auflösungscache bei jeder Änderung einer Datei
HOSTS aktualisiert.
Möglichkeit, bei einem Netzwerkfehler ein Timeout auszulösen. Wenn alle Abfragen eines
Auflösers mit Timeout fehlschlagen, wird ein Netzwerkfehler angenommen und es werden
eine bestimmte Zeit lang (standardmäßig 30 Sekunden) keine weiteren Abfragen gesendet.
Bei einem Computer mit mehreren Netzwerkkarten gilt diese Regel für jede einzelne
Netzwerkkarte. Die Funktion ist standardmäßig aktiviert. Sie kann über die Registrierung
deaktiviert werden.
Namensauflösung
Eine grundlegende Namensauflösungsanforderung besteht aus einer Abfrage für einen
bestimmten Typ von DNS-Eintrag mit einem bestimmten DNS-Namen. Der in einer Abfrage
angegebene aufzulösende Name fällt in eine von drei Kategorien:
Vollqualifiziert. Der in der Abfrage angegebene Name ist durch einen Punkt abgeschlossen.
Unqualifizierter einteiliger Name. Der in der Abfrage angegebene Name enthält keine
Punkte.
Unqualifizierter mehrteiliger Name. Der in der Abfrage angegebene Name enthält einen oder
mehrere Punkte, ist jedoch nicht mit einem Punkt abgeschlossen.
Vollqualifizierte Abfrage
Ein vollqualifizierter Name kennzeichnet eindeutig einen bestimmten Computer im Netzwerk
und erfordert keine Änderungen, beispielsweise ntserver.mydomain.microsoft.com.
Wenn ein solcher Name aufgelöst werden muss, versucht zunächst ein
Cacheauflösungsdienst die vollqualifizierte Abfrage aus seinem Cache aufzulösen (beachten
Sie, dass die Datei HOSTS vorab in den Auflösungscache geladen wird). Schlägt die
Auflösung aus dem Cache fehl, wird die vollqualifizierte Abfrage direkt an einen DNS-Server
gesendet. Der Cacheauflösungsdienst ermittelt aus der TCP/IP-Konfiguration des lokalen
Computers Listen der DNS-Server, die er abfragen kann. Ein Computer mit mehreren
Netzwerkkarten kann über mehrere Listen von DNS-Servern verfügen.
Die Netzwerkadapter eines mehrfach vernetzten Computers sind möglicherweise (jedoch
nicht notwendigerweise) in ein vollständig verbundenes Netzwerk integriert. Falls die
Netzwerke getrennt sind, sind unter Umständen auch die DNS-Namespaces an diesen
Netzwerkadaptern getrennt. Daher müssen die Abfragen für eine vollständige
Namensauflösung an DNS-Server über alle Adapter gesendet werden. Die Antwort auf eine
Abfrage kann einer von vier Klassen zugeordnet werden:
Positive Antwort. Der Name existiert und ihm sind Daten zugeordnet.
Negative Antwort. Entweder existiert der Name nicht oder ihm sind keine Daten zugeordnet.
Serverfehler. Der Server ist nicht in der Lage die Anforderung zu bedienen.
Keine Antwort. Der Server antwortet nicht innerhalb der Timeoutzeitspanne.
Es wird angenommen, dass die DNS-Server in einer Liste, die einer bestimmten
Netzwerkkarte zugeordnet ist, Mitglieder desselben Namespace sind. Die Server werden in
der Reihenfolge abgefragt, in der sie in der Liste aufgeführt sind. Die Reihenfolge ist durch
die Priorität der Server definiert. Gibt ein Server in der Liste eine positive oder negative
Antwort zurück, wird dieselbe Frage keinem anderen Server in der Liste mehr gestellt. Der
Auflöser greift nur dann auf die anderen Server in der Liste zurück, wenn der aktuelle
Server nicht oder mit einem Serverfehler reagiert (bei einem mehrfach vernetzten
Computer unterscheidet sich dieses Verhalten geringfügig, wie unten dargestellt). Sollte ein
Server nicht antworten, ändert der Auflöser durch dynamisches Umordnen der Liste die
Priorität des nicht reagierenden Servers (weitere Informationen hierzu finden Sie im
Abschnitt "Verwaltung von DNS-Serverlisten").
Aus Effizienzgründen wird ein schneller Netzwerkadapter als bevorzugter Adapter für die
Namensauflösung betrachtet. Im Folgenden wird der Algorithmus für die Namensauflösung
zusammengefasst:
Die Abfrage wird an den ersten Server in der Serverliste des bevorzugten Adapters
gesendet.
Wird innerhalb von einer Sekunde keine Antwort empfangen, wird die Abfrage an die ersten
Server in allen Listen, einschließlich derjenigen des bevorzugten Adapters, gesendet.
Wird innerhalb von zwei Sekunden keine Antwort empfangen, wird die Abfrage an alle DNSServer in allen Listen, einschließlich der zuvor abgefragten ersten Server, gesendet.
Wird innerhalb von zwei Sekunden keine Antwort empfangen, wird die Abfrage erneut an
alle DNS-Server in allen Listen gesendet.
Dieses Verfahren wird nach 4 Sekunden und, falls keine Antwort empfangen wird, nach 8
Sekunden nochmals wiederholt.
Wurde die Abfrage nach allen diesen Versuchen nicht aufgelöst (diese können bis zu 17
Sekunden dauern), wird ein Timeout an den Client gemeldet.
Der Algorithmus verläuft anders, wenn mindestens eine Antwort empfangen wurde:
Falls eine positive Antwort von einem Server empfangen wird, wird diese an den
Abfragenden zurückgegeben, und der Algorithmus wird beendet.
Falls eine negative Antwort von einem Server empfangen wird, wird die Liste, der dieser
Server angehört, aus der Abfrage entfernt.
Falls von jeder Adapterliste ein Server eine negative Antwort zurückgibt, wird eine negative
Antwort an den Abfragenden geliefert.
Gibt ein Server einen Serverfehler zurück, wird dieser Server für einen bestimmten
Zeitraum aus der Abfrage entfernt, wie im Abschnitt "Verwaltung von DNS-Serverlisten"
beschrieben.
Abfrage mit unqualifiziertem einteiligem Namen
Ein Name, der keine Punkte enthält, wird als unqualifizierter einteiliger Name (Unqualified
Single-Label) bezeichnet, z. B. ntserver.
Zur Auflösung eines solchen Namens muss dieser mithilfe eines Suffixes vollständig
qualifiziert werden, bevor die Abfrage gesendet wird. Die Liste der in Frage kommenden
Suffixe kann aus zwei Quellen stammen:
Globale Suchreihenfolge für Suffixe und
Primäre und adapterspezifische Domänennamen.
Falls eine Suchreihenfolge für Suffixe vordefiniert ist, wird diese verwendet. Ist diese nicht
definiert, werden die primären und adapterspezifischen Domänennamen verwendet.
Verwenden der globalen Suchreihenfolge für Suffixe
Die Suchreihenfolge für Suffixe wird mithilfe der Benutzeroberfläche für die TCP/IPKonfiguration festgelegt. Es handelt sich dabei nicht um einen adapterspezifischen Wert.
Suffixe werden in der Reihenfolge angefügt, die in der Benutzeroberfläche angegeben ist.
Der Algorithmus zur Namenverkettung bei einem Namensauflösungsvorgang lautet
folgendermaßen:
Das erste Suffix in der Suchreihenfolge wird an den Namen angefügt.
Die Abfrage wird als vollqualifizierte Abfrage verarbeitet.
Falls das Ergebnis eine positive Antwort ist, wird diese an den Abfragenden zurückgegeben.
Falls das Ergebnis ein Timeout ist, wird dieser an den Abfragenden zurückgegeben.
Falls das Ergebnis eine negative Antwort ist, wird das nächste Suffix angefügt und der
Algorithmus mit Schritt 2 neu gestartet.
Falls die Suffixsuchliste ohne Erfolg abgearbeitet wurde, wird eine negative Antwort an den
Abfragenden zurückgegeben.
Verwenden primärer und adapterspezifischer Domänennamen
Die Konfiguration eines Windows 2000-basierten Computers enthält den primären DNSDomänennamen (PrimaryDnsDomainName) des Computers. Darüber hinaus kann jeder
Netzwerkadapter aus seiner TCP/IP-Konfiguration über einen IP-DNS-Domänennamen
(IpDnsDomainName) verfügen.
Der Algorithmus zur Namenverkettung bei einem Namensauflösungsvorgang lautet
folgendermaßen:
Der primäre DNS-Domänenname wird an den Namen angefügt.
Die Abfrage wird als vollqualifizierte Abfrage gesendet.
Falls das Ergebnis eine positive Antwort ist, wird diese an den Client zurückgegeben.
Falls das Ergebnis ein Timeout ist, wird dieser an den Client zurückgegeben.
Falls das Ergebnis eine negative Antwort ist:
An den ursprünglichen einteiligen Namen wird der IP-DNS-Domänenname angefügt, der
noch nicht von einem Adapter in der TCP/IP-Bindungsreihenfolge verwendet wurde, und der
Algorithmus wird mit Schritt 2 neu gestartet.
Falls alle eindeutigen IP-DNS-Domänennamen versucht wurden und das Registrierungs-Flag
für Devolution festgelegt ist, wird der Devolutionsalgorithmus unter Verwendung des
primären DNS-Domänennamens versucht und der Algorithmus mit Schritt 2 neu gestartet.
Beachten Sie, dass die Namensdevolution den primären Domänennamens nicht stärker als
auf 2 Bezeichnungen (z. B. microsoft.com.) verkürzt. Beachten Sie ferner, dass der
Algorithmus für Namensdevolution nicht auf adapterspezifische Domänennamen
(IpDnsDomainName) anwendbar ist.
Die Antwort wird an den Client zurückgegeben.
Der Registrierungsschlüssel für Devolution ist standardmäßig aktiviert, um das Verhalten
eines Windows NT 4.0-basierten Clients widerzuspiegeln. Administratoren können ihn über
die Registrierung deaktivieren.
Abfrage mit unqualifiziertem mehrteiligem Namen
Ein Name, der Punkte enthält, jedoch nicht mit einem Punkt abgeschlossen ist, wird als
unqualifizierter mehrteiliger Name (Unqualified Multi-Label) bezeichnet, z. B.
ntserver.mydomain. Ein Name, der Punkte enthält, kann eindeutig oder teilweise qualifiziert
sein.
Der Namensauflösungsalgorithmus für solche Namen lautet folgendermaßen:
Die Abfrage wird als vollqualifizierte Abfrage (mit dem Namen ntserver.mydomain.)
gesendet.
Falls das Ergebnis eine positive Antwort ist, wird diese an den Client zurückgegeben.
Falls das Ergebnis ein Timeout ist, wird dieser an den Client zurückgegeben.
Falls das Ergebnis eine negative Antwort ist, wird die Abfrage als unqualifizierte einfache
Namensabfrage gesendet.
Die Antwort wird an den Client zurückgegeben.
Szenarios der Namensauflösung
In diesem Abschnitt werden Szenarios der Namensauflösung für einen mehrfach vernetzten
Computer mithilfe von Abfragen mit unqualifizierten einfachen Namen und vollqualifizierten
Abfragen beschrieben. In diesem Szenario wird die globale Suchliste für Suffixe nicht
angegeben.
Die folgende Tabelle zeigt die DNS-Konfiguration des Computers.
KONFIGURATIONSPARAMETER
mydomain.microsoft.com.
(Standardwert - identisch mit
Domänenmitgliedschaft)
Primärer DNSDomänenname
Ethernet0
(bevorzugt)
WERT
DNS-Server
e1, e2, e3 (von DHCP)
DNSDomänenname
dns.microsoft.com. (von DHCP)
TokenRing0
DNS-Server
DNSDomänenname
t1, t2, t3 (von DHCP)
dns.ntlab.microsoft.com. (von
DHCP)
Szenarios für Abfragen mit unqualifiziertem einteiligem Namen
Suchen eines Namens im Ethernet-Segment: ping ntserver
 Abfrage an e1 bezüglich ntserver.mydomain.microsoft.com.
 Positive Antwort
Suchen eines Namens im Token Ring-Segment: ping products1
 Abfrage an e1 bezüglich products1.mydomain.microsoft.com.
 Negative Antwort
 Abfrage an t1 bezüglich ‘products1.mydomain.microsoft.com‘.
 Positive Antwort
Suchen eines Namens im Unternehmensintranet: ping thunder
 Abfrage an e1 bezüglich thunder.mydomain.microsoft.com.
 Negative Antwort
 Abfrage an t1 bezüglich thunder.mydomain.microsoft.com.
 Negative Antwort
 Abfrage an e1 bezüglich thunder.dns.microsoft.com.
 Positive Antwort
Suchen eines falschen Namens: ping boguz
 Abfrage an e1 bezüglich boguz.mydomain.microsoft.com.
 Negative Antwort
 Abfrage an t1 bezüglich boguz.mydomain.microsoft.com.
 Negative Antwort
 Abfrage an e1 bezüglich boguz.dns.microsoft.com.
 Negative Antwort
 Abfrage an t1 bezüglich boguz.dns.microsoft.com.
 Negative Antwort
 Abfrage an e1 bezüglich boguz.dns.ntlab.microsoft.com.
Negative Antwort
Abfrage an t1 bezüglich boguz.dns.ntlab.microsoft.com.
Negative Antwort
Abfrage an e1 bezüglich boguz.microsoft.com.
Negative Antwort
Abfrage an t1 bezüglich boguz.microsoft.com.
Negative Antwort
Falls ein Registrierungsschlüssel zum Senden einer Abfrage mit einteiligem Namen
festgelegt wurde, Abfrage an e1 bezüglich boguz; falls die Antwort negativ ist, Abfrage an
t1 bezüglich boguz.
Szenarios für Abfragen mit vollqualifizierten Namen
Suchen eines Namens im Internet: ping www.microsoft.com.
Abfrage an e1 bezüglich www.microsoft.com.
Positive Antwort
Suchen eines Namens im Windows NT-Labor: ping www.ntlab.microsoft.com.
Abfrage an e1 bezüglich www.ntlab.microsoft.com.
Negative Antwort
Abfrage an t1 bezüglich www.ntlab.microsoft.com.
Positive Antwort
Verwaltung von DNS-Serverlisten
Wenn ein DNS-Server auf eine Abfrage nicht reagiert, wird automatisch seine Priorität
gesenkt. Auf diese Weise wird verhindert, dass der Auflöser wiederholt Timeouts für nicht
reagierende Server erhält. Im Lauf der Zeit wird die Priorität dieses DNS-Servers jedoch
unter Umständen wieder angehoben, falls er auf weitere Abfragen antwortet.
Negative Zwischenspeicherung
Als negative Zwischenspeicherung wird die Speicherung der Tatsache bezeichnet, dass die
angeforderten Informationen nicht vorhanden sind. Die Tatsache, dass ein
Ressourceneintrag oder Namenserver nicht vorhanden ist, kann ebenso zwischengespeichert
werden wie die Tatsache, dass ein Ressourceneintrag vorhanden ist und einen bestimmten
Wert hat.
Die negative Zwischenspeicherung ist insofern sinnvoll, als sie die Antwortzeit bei negativen
Antworten verkürzt. Ferner wird die Anzahl der zwischen Auflösern und Namenservern
gesendeten Nachrichten und damit die Netzwerklast verringert. Ein großer Teil des DNSDatenaufkommens im Internet könnte vermieden werden, wenn auf allen Auflösern die
negative Zwischenspeicherung implementiert würde.
Microsofts Implementierung der negativen Zwischenspeicherung
Microsofts Implementierung der negativen Zwischenspeicherung basiert auf RFC 2308. Sie
kann deaktiviert werden, indem unter dem Registrierungsschlüssel HKEY_Local_Machine
\System \CurrentControlSet \Services \DNSCache \Parameters der REG_DWORDWert NegativeCacheTime auf Null gesetzt wird.
Deaktivieren des Cacheauflösungsdienstes
Es gibt zwei Möglichkeiten, den Cacheauflösungsdienst zu deaktivieren:
Manuelles Deaktivieren des Cacheauflösungsdienstes durch Eingeben von net stop
dnscache in der Befehlszeile. Dies deaktiviert die DNS-Serverreihenfolge, die
Unterstützung für Plug & Play-Adapter usw. Das Endergebnis ist eine Namensauflösung wie
unter Windows NT 4.0.
Festlegen des REG_DWORD-Wertes MaxCacheEntryTtlLimit, der angibt, wie lange die
positiv beantwortete Suche maximal zwischengespeichert wird, auf Null. Dies verhindert die
Zwischenspeicherung von Ressourceneinträgen, deaktiviert jedoch nicht die DNSServerreihenfolge und die Plug & Play-Unterstützung.
Verwaltungsprogramme
Windows 2000 enthält verschiedene Verwaltungsprogramme zur Unterstützung von DNSServern und Clients. Der DNS-Server kann mithilfe des MMC-Snap-Ins DNS-Manager, des
Befehlszeilenprogramms Dnscmd.exe und der Windows-Verwaltungsinstrumentation
(Windows Management Instrumentation, WMI) verwaltet werden.
Das Befehlszeilenprogramm ipconfig.exe kann zur Verwaltung von DNS-Clients verwendet
werden. Nämlich um die Registrierung der A- und PTR-Einträge eines Computers
auszulösen, den Cache anzuzeigen oder ihn zu löschen.
DNS-Manager
Die Windows 2000-Implementierung von DNS enthält einen neuen DNS-Manager als
Microsoft Management Console-Snap-In. Er stellt die gesamte erforderliche Funktionalität
zur Verwaltung des DNS-Servers, der zugehörigen Zonen, der Sicherheit usw. bereit.
Der DNS-Manager bietet vor allem folgende interessante Funktionen:
Assistent für die Konfiguration des Servers, der das Vorbereiten der Hinweise auf den
Stammserver für einen neuen DNS-Server ermöglicht.
Filterfunktionen, die für Server und Zonen mit einer großen Anzahl von Zonen bzw.
Einträgen hilfreich sind.
Neue Sicherheitsfunktionen, die die Angabe sekundärer Server, die bei Änderungen in der
Masterzone benachrichtigt werden, sowie die Angabe der Servergruppen, an die die
aktualisierten Zoneninformationen zu senden sind, ermöglichen.
Neue Sicherheitsfunktion, die das Ändern der Zugriffssteuerungslisten (ACLs) für die
verzeichnisintegrierten Zonen und Einträge in diesen Zonen ermöglicht.
Anmerkung Zur Verwaltung eines DNS-Servers müssen Sie mindestens Mitglied der
Server-Operatoren-Gruppe auf dem Server mit DNS-Server sein.
Weitere Informationen zum DNS-Manager finden Sie in der Produktdokumentation.
WMI-Unterstützung für die DNS-Serververwaltung
Der WMI-Anbieter (Windows-Verwaltungsinstrumentation) ist ein Satz von Erweiterungen
zum Windows Driver Model (WDM), einer Betriebssystemschnittstelle, über die
Hardwarekomponenten Informationen liefern und Ereignisse melden können. WMI
vereinfacht die Instrumentation verschiedener, für Windows entwickelter Treiber und
Anwendungen, bietet ausführliche und erweiterbare produkt- und herstellerübergreifende
Informationen und ermöglicht konsistenten Zugriff auf die Windows-Instrumentation von
nicht Windows verwendenden Umgebungen aus.
Neben anderen Diensten unterstützt WMI die Überwachung und Verwaltung der DNSServer, Zonen und Einträge. Es ermöglicht das Eintragen und Ändern der Eigenschaften von
DNS-Servern und Zonen, das Aufzählen der Zonen und Ressourceneinträge, das
Aktualisieren der Ressourceneinträge und das Erstellen neuer Zonen. Mithilfe von WMI kann
ein Administrator eine automatisierte Anwendung zur Verwaltung von DNS-Objekten
erstellen. Der WMI-Methodenanbieter versetzt diese Anwendungen in die Lage, Methoden
aufzurufen, die auf dem DNS-Server definiert sind.
Interoperabilitätsaspekte
In diesem Abschnitt werden Probleme erörtert, die beim Einsatz von Microsoft DNS-Servern
in der gemischten Umgebung mit DNS-Servern anderer Anbieter auftreten können.
Aufgrund seiner RFC-Kompatibilität ist der Microsoft DNS-Server vollständig interoperabel
mit allen anderen RFC-kompatiblen DNS-Servern. Da der Microsoft DNS-Server jedoch
einige Funktionen bietet, die über die RFC-Spezifikation hinausgehen, sollten Benutzer bei
der Anwendung dieser Funktionen Vorsicht walten lassen. Diese Funktionen beschränken
sich auf die Verwendung der WINS- und WINSR-Ressourceneinträge (wie im Whitepaper zu
Windows NT 4.0-DNS spezifiziert) und auf die Verwendung der UTF-8-Zeichencodierung.
Verwenden der WINS- und WINSR-Einträge
Da derzeit nur Microsoft DNS-Server die WINS- und WINSR-Ressourceneinträge
unterstützen, wird empfohlen, die Replikation dieser Einträge zu deaktivieren, sofern die
folgenden Bedingungen erfüllt sind:
Die primäre Kopie der Zone enthält einen dieser Einträge.
Mindestens eine der sekundären Zonen befindet sich auf dem Fremdhersteller-DNS-Server.
Falls sich die sekundären Zonen teilweise auf Microsoft DNS-Servern und teilweise auf
anderen DNS-Servern befinden, müssen diese Einträge bei deaktivierter Replikation von
WINS- und WINSR-Einträgen unter Umständen manuell in die sekundären Zonen auf den
Microsoft DNS-Servern eingegeben werden.
Verwenden des UTF-8-Zeichenformats
Der Windows 2000-DNS-Server kann dahingehend konfiguriert werden, die Verwendung von
UTF-8-Zeichen serverspezifisch oder zonenspezifisch zuzulassen bzw. nicht zuzulassen. Ein
UTF-8 nicht unterstützender DNS-Server akzeptiert unter Umständen eine
Zonenübertragung einer Zone, die UTF-8-Namen enthält, ist jedoch möglicherweise nicht in
der Lage, diese Namen in eine Zonendatei zurückzuschreiben oder diese Namen aus einer
Zonendatei wieder zu laden. Administratoren sollten beim Übertragen einer Zone, die UTF-
8-Namen enthält, auf einen UTF-8 nicht unterstützenden DNS-Server Vorsicht walten
lassen.
Empfangen nicht RFC-kompatibler Daten
Wenn ein Windows 2000-Server eine sekundäre Zone unterstützt und unbekannte
Ressourceneinträge empfängt, werden diese Einträge verworfen und die Zonenreplikation
fortgesetzt. Ebenso werden empfangene zirkuläre CNAME-Ressourceneinträge verworfen.
DNS-Serverleistung
Die folgende Statistik wurde als Profil der DNS-Serverleistung während vorläufiger Tests von
Windows 2000 Server erstellt. Beim Test wurden zwei verschiedene
Hardwarekonfigurationen verwendet und zusammen mit der Prozessorauslastung die
gesamte Aktivität an DNS-Abfragen und dynamischen Aktualisierungen gemessen.
Die Ergebnisse der Tests sind in der nachstehenden Tabelle aufgeführt.
Dynamische
Prozessorau
Abfragen/s Aktualisieru
slastung
ngen/s
Serverkonfiguration
Alpha 533 MHzDoppelprozessor
Intel P-II 400 MHzDoppelprozessor
1600
200
25%
900
100
30%
Bei diesen Messungen verarbeitete der überwachte DNS-Server gleichzeitig sowohl Abfragen
als auch dynamische Aktualisierungen. Die oben stehenden Zahlen geben diese parallelen
Prozesse wieder. Die Statistik wurde über einen Zeitraum von einigen Stunden erhoben. Die
Ergebnisse wurden jedoch über einen längeren Zeitraum hinweg bestätigt, in dem mehr als
2.200.000.000 Abfragen und mehr als 270.000.000 dynamische
Aktualisierungsanforderungen von einem DNS-Server (mit Alpha 533 MHz-Doppelprozessor)
in etwa 19 Tagen verarbeitet wurden.
Für die dynamischen Aktualisierungen wurden standardmäßige primäre Zonen und keine
Active Directory-integrierten Zonen verwendet. Wenn die Verzeichnisintegration für Zonen
verwendet wird, sinkt die Rate der verarbeitbaren dynamischen Aktualisierungen um den
Faktor 2, da der DNS-Server zusätzlich in die Active Directory-Datenbank schreiben muss.
Ist eine Zone so konfiguriert, dass sie nur sichere dynamische Aktualisierungen akzeptiert,
sinkt darüber hinaus die Aktualisierungsrate um 25 % gegenüber der Rate von
Aktualisierungen, die der DNS-Server für Active Directory-integrierte Zonen verarbeitet, die
nicht sichere dynamische Aktualisierungen zulassen. Die Netzwerkleistung kann in diesen
Fällen ebenfalls ein Faktor sein, da die Verarbeitung von Aktualisierungen in der
Verzeichnisdatenbank Netzwerkaktivität verursachen kann.
Die zitierten Messungen sind nicht dazu gedacht, die maximale Leistung oder
Serverbeschränkungen für Windows 2000-DNS-Server anzugeben. Das Ziel der Tests war
lediglich, Daten über eine typische DNS-Serverleistung zu erheben und einen auf
verfügbarer Standardhardware basierenden Vergleichstest als Grundlage der
Serverkapazitätsplanung zu erhalten.
In der folgenden Liste ist die spezielle Hardware aufgeführt, die vom Entwicklungs- und
Testteam für Windows 2000-DNS für Servercomputer bei diesen Tests verwendet wurde.
Hardwarekomponenten
Größe
Anzahl Prozessoren
Prozessor
RAM
Festplattenspeicher
Zwei
Alpha 533 MHz
512 MB (Megabyte)
4 GB (Gigabyte)
Anzahl Prozessoren
Prozessor
RAM
Festplattenspeicher
Zwei
Intel Pentium II 400 MHz
256 MB (Megabyte)
4 GB (Gigabyte)
Diese Messungen basierten auf einem Servercomputer, auf dem DNS-Server ausgeführt
wurde und keine anderen Dienste aktiv waren. Bei Verwendung anderer
Hardwarespezifikationen oder Softwarekonfigurationen beim Einsatz von Windows 2000DNS-Servern werden voraussichtlich andere Leistungsergebnisse als die hier
dokumentierten erzielt.
Planen der Serverkapazität
Bei der Planung und Bereitstellung von DNS-Servern sind verschiedene Aspekte des
Netzwerks und der Kapazitätsanforderungen für alle verwendeten DNS-Server zu
untersuchen.
In vielen Fällen lässt sich durch eine Erweiterung des Arbeitsspeichers auf einem DNSServer die deutlichste Leistungsverbesserung erzielen. Der Grund ist, dass der DNSServerdienst beim Start alle konfigurierten Zonen vollständig in den Arbeitsspeicher lädt.
Wenn der Server eine große Zahl von Zonen betreibt und lädt und häufig dynamische
Aktualisierungen für Zonenclients auftreten, kann weiterer Arbeitsspeicher hilfreich sein.
Der DNS-Server belegt Speicher in folgendem Umfang:
Etwa 4 MB RAM werden belegt, wenn der DNS-Server ohne Zonen gestartet wird.
Bei jedem Hinzufügen von Zonen oder Ressourceneinträgen zum Server belegt der DNSServer weiteren Serverspeicher. Schätzungsweise werden für jeden hinzugefügten
Ressourceneintrag zu einer Serverzone durchschnittlich 100 Byte Serverspeicher verwendet.
Wird beispielsweise eine Zone mit 1000 Ressourceneinträgen zu einem Server hinzugefügt,
werden etwa 100 KB Serverspeicher belegt. Die genannten Empfehlungen sollen weder die
maximale Leistung noch Beschränkungen für Windows 2000-DNS-Server angeben.
Anmerkung Diese Zahlen sind Schätzungen und sind abhängig vom Typ der in den Zonen
eingegebenen Ressourceneinträge, der Anzahl der Ressourceneinträge mit demselben
Besitzernamen sowie der Anzahl der auf einem bestimmten DNS-Server verwendeten
Zonen.
Entwerfen eines DNS-Namespace für Active
Directory
Bevor ein DNS-Namespace in Windows 2000 implementiert werden kann, muss die Struktur
der Active Directory-Dienste verfügbar sein. Daher wird empfohlen, zunächst die Active
Directory-Dienste zu entwerfen und diese dann durch den geeigneten DNS-Namespace zu
unterstützen.
Der Active Directory-Entwurf ist ein iterativer Vorgang. Zunächst werden ein anfänglicher
Active Directory-Namespace und eine ihn unterstützende DNS-Architektur entwickelt, die
dann bei auftretenden unerwarteten oder unerwünschten Konsequenzen überarbeitet
werden.
Das Whitepaper "Windows 2000 Active Directory Namespace Design" beschreibt den
Namespace der Active Directory-Dienste, insbesondere die Domänen- und Gesamtstruktur,
die Organisationseinheiten, den globalen Katalog, die Vertrauensstellungen und die
Replikation. Anschließend werden Beispiele für Namespaceimplementierungen angeführt
und die architektonischen Kriterien beschrieben, die Netzwerkarchitekten und
Administratoren beim Entwurf eines Active Directory-Namespace für das Unternehmen
beachten sollten. Durch Befolgen dieser Empfehlungen sollte der Netzwerkarchitekt des
Unternehmens in der Lage sein, einen Namespace zu entwerfen, der anstehenden
Änderungen der Firmenorganisation ohne kostspielige Umstrukturierungen standhält.
Unter anderem sind beim DNS-Entwurf die folgenden grundlegenden Fragen zu
beantworten:
 Wie viele Active Directory-Domänen werden benötigt?
 Welche Namen haben sie?
 Hat der DNS-Namespace einen privaten Stamm?
 Welche Computernamen werden verwendet?
Wählen der Namen
In Windows 2000 werden Active Directory-Domänen mit DNS-Namen benannt. Ermitteln Sie
vor dem Wählen der DNS-Namen für Active Directory-Domänen das registrierte DNSDomänennamensuffix, das Ihr Unternehmen für die Verwendung im Internet reserviert hat,
z. B. "company.com.". Es wird empfohlen, unterschiedliche interne und externe Namespaces
zu verwenden, um die Namensauflösung zu vereinfachen. So könnten Sie intern (und als
Stamm der Gesamtstruktur) ein anderes registriertes DNS-Suffix als extern verwenden, z.
B. "comp.com." oder eine untergeordnete Domäne der externen Domäne wie
"corp.company.com.". Dann können Sie diesen Namen mit einem Ortsnamen oder einem in
Ihrem Unternehmen verwendeten Organisationsnamen kombinieren, um vollständige
Namen für die Active Directory-Domänen zu erstellen, z. B. "hr.corp.company.com.". Diese
Benennungsmethode stellt sicher, dass jeder Active Directory-Domänenname global
eindeutig ist.
Nachdem Sie einen DNS-Namen für jede Active Directory-Domäne festgelegt haben, können
Sie mithilfe dieser Namen weitere untergeordnete Domänen erstellen, um andere
Abteilungen in Ihrem Unternehmen zu verwalten. Die DNS-Namen untergeordneter
Domänen müssen den DNS-Namen der übergeordneten Domänen unmittelbar
untergeordnet sein. Wenn beispielsweise eine untergeordnete Domäne in der Struktur
"us.corp.company.com." für die Personalabteilung (Human Resources) im amerikanischen
Zweig des Unternehmens hinzugefügt werden muss, wäre ein geeigneter Name für diese
Domäne "hr.us.corp.company.com.".
Aspekte des Internetzugangs
Üblicherweise besteht der Namespace eines Unternehmens aus zwei Teilen: dem privaten
und dem öffentlichen Teil. Der private Teil ist für die Außenwelt unsichtbar, während der
öffentliche aus dem Internet zugänglich ist. Die Namen, die den privaten bzw. den
öffentlichen Namespace bilden, werden hier als intern bzw. extern bezeichnet. Auch wenn
die privaten Namen aus dem Internet nicht zugänglich sind, wird von der Verwendung
externer Namen (nicht nur aus dem Unternehmen, sondern aus dem Internet allgemein) im
privaten Namespace dringend abgeraten. Sie könnte zu Mehrdeutigkeiten bei der
Namensauflösung führen.
Der Schwerpunkt in diesem Abschnitt liegt auf dem Entwurf des privaten Namespace und
der Konfiguration der DNS-Server und Zonen. Die Besonderheiten zweier unterschiedlicher
Entwürfe werden anhand zweier Unternehmen mit privaten Namespaces unterschiedlicher
Struktur dargestellt. Die beiden Unternehmen, YYY und ZZZ Corporations, haben die DNSDomänennamensuffixe "yyy.com." und "zzz.com." reserviert. Der allgemeine Ansatz für die
DNS-Konfiguration besteht darin, zwischen internen DNS-Servern (auf die nur von internen
Clients zugegriffen werden kann) und externen DNS-Servern zu unterscheiden. Externe
DNS-Server enthalten die Einträge, die voraussichtlich aus dem Internet zugänglich sein
sollen. Der interne DNS-Namespace kann einen privaten Stamm enthalten. In diesem Fall
müssen alle internen Clients, die voraussichtlich Namensauflösung benötigen, eine
Namenausschlussliste oder eine Autokonfigurationsdatei für Proxyserver unterstützen, um
zu unterscheiden, ob Namensauflösungsabfragen an den Proxyserver oder an den internen
DNS-Server zu stellen sind. Alternativ können die internen DNS-Server dafür konfiguriert
werden, unaufgelöste Abfragen an das Internet weiterzuleiten. Die DNS-Konfiguration kann
abhängig vom Typ der Clients, die DNS-Namensauflösung benötigen, sehr unterschiedlich
ausfallen. Je nach der Proxyfähigkeit ihrer Software werden vier Typen von Clients
unterschieden:
 keine Proxyunterstützung
 Unterstützung einer lokalen Adresstabelle (LAT)
 Unterstützung einer Namenausschlussliste und
 Unterstützung einer Autokonfigurationsdatei für Proxyserver.
Falls Clients ohne Proxyunterstützung oder solche, die nur LAT unterstützen,
Namensauflösung benötigen, kann der private DNS-Namespace keinen privaten Stamm
enthalten und ein oder mehrere interne DNS-Server müssen unaufgelöste Abfragen an das
Internet weiterleiten.
Entsprechend der Empfehlung im vorherigen Abschnitt würden die gewünschten
Namespaces "corp.yyy.com." und "corp.zzz.com." lauten.
Falls sich der interne und der externe Namespace überschneiden, wird die Konfiguration
komplexer. Eine solche Überschneidung liegt beispielsweise vor, wenn der externe
Webserver den Namen "www.yyy.com." und der interne Computer den Namen
"host1.yyy.com." haben. Dieser Ansatz bringt einige Komplikationen für die interne DNSKonfiguration mit sich:
 Damit ein interner Computer den Namen eines externen Servers auflösen und ihn
kontaktieren kann, müssen alle Clients eine Autokonfigurationsdatei für Proxyserver
unterstützen, es sei denn, externe Server werden intern dupliziert und externe DNSEinträge intern kopiert (wodurch die Anschaffungs- und Folgekosten (Total Cost of
Ownership) aufgrund der erforderlichen zusätzlichen Hardware und Verwaltung
steigen), oder externe DNS-Einträge werden intern kopiert und der Firewall ist so
konfiguriert, dass interne Clients externe Server kontaktieren können.
 Wenn alle Clients die Autokonfigurationsdatei für Proxyserver unterstützen, muss die
Datei so konfiguriert sein, dass interne und externe Computer mit denselben Suffixen
(wie im obigen Beispiel "www.yyy.com." und der interne Computer
"host1.yyy.com.") unterschieden werden.
Die folgenden Szenarios der DNS-Konfiguration und Namensauflösung mit sich
überschneidenden internen und externen Namespaces werden ausführlich betrachtet, da
dies der komplizierteste Fall ist.
Es wird angenommen, dass die Namespaces beider Unternehmen nur aus Namen innerhalb
einer vom NSI zugewiesenen Domäne, also "yyy.com." und "zzz.com.", bestehen. Ferner
wird angenommen, dass alle Computer der YYY Corporation Proxyclients sind, die die
Autokonfigurationsdatei für Proxyserver unterstützen, während keiner der Computer der
ZZZ Corporation ein Proxyclient ist. Das Ziel dieses Abschnitts besteht darin, die geeignete
Konfiguration der DNS-Server, Zonen und Clients zu zeigen, um folgende Anforderungen zu
erfüllen:
 Nur ein öffentlicher Teil des Namespace soll aus dem Internet zugänglich sein.
 Ein Computer des Unternehmens soll in der Lage sein, alle (internen und externen)
Namen innerhalb des Unternehmens aufzulösen.
 Ein Computer des Unternehmens soll in der Lage sein, jeden Namen aus dem
Internet aufzulösen.
Schließlich wird angenommen, dass die beiden Unternehmen zusammengeführt wurden und
jetzt jeder Computer dieser beiden Namespaces in der Lage sein sollte, jeden (internen oder
externen) Namen aufzulösen, und zwar nicht nur innerhalb des Namespace seines eigenen
Unternehmens, sondern auch innerhalb des Namespace des anderen Unternehmens.
Die folgende Lösung erfüllt alle vier Anforderungen.
Zwei aus dem Internet zugängliche DNS-Server sind autorisierend für zwei Zonen,
"yyy.com." und "zzz.com.", wie in der folgenden Abbildung dargestellt. (Um das Beispiel zu
vereinfachen, wurde ein einzelner Server und eine einzelne Zone pro Unternehmen gewählt.
In der Realität wird ein Unternehmen mehrere Server und Zonen, wie z. B. "first.yyy.com.",
"second.yyy.com." usw. verwenden.) Diese Zonen enthalten nur Einträge, die externen
Namen entsprechen, und Delegierungen der YYY und der ZZZ Corporation (also nur die
Einträge, die die beiden Unternehmen für die Außerwelt offen legen möchten). Dies ist die
einzige gemeinsame Lösung für die beiden Unternehmen. Die restlichen Entwurfsmerkmale
sind unterschiedlich.
Zunächst werden der Entwurf des privaten Namespace und die Konfiguration der DNSServer, Zonen und Clients für den Fall betrachtet, dass die Computer z. B. des
Unternehmens ZZZ Corporation keine Proxyclients sind.
Ein Unternehmen muss eine Gruppe von nicht aus dem Internet zugänglichen DNS-Servern
bestimmen, die Zonen mit allen (internen und externen) Namen des
Unternehmensnamespace verwalten. Jeder DNS-Client muss DNS-Abfragen an einige dieser
DNS-Server senden. Jeder DNS-Server muss Abfragen an einen oder mehrere vorher
zugewiesene Weiterleitungsserver weiterleiten. Enthält ein DNS-Server eine Namespacezone
der obersten Ebene für das Unternehmen, z. B. "zzz.com.", ist sein Weiterleitungsserver ein
aus dem Internet zugänglicher DNS-Server. Die Kommunikation zwischen internen und
externen Servern findet über einen Firewall statt. Jeder andere interne DNS-Server leitet
unaufgelöste Abfragen an einen oder mehrere DNS-Server weiter, die die Namespacezone
der obersten Ebene für das Unternehmen enthalten.
Um zu gewährleisten, dass ein Unternehmensclient jeden Hostnamen aus den
zusammengeführten Unternehmen auflösen kann, muss jeder DNS-Server, der eine
Unternehmensnamespacezone der obersten Ebene wie "zzz.com." enthält, auch die Zonen
enthalten, die alle (internen und externen) Namen der zusammengeführten Unternehmen
enthalten.
Jetzt werden der Entwurf des privaten Namespace und die Konfiguration der DNS-Server,
Zonen und Clients für die YYY Corporation betrachtet. Der private Namespace enthält einen
privaten Stamm, ".".
Ein Unternehmen muss eine Gruppe von nicht aus dem Internet zugänglichen DNS-Servern
bestimmen, die Zonen mit internen Namen aus dem privaten Unternehmensnamespace
verwalten. Jeder DNS-Client sendet eine Abfrage an einige (bevorzugte oder alternative)
DNS-Server oder an die Proxyserver entsprechend der Autokonfigurationsdatei für
Proxyserver (PAC-Datei). Jeder interne DNS-Server enthält in Hinweise auf das
Stammverzeichnis die Adresse(n) des bzw. der privaten Stamm-DNS-Server(s).
Um zu gewährleisten, dass ein Unternehmensclient jeden Hostnamen aus den
zusammengeführten Unternehmen auflösen kann, muss die "."-Zone Delegierungen an die
Zonen der obersten Ebene der privaten Namespaces der zusammengeführten Unternehmen
enthalten.
Die folgenden Abfragebeispiele zeigen die internen und externen Namen in beiden
Unternehmen sowie die Erfüllung aller oben genannten Anforderungen.
Zunächst ein Beispiel, bei dem ein Unternehmenscomputer einen internen Namen auflösen
muss (folgen Sie zur Illustration der obigen Abbildung).
Ein Computer in der YYY Corporation muss eine DNS-Abfrage für "www.third.yyy.com."
auflösen. Zunächst wird anhand der PAC-Datei festgestellt, dass es sich bei
"www.third.yyy.com." um einen internen Namen handelt. Daher wird die Abfrage an den
zugewiesenen DNS-Server gesendet (Schritt 1). Falls dieser DNS-Server für den Namen
"www.third.yyy.com." autorisierend ist oder der Cache die erforderlichen Daten enthält,
antwortet der Server dem Client. Andernfalls fragt der Server einen Stammserver ab
(Schritt 2). Ein Stammserver gibt eine Referenz auf den autorisierenden Server zurück
(Schritt 3). Dann sendet der Server eine Abfrage an die Zone des autorisierenden Servers
(Schritt 4), empfängt von dieser eine Antwort (Schritt 5) und gibt sie schließlich an den
Client weiter (Schritt 6).
Ein Computer in der ZZZ Corporation muss eine DNS-Abfrage für "www.third.zzz.com."
auflösen. Er sendet die Abfrage an den zugewiesenen DNS-Server (Schritt 1). Falls dieser
DNS-Server für den Namen "www.third.zzz.com." autorisierend ist oder der Cache die
erforderlichen Daten enthält, antwortet der Server dem Client. Andernfalls leitet der Server
die Abfrage an den DNS-Server weiter, der die Zone "zzz.com." enthält (Schritt 2). Dieser
Server findet eine Delegierung an "third.zzz.com." in der Zone "zzz.com.". Er sendet die
Abfrage an diesen Server (Schritt 3), erhält die Antwort (Schritt 4), übermittelt sie an den
vorherigen Server (Schritt 5), der sie schließlich an den Client zurückgibt (Schritt 6).
Im nächsten Beispiel wird ein Unternehmenscomputer betrachtet, der einen externen (nicht
zum Unternehmen gehörenden) Namen auflösen muss.
Ein Computer in der YYY Corporation muss eine Webseite auf dem Computer
"www.someother.com." öffnen. Da er ein Proxyclient ist, sendet er eine Anfrage an den
Proxyserver (Schritt 1), nachdem er anhand der PAC-Datei festgestellt hat, dass der Name
"www.someother.com." extern ist. Der Proxyserver sendet eine DNS-Abfrage an den
zugewiesenen DNS-Server (Schritt 2), der die Abfrage rekursiv auflöst. Er sendet die
Abfrage an den Stammserver (Schritt 3) und erhält als Antwort eine Referenz auf den
Server, der die Zone "com." enthält (Schritt 4). Dann sendet er die Abfrage an diesen
Server (Schritt 5) und erhält als Antwort eine Referenz auf den Server, der eine Zone
"someother.com." enthält (Schritt 6). Er sendet eine Abfrage an letzteren (Schritt 7), der
die Abfrage auflöst und die Antwort an den Server zurückgibt (Schritt 8). Der DNS-Server
gibt die Antwort an den Proxyserver zurück (Schritt 9). Schließlich verwendet der
Proxyserver die erhaltene IP-Adresse von "www.someother.com.", um diesen zu
kontaktieren, und liefert die erforderlichen Informationen an den Client (Schritt 10).
Ein Computer in der ZZZ Corporation muss eine DNS-Abfrage für "www.someother.com."
auflösen. Er sendet eine entsprechende Abfrage an den zugewiesenen DNS-Server (Schritt
1). Falls der Cache die erforderlichen Daten enthält, antwortet der Server dem Client.
Andernfalls leitet der Server die Abfrage an den DNS-Server weiter, der die Zone "zzz.com."
enthält (Schritt 2). Dieser Server leitet die Abfrage über den Firewall an den externen
Server weiter (Schritt 3). Der letztere führt die Namensauflösung ähnlich wie im vorigen Fall
durch (Schritte 4-9) und übermittelt das Ergebnis über den Firewall und die Kette der an der
Auflösung beteiligten Server an den Client (Schritte 10-12). Dann verwendet der Client die
aufgelöste IP-Adresse von "www.someother.com.", um ihn über den Firewall zu
kontaktieren und die gewünschte Webseite zu downloaden.
Im nächsten Beispiel wird der interessante Fall eines Unternehmenscomputers betrachtet,
der einen externen Namen eines Computers in seinem eigenen Unternehmen auflösen
muss.
Ein Computer in der YYY Corporation muss eine Webseite auf dem Computer
"www.yyy.com." öffnen. Da er ein Proxyclient ist, sendet er eine Anfrage an den
Proxyserver (Schritt 1), nachdem er anhand der PAC-Datei festgestellt hat, dass der Name
"www.yyy.com." extern ist. Der Proxyserver sendet eine DNS-Abfrage an den zugewiesenen
DNS-Server (Schritt 2), der zufällig autorisierend für "www.yyy.com." ist. Der DNS-Server
löst die Abfrage auf und gibt die Antwort an den Proxyserver zurück (Schritt 3). Schließlich
verwendet der Proxyserver die erhaltene IP-Adresse von "www.yyy.com.", um diesen zu
kontaktieren, und liefert die erforderlichen Informationen an den Client (Schritt 4).
Ein Computer in der ZZZ Corporation muss eine DNS-Abfrage für "www.zzz.com." auflösen.
Er sendet die Abfrage an den zugewiesenen DNS-Server (Schritt 1). Falls der Cache die
erforderlichen Daten enthält, antwortet der Server dem Client. Andernfalls leitet der Server
die Abfrage an den DNS-Server weiter, der die Zone "zzz.com." enthält (Schritt 2). Da der
Server autorisierend für den Namen "www.zzz.com." ist, löst er die Abfrage auf und gibt die
Antwort über den weiterleitenden DNS-Server an den Client zurück (Schritte 3-4). An
diesem Punkt ist die Tatsache zu betonen, dass die Zone "zzz.com." auf dem internen DNSServer sowohl interne als auch externe Namen enthält. Enthielte sie nur interne Namen,
würde die Abfrage nicht aufgelöst und ein Namenfehler an den Client zurückgegeben.
Zum Abschluss ein Beispiel eines Unternehmenscomputers, der einen Hostnamen aus dem
privaten Namespace eines zusammengeführten Unternehmens auflösen muss.
Ein Computer in der YYY Corporation muss eine Verbindung zu einem Computer
"myname.zzz.com." herstellen.
Zunächst wird anhand der PAC-Datei festgestellt, dass es sich bei "myname.zzz.com." um
einen internen Namen handelt. Daher wird die Abfrage an den zugewiesenen DNS-Server
gesendet (Schritt 1). Falls der Cache die erforderlichen Daten enthält, antwortet der Server
dem Client. Andernfalls fragt der Server einen Stammserver ab (Schritt 2). Der
Stammserver, der die "."-Zone enthält, findet eine Delegierung an die Zone "zzz.com." und
gibt eine Referenz auf den autorisierenden Server zurück (Schritt 3). Der Server verwendet
die IP-Adresse des Namenservers, der die Zone "zzz.com." enthält, um die Abfrage zu
senden (Schritt 4). Da der Server autorisierend für "myname.zzz.com." ist, löst er die
Abfrage auf und gibt die Antwort zurück (Schritt 5). Schließlich gibt der Server die Antwort
an den Client zurück (Schritt 6).
Ein Computer in der ZZZ Corporation muss eine DNS-Abfrage für "myname.yyy.com."
auflösen. Er sendet die Abfrage an den zugewiesenen DNS-Server (Schritt 1). Falls der
Cache des Servers die erforderlichen Daten enthält, antwortet der Server dem Client.
Andernfalls leitet der Server die Abfrage an den DNS-Server weiter, der die Zone "zzz.com."
enthält (Schritt 2). Da dieser Server eine sekundäre Kopie der Zone "yyy.com." enthält, löst
er die Abfrage auf und gibt die Antwort über den vorherigen Server an den Client zurück
(Schritte 3-4).
Mit jeder der beiden vorgeschlagenen Lösungen sind Nachteile verbunden.
Die Lösung für das Unternehmen YYY erfordert die Wartung der PAC-Datei.
Die Lösung für das Unternehmen ZZZ bedeutet dagegen eine erhebliche Belastung der
internen DNS-Server, die die privaten Namespacezonen der obersten Ebene enthalten.
Denn die Mehrzahl der in dem Unternehmen generierten Abfragen wird an diese Server
weitergeleitet. Zudem enthalten diese Server im Fall derselben internen und externen
Namespaces größere Zonen, da sie sowohl interne als auch externe Namen enthalten
müssen.
Zeichen in Namen
Wie erwähnt sind die Standardzeichen für DNS nach RFC 1123 "A-Z", "a-z", "0-9" und "-".
In Organisationen, die erhebliche Investitionen in die Microsoft NetBIOS-Technologie
getätigt haben, entsprechen die Namen dem NetBIOS-Standard. Diese Organisationen
sollten ernsthaft in Erwägung ziehen, auf den DNS-Standard überzugehen.
Die Anpassung der Benennungskonventionen kann allerdings beträchtliche Zeit in Anspruch
nehmen. Windows 2000-DNS enthält Unterstützung für erweiterte ASCII- und UnicodeZeichen, um die Migration von Windows NT 4.0-NetBIOS-Namen zu Windows 2000-DNSNamen zu vereinfachen. Die Unterstützung für weitere Zeichen kann jedoch nur in einer
reinen Windows 2000-basierten Netzwerkumgebung genutzt werden, da Auflösungssoftware
von Drittanbietern, wie Unix oder Apple, überwiegend auf dem Standard von RFC 1123
basiert.
Anmerkung Wird bei der Installation von Windows 2000-DNS ein nicht standardmäßiger
DNS-Name eingegeben, wird eine Warnmeldung angezeigt, in der der Standard-DNS-Name
vorgeschlagen wird.
Computernamen
Windows NT 4.0 und frühere Versionen des Betriebssystems verwenden einen NetBIOSNamen zur Identifikation eines bestimmten Computers im Netzwerk. Ein Windows 2000basierter Computer kann durch einen NetBIOS-Namen (zugunsten der Interoperabilität mit
Vorgängerversionen) und einen vollständigen DNS-Computernamen (die Verkettung von
Hostname und primärem DNS-Suffix) gekennzeichnet werden. Das primäre DNS-Suffix ist
Teil der grundlegenden Computerkonfiguration und ist mit keinerlei Netzwerkkomponenten
verbunden. Nicht vernetzte oder nicht auf TCP/IP basierende Computer verfügen nicht über
ein primäres DNS-Suffix. Standardmäßig wird das primäre DNS-Suffix eines Computers auf
den DNS-Domänennamen des Active Directory festgelegt, dem er angeschlossen ist. Ein
Computeradministrator kann das primäre DNS-Suffix eines Computers ändern, indem er in
der Systemsteuerung auf System doppelklickt, dann auf die Registerkarte
Netzwerkidentifikation, auf Eigenschaften und dann auf Erweitert klickt und dann im
Feld Primäres DNS-Suffix des Computers ein Suffix eingibt. Über die Gruppenrichtlinien
könnte das primäre DNS-Suffix auch einer Gruppe von Computern zugewiesen werden.
Die folgende Tabelle enthält einen Vergleich zwischen einem NetBIOS-Namen und einem
DNS-Hostnamen.
NetBIOS-Name
Typ
Vollständiger
Computername
Flach
A-Z, a-z, 0-9,
Leerzeichen,
Zeicheneinschränku
Unicode-Zeichen,
ngen
Symbole: ! @ # $ %
^&')(.-_{}~
Maximale Länge
Namensdienst
Hierarchisch
A-Z, a-z, 0-9, Symbole:
-_, Unicode-Zeichen.
Der Punkt ('.') gilt als
Begrenzer für
Bezeichnungen.
63 UTF-8-Byte pro
16 Byte
Bezeichnung
(einschließlich eines
255 UTF-8-Byte für den
reservierten Bytes)
gesamten Namen
NBNS (WINS und
DNS
Broadcast)
Somit ist der NetBIOS-Name auf 15 Byte beschränkt, während ein Hostname maximal 63
Byte lang sein kann (DNS-Namen werden in UTF-8 codiert und belegen nicht
notwendigerweise ein Byte pro Zeichen).
Die Registerkarte Netzwerkidentifikation der Eigenschaftenseite Systemeigenschaften
enthält die folgenden Einträge:
 Computername: "MyComputer.MyCompany.com."
 Domäne: "MyCompany.com."
In diesem Beispiel ist "MyComputer" der Hostname und der NetBIOS-Name, während
"MyCompany.com" das primäre DNS-Suffix darstellt.
Adapterspezifische Benennung
Einem Computer mit mehreren Netzwerkadaptern können im Rahmen der IP-Konfiguration
der Adapter verschiedene Domänennamen zugewiesen werden. Die Adapter des Computers
können dann einzeln über ihre Hostnamen adressiert werden. Ein Beispiel dieser
Konfiguration ist nachstehend angegeben.
In der obigen Abbildung wird ein Computer mit dem Hostnamen "MyComputer" der Active
Directory-Domäne "MyCompany.com." zugeordnet. Sein primäres DNS-Suffix wird ebenfalls
auf "MyCompany.com." festgelegt.
Der erste Adapter, der dem öffentlichen Zugriff dient, wird mit dem DNS-Suffix
"example1.com." konfiguriert. Der zweite Adapter, der ausschließlich zu Sicherungszwecken
dient, hat das Suffix "example2.com.". Daher kann auf den Computer öffentlich über den
ersten Adapter mithilfe des DNS-Namens "MyComputer.example1.com." zugegriffen
werden. Für Datensicherungen kann auf denselben Computer über den zweiten Adapter
mithilfe des DNS-Namens "MyComputer.example2.com." zugegriffen werden.
Integrieren des Active Directory-Dienstes mit einer vorhandenen
DNS-Struktur
Damit ein DNS-Server Active Directory unterstützen kann, muss er die SRV-Einträge
unterstützen und sollte dynamische Aktualisierungen, wie in RFC 2136 beschrieben,
unterstützen.
Beim Integrieren von Active Directory in eine vorhandene DNS-Infrastruktur muss die
Entscheidung getroffen werden, ob der Active Directory-Namespace mit dem vorhandenen
DNS-Namespace verbunden werden oder sich mit ihm überschneiden soll.
Falls es keine Überschneidung gibt, können Sie einen neuen Windows 2000-DNSNamespace aus der vorhandenen DNS-Struktur delegieren. Wenn ein DNS-Namespace von
einer vorhandenen DNS-Struktur weg delegiert wird, wird der DNS-Server, der Besitzer der
Zonendatei für den neu delegierten Namespace ist, zum primären Master für diesen
Namespace. Der delegierte DNS-Zonenname sollte der Active Directory-Stammdomäne
entsprechen. Diese Vorgehensweise ist nicht zwingend, wird jedoch empfohlen, wenn Sie
die Vorzüge von Windows 2000-DNS-Server nutzen möchten. Sie können den vorhandenen
DNS-Server weiterhin verwenden, ohne den Active Directory-Namespace zu delegieren,
solange die aktuellen DNS-Server SRV-Einträge und die dynamische Aktualisierung
unterstützen.
Falls die Überschneidung unvermeidlich ist, hängt die weitere Vorgehensweise davon ab, ob
die vorhandene DNS-Struktur mithilfe von Windows NT 4.0-DNS oder einem nicht von
Microsoft stammenden Produkt implementiert ist.
Ist die vorhandene DNS-Struktur mit Windows NT 4.0-DNS implementiert, besteht die
Lösung in der Aktualisierung der Windows NT 4.0-DNS-Server auf die Windows 2000Implementierung von DNS.
Bei einer nicht von Microsoft stammenden Implementierung, die SRV-Ressourceneinträge
und dynamische Aktualisierungen nicht unterstützt, stellt sich die Frage: Kann sie
aktualisiert werden? Anmerkung: Die Funktion der dynamischen Aktualisierung ist nicht
erforderlich, jedoch sehr empfehlenswert.
Falls vorhandene, nicht von Microsoft stammende DNS-Server aktualisiert werden können,
führen Sie die Aktualisierung durch.
Falls vorhandene, nicht von Microsoft stammende DNS-Server nicht aktualisiert werden
können, fügen Sie einen weiteren DNS-Server hinzu, der SRV-Einträge und dynamische
Aktualisierungen unterstützt, und delegieren Sie bestimmte Zonen an diesen Server.
Delegieren Sie auf dem DNS-Server, der SRV-Einträge und dynamische Aktualisierungen
nicht unterstützt, die folgenden Zonen an den DNS-Server, der diese Funktionen
unterstützt: _tcp.<Active Directory domain name>, _udp.<Active Directory domain name>,
_msdcs.<Active Directory domain name> und _sites.<Active Directory domain name>.
Erstellen und aktivieren Sie auf dem DNS-Server, der diese Funktionen unterstützt, die
dynamische Aktualisierung für jede der Zonen in der vorherigen Liste. Active Directory
aktualisiert dynamisch die entsprechenden Einträge in diesen Zonen.
Der Vorgang, den Active Directory-Dienst in eine vorhandene DNS-Infrastruktur zu
integrieren, ist anhand des folgenden Flussdiagramms besser verständlich.
Migration nach Windows 2000-DNS
Der erste Schritt bei der Migration nicht von Microsoft stammender DNS-Server auf die
Windows 2000-Implementierung von DNS besteht darin, Windows 2000-DNS-Server als
sekundäre Server für die sich überschneidenden Zonen einzuführen. Einer der wesentlichen
Punkte ist dabei, eine Zonenübertragung von einem Masterserver auf einen sekundären
Windows 2000-DNS-Server zu konfigurieren und sicherzustellen, dass bei der
Zonenübertragung keine Fehler auftreten. Fehler können auftreten, wenn der Windows
2000-DNS-Server während der Zonenübertragung vom Nicht-Microsoft-DNS-Server
gesendete Einträge nicht erkennt. Diese Einträge sollten entweder repariert oder aus der
Zone entfernt werden, damit die Zonenübertragung erfolgreich abgeschlossen werden kann.
Sobald die Windows 2000-DNS-Server ihre neue Rolle stabil ausführen, können die
sekundären Zonen in verzeichnisintegrierte Zonen umgewandelt werden. An diesem Punkt
können die Nicht-Microsoft-DNS-Server ohne Gefahr für die Sicherheit zurückgezogen und
aus dem Netzwerk entfernt werden.
Einsetzen von DNS zur Unterstützung von Active Directory
Wenn Sie eine neue Netzwerkumgebung entwerfen, ist der Einsatz von Active Directory und
Windows 2000-DNS relativ problemlos. Es kann jedoch vorkommen, dass der neu
entworfene Active Directory-Dienst in eine vorhandene DNS-Infrastruktur integriert werden
muss.
Partitionieren und Replikation (Wählen der Zonen)
Beim Entwerfen eines DNS-Namespace für ein Active Directory sollte vor allem Wert darauf
gelegt werden, eine effektive Partitions- und Replikationstopologie zu erstellen und
gleichzeitig die Netzwerklast durch Replikationen und Aktualisierungen möglichst niedrig zu
halten.
Folgende Domänen- und Zonenkonfiguration wird empfohlen:
 Zu jeder Active Directory-Domäne sollte es eine dem Domänennamen entsprechende
DNS-Zone geben. Diese Zone sollte auf einem DNS-Server konfiguriert werden, auf
dem die Domänencontroller in dieser Active Directory-Domäne ausgeführt werden.
Die Zone sollte Active Directory-integriert sein.
 DNS-Server sollten auf mindestens zwei Domänencontrollern in jeder Active
Directory-Domäne und auf mindestens einem Domänencontroller an jedem Standort
ausgeführt werden.
 Da die meisten auf das Suffix "_msdcs.<DnsForestName>" endenden Einträge
überall aus der Gesamtstruktur zugänglich sein sollten, ist es unter Umständen
nützlich, eine Zone "_msdcs.<DnsForestName>" aus der Zone "<DnsForestName>"
zu delegieren. Alle DNS-Server im Unternehmen, die über langsame oder nicht
permanente Verbindungen mit den primären Zonenservern für
"_msdcs.<DnsForestName>" verbunden sind, sollten als sekundäre Server für die
Zone"_msdcs.<DnsForestName>" konfiguriert werden. Ein DNS-Server an jedem
Standort sollte dafür konfiguriert sein, Zonenübertragungen für
"_msdcs.<DnsForestName>" von einem primären Server abzurufen. Alle anderen
DNS-Server an einem Standort rufen die Zonenübertragung von dem gewählten
DNS-Server an diesem Standort ab. Die primären Server sollten sekundäre Server
nicht von Änderungen in der Zone benachrichtigen. Die sekundären Server rufen
Aktualisierungen im Abstand des Erneuerungsintervalls für Zonen von den primären
Servern ab. Der DNS-Server, der die Zonenübertragung direkt vom primären Server
abruft, sollte dafür konfiguriert sein, alle anderen DNS-Server an demselben
Standort zu benachrichtigen. Diese Konfiguration belastet das Netzwerk nicht
übermäßig mit Zonenreplikationen und ermöglicht gleichzeitig den Clients in den
untergeordneten Domänen die Auflösung von an die Zone
"_msdcs.<DnsForestName>" gerichteten DNS-Abfragen, während die Verbindung
unterbrochen ist.
Die Konfiguration der Reverse-Lookups basiert nicht auf der Windows 2000Domänenstruktur. Sie basiert vielmehr auf dem Bereich von IP-Adressen, der einem
Unternehmen zugewiesen ist. Werden einem Unternehmen IP-Adressen der Klasse B wie z.
B. 172.56.X.Y. zugewiesen, wird ein Reverse-Lookup "56.172.in-addr.arpa." erstellt. Sie
kann Delegierungen an andere Domänen wie "1.56.172.in-addr.arpa.", "2.56.172.inaddr.arpa." usw. enthalten. Es besteht auch die Möglichkeit, klassenlose Reverse-Lookups
zu konfigurieren, wie im Internet Draft "Classless IN_ADDR.ARPA delegation" beschrieben.
Verwenden der automatischen Konfiguration
Die Windows 2000-Implementierung von DNS stellt einen Assistenten für die DNSServerkonfiguration zur Verfügung, der die Installation und Konfiguration eines DNSServers wesentlich vereinfacht. Beispielsweise bietet er eine elegante Methode für die
Vorbereitung der Hinweise auf den Stammserver für einen neuen DNS-Server an.
Der Assistent für die DNS-Serverkonfiguration sendet an die bevorzugten (und
möglicherweise alternativen) DNS-Server des Computers eine NS-Abfrage nach dem
Stammknoten ".". Die Antwort wird in die Hinweise auf den Stammserver für diesen neuen
Server eingetragen. Falls keine Stammserver gefunden werden, sendet der Assistent
dieselbe Abfrage an die in der Datei cache.dns gespeicherten DNS-Server, die den
Stammservern im Internet entsprechen. Werden erneut keine Stammserver gefunden,
fordert der Assistent den Benutzer auf, den Server entweder zu einem Stammserver zu
erklären (durch Wählen der entsprechenden Option) oder die Hinweise auf den
Stammserver manuell anzugeben.
WINS-Referenz
WINS erfüllte für frühere Versionen von Windows NT die Funktion des Domänen- und
Computersuchdienstes. In einer Umgebung ohne NetBIOS ist WINS für Windows 2000 nicht
erforderlich. Dagegen ist WINS immer erforderlich in einer gemischten Umgebung, in der
Windows 2000-basierte Computer mit anderen Systemen wie Windows NT 4.0, Windows 9x
und Windows für Workgroups zusammenarbeiten.
WINS-Referenzen sind die empfohlene Methode für Windows 2000-DNS-Clients, um in
WINS registrierte Computer mit Vorgängerversionen zu adressieren. Da Windows 2000Auflöser für die Verwendung von DNS optimiert sind, wäre es wesentlich effizienter, Clients
mit Vorgängerversionen in einer DNS-Datenbank zu suchen als in einer WINS-Datenbank.
Um diese Art des Suchens zu ermöglichen, kann in DNS eine WINS-Referenzzone erstellt
werden, die auf die WINS-Datenbank verweist.
Diese Zone führt weder Registrierungen noch Aktualisierungen aus, sie verweist lediglich
DNS-Abfragen auf WINS.
Immer wenn Windows 2000-basierte Clients eine Abfrage mit dem unqualifizierten Namen
(z. B. ntservermydomain) senden, wird zunächst das Standarddomänennamensuffix
versucht. Bei der DHCP-Konfiguration können jedoch weitere Suffixe angegeben werden.
Falls der Name der WINS-Referenzzone einer davon ist, können alle WINS-Clientnamen
aufgelöst werden.
In der obigen Abbildung wurde eine WINS-Referenzzone mit dem Namen
wins.mydomain.microsoft.com. erstellt, die auf die WINS-Datenbank verweist.
Angenommen, ein Windows NT 4.0-basierter Client hat den Namen client1. Ein Windows
2000-basierter Client gehört zur Domäne mydomain.microsoft.com. Falls der Windows
2000-basierte Client bei der DHCP-Konfiguration das Suffix wins.mydomain.microsoft.com.
erhalten hat, wird beim Versuch, den unqualifizierten Namen client1 aufzulösen, zunächst
das Suffix mydomain.microsoft.com. versucht (also client1.mydomain.microsoft.com.).
Schlägt dies fehl, wird wins.mydomain.microsoft.com. versucht (also
client1.wins.mydomain.microsoft.com.). Wenn der autorisierende DNS-Server für die Zone
wins.mydomain.microsoft.com. die Abfrage empfängt, kann er den angeforderten Namen
nicht auflösen. Da er jedoch für die Verwendung von WINS-Lookup konfiguriert ist, sendet
er eine Abfrage für client1 an den WINS-Server. Der WINS-Server, der die entsprechende
Registrierung enthält, gibt die Host-IP-Adresse an den DNS-Server zurück, und dieser
übermittelt sie an den Windows 2000-basierten Client.
Zusammenfassung
Microsoft hat sich dafür entschieden, langfristig DNS als Namespace in Windows 2000
einzusetzen und damit das in früheren Versionen von Windows NT als Namensdienst
verwendete NetBIOS zu ersetzen.
Die Implementierung von DNS in Windows 2000 stellt eine einzigartige DNS-ServerImplementierung dar, die vollständig interoperabel mit anderen standardbasierten
Implementierungen von DNS-Servern ist. Es handelt sich um eine skalierbare,
hochverfügbare und hochleistungsfähige Lösung. Die folgenden Funktionen von Windows
2000-DNS machen es zu einer guten Wahl für Unternehmen, die eine zuverlässige,
hierarchische, verteilte Netzwerkumgebung implementieren möchten:
 Integration des Active Directory-Dienstes
 Inkrementelle Zonenübertragung (IXFR)
 Dynamische Aktualisierung und sichere dynamische Aktualisierung
 Unterstützung von Unicode-Zeichen
 Erweiterter Domänenlocator
 Erweiterter Cacheauflösungsdienst
 Erweiterter DNS-Manager
Für den ordnungsgemäßen Einsatz von DNS in der Windows 2000-basierten Umgebung
empfiehlt es sich, mit dem Active Directory-Entwurf zu beginnen und diesen dann durch
einen geeigneten DNS-Namespace zu unterstützen. Informationen zum Active DirectoryEntwurf finden Sie im Whitepaper "Windows 2000 Active Directory Namespace Design".
Weitere Informationen
Die neuesten Informationen zu Windows 2000 finden Sie im Microsoft TechNet oder in der
Microsoft-Website unter http://www.microsoft.com/windows/server/
(englischsprachig).
Glossar
AXFR - Typ der Zonendateireplikation. AXFR repliziert die gesamte Zone. (Siehe auch
IXFR.)
Autorisierender DNS-Server - Ein DNS-Server gilt als autorisierend für einen Namen,
wenn er die autorisierende Zone für diesen Namen lädt.
Autorisierende DNS-Zone - Eine DNS-Zone gilt als autorisierend für einen Namen, wenn
der Name zu der DNS-Unterstruktur gehört, die an diese Zone delegiert wurde.
DNS - Domain Name System.
IXFR - Typ der Zonendateireplikation. Bei der inkrementellen Zonenübertragung (IXFR)
werden nur die geänderten Einträge der Zone repliziert.
Master- und Slave-DNS-Server - Zwei DNS-Server werden als Master und Slave
bezeichnet, wenn sie Kopien derselben Zone enthalten, wobei eine davon direkt von der
anderen repliziert wird. Die Quelle der Replikation wird als Masterserver bezeichnet, das Ziel
der Replikation als Slaveserver. Jeder Master kann über einen oder mehrere Slaves
verfügen, und umgekehrt kann jeder Slave über einen oder mehrere Master verfügen.
Derselbe DNS-Server kann gleichzeitig Master und Slave sein.
Primäre und sekundäre Zonen - Dieselbe Zone kann durch primäre und sekundäre
Kopien repräsentiert sein. Die Ressourceneinträge der primären Zone bzw. Kopie können
direkt aktualisiert werden. Dagegen empfängt die sekundäre Zone bzw. Kopie alle
Aktualisierungen ausschließlich von primären oder sekundären Zonen über den
Mechanismus der Zonenübertragung. Nur verzeichnisdienstintegrierte Zonen können
mehrere primäre Zonen aufweisen. Mehrere sekundäre Zonen sind in jedem Szenario
zulässig.
Ressourceneintrag - Atomare Einheit der DNS-Datenbank. Alle Ressourceneinträge haben
dasselbe Format mit den Attributen NAME, TYPE, CLASS, TTL, RDLENGTH und RDATA, das
wiederum von den Attributen TYPE und CLASS des Ressourceneintrags abhängt. Ein Satz
von Ressourceneinträgen bildet eine DNS-Zone.
Stammserver - Ein DNS-Server, der eine Stammzone enthält, wird als Stammserver
bezeichnet.
Stammzone - Eine Zone, die die DNS-Stammdomäne enthält, wird als Stammzone
bezeichnet.
Gültigkeitsdauer (TTL) - Die Gültigkeitsdauer (Time-To-Live, TTL) bezeichnet den
Zeitraum, für den ein bestimmter Ressourceneintrag zwischengespeichert werden kann.
UCS-2 - Auch bekannt als Unicode, bezeichnet ein Zeichencodierungsprotokoll.
UTF-8 - Ein in RFC 2044 spezifiziertes Zeichencodierungsprotokoll.
WINS - Windows Name System (WINS) ist das vor DNS verwendete Namensystem. Es wird
in Windows 2000 weiterhin unterstützt, um die Interoperabilität zwischen verschiedenen
Generationen von Computern unter Windows zu bewahren.
Zonenübertragung - Der Vorgang der Replikation einer Zone vom Master- zum
Slaveserver.
© 1999 Microsoft Corporation. Alle Rechte vorbehalten.
Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der
Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf
sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens
Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach
dem Zeitpunkt der Veröffentlichung nicht garantieren.
Dieses Dokument dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIESES
DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT.
Microsoft, Active Directory, Windows und Windows NT sind eingetragene Marken oder
Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
Weitere in diesem Dokument aufgeführte Produkt- oder Firmennamen können geschützte
Marken ihrer jeweiligen Inhaber sein.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA
1099
1 Berkeley Internet Name Domain - Die BIND 8.1.1-DNS-Server-Implementierung
unterstützt sowohl SRV-Ressourceneinträge als auch dynamische Aktualisierung, stürzt
jedoch mit einem Speicherabbild ab, wenn Windows 2000-basierte Clients bestimmte
Aktualisierungen an sie senden. 8.1.2 ist die erste zuverlässig arbeitende BIND-Version.