DNS-Architektur in Windows Server

DNS besteht aus einer hierarchisch verteilten Datenbank und einem zugehörigen Satz von Protokollen, die Folgendes definieren:

• Einen Mechanismus zum Abfragen und Aktualisieren der Datenbank

• Einen Mechanismus zum Replizieren der Informationen in der Datenbank zwischen Servern

• Ein Schema der Datenbank

DNS-Hostnamen befinden sich in einer Datenbank, die auf mehrere Server verteilt werden kann, was die Last für einen einzelnen Server reduziert, und ermöglichen die Verwaltung dieses Benennungssystem auf Partitionsbasis. DNS unterstützt hierarchische Namen und ermöglicht die Registrierung verschiedener Datentypen, zusätzlich zur Zuordnung von Hostnamen zu IP Adressen in HOSTS-Dateien. Die DNS-Datenbank ist verteilt, sodass sie sowohl hoch- als auch horizontal skaliert werden kann. Das bedeutet, dass die Leistung nicht beeinträchtigt wird, wenn weitere Server hinzugefügt werden.

Das ursprüngliche DNS basierte auf Request for Comment (RFC) 1035 (Domain Names – Implementation and Specification).. Andere RFCs, die Probleme im Zusammenhang mit DNS-Sicherheit, -Implementierung und -Verwaltung beschreiben, ergänzten später die ursprünglichen Designspezifikationen.

Die in den Windows Server-Betriebssystemen verwendeten RFCs sind:

• Domänennamen – Konzepte und Einrichtungen RFC 1034
• Domänennamen – Implementierung und Spezifikation RFC 1035
• DNS-Erweiterungen zur Unterstützung der IP-Version 6 RFC 1886
• Ein Mechanismus für die Prompt Notification of Zone Changes (DNS NOTIFY) RFC 1996
• Inkrementelle Zonenübertragung in DNS RFC 1995
• Dynamische Updates im Domain Name System (DNS UPDATE)RFC 2136
• Negatives Zwischenspeichern von DNS-Abfragen (DNS NCACHE) RFC 2308
• Ressourceneinträge für die DNS-Sicherheitserweiterungen RFC 4034
• Protokolländerungen für die DNS-Sicherheitserweiterungen RFC 4035
• Ein DNS-RR zum Angeben des Standorts von Diensten (DNS SRV) RFC 2052

DNS-Domänennamen

DNS wird als hierarchische und verteilte Datenbank implementiert, die verschiedene Arten von Daten enthält, einschließlich Hostnamen und Domänennamen. Die Namen in einer DNS-Datenbank bilden eine hierarchische Struktur, die als „Domänennamespace“ bezeichnet wird. Domänennamen bestehen aus einzelnen Bezeichnungen, die durch Punkte getrennt werden, zum Beispiel: mydomain.contoso.com.

Ein vollständig qualifizierter Domänenname (Fully Qualified Domain Name, FQDN) identifiziert auf eindeutige Weise die Position des Hosts innerhalb der hierarchischen DNS-Struktur. Der FQDN gibt eine Liste von durch Punkte getrennten Namen im Pfad vom referenzierten Host zum Stamm an. Die folgende Abbildung zeigt ein Beispiel für eine DNS-Struktur mit einem Host namens mydomain innerhalb der Domäne contoso.com an. Der FQDN für den Host wäre mydomain.contoso.com.

Informationen zum DNS-Domänennamespace

Der DNS-Domänennamespace basiert, wie in der vorherigen Abbildung gezeigt, auf dem Konzept einer Struktur mit benannten Domänen. Jede Ebene der Struktur kann einen Zweig oder ein Blatt darstellen. Ein Zweig ist eine Ebene, auf der mehr als ein Name verwendet wird, um eine Auflistung benannter Ressourcen zu identifizieren. Ein Blatt stellt einen einzelnen Namen dar, der einmal auf dieser Ebene verwendet wird, um eine bestimmte Ressource anzugeben.

Hierarchie der DNS-Domänennamen

DNS-Clients und -Server verwenden Abfragen als Methode, um Namen in der Struktur in bestimmte Typen von Ressourceninformationen aufzulösen. Diese Informationen werden von DNS-Servern in Abfrageantworten an DNS-Clients bereitgestellt, die diese Informationen anschließend extrahieren und an ein anforderndes Programm übergeben, um den abgefragten Namen aufzulösen. Bei der Auflösung eines Namens dienen DNS-Server häufig als DNS-Clients, die andere Server abfragen, um einen abgefragten Namen vollständig aufzulösen.

Beispielsweise wird Contoso von den Internetstammservern die Berechtigung für seinen eigenen Teil der DNS-Domänennamespacestruktur im Internet zugewiesen, d. h. contoso.com. Das Auflösen eines Namens außerhalb des Namespace contoso.com erfordert, dass die DNS-Server von Contoso andere DNS-Server abfragen, z. B. die Stammserver.

Organisation des DNS-Domänennamespace

Jeder DNS-Domänenname, der in der Struktur verwendet wird, ist technisch gesehen eine Domäne. In den meisten DNS-Diskussionen werden Namen jedoch auf eine von fünf Arten identifiziert, basierend auf der Ebene und der Art und Weise, wie ein Name in der Regel verwendet wird. Der für Contoso registrierte DNS-Domänenname (contoso.com) wird z. B. als „Domäne der zweiten Ebene“ bezeichnet. Der Name besteht aus zwei Teilen (als Bezeichnungen bekannt), die angeben, dass er sich zwei Ebenen unter dem Stamm oder dem oberen Bereich der Struktur befindet. Die meisten DNS-Domänennamen verfügen über zwei oder mehr Bezeichnungen. Jede Bezeichnung gibt eine neue Ebene in der Struktur an. Punkte werden in Bezeichnungen verwendet, um einzelne Bezeichnungen zu trennen.

In der folgenden Tabelle werden die fünf Kategorien von DNS-Domänennamen nach ihrer Funktion im Namespace beschrieben. Für jeden Kategorie wird ein Beispiel gegeben.

Nametyp	Description	Example
Stammdomäne	Die oberste Ebene der Struktur, die eine unbenannte Ebene darstellt; manchmal als zwei leere Anführungszeichen ("") angezeigt, die einen NULL-Wert angeben. Bei Verwendung in einem DNS-Domänennamen wird durch einen nachgestellten Punkt (.) angegeben, dass sich der Name auf der Stamm- oder höchsten Ebene der Domänenhierarchie befindet. In diesem Fall wird der DNS-Domänenname als vollständig betrachtet und verweist auf eine genaue Position in der Namensstruktur. Namen, die auf diese Weise angegeben werden, sind FQDNs. Ein einzelner Punkt (.) oder ein Punkt, der am Ende eines Namens verwendet wird, z. B. example.contoso.com.	Ein einzelner Punkt (.) oder ein Punkt, der am Ende eines Namens verwendet wird, z. B. example.contoso.com.
Domäne der obersten Ebene (Top-Level-Domain, TLD)	Ein Name, der zur Angabe eines Landes oder einer Region oder der Art der Organisation verwendet wird, die einen Namen verwendet.	.com, was einen Namen angibt, der im Internet für ein Unternehmen zur kommerziellen Nutzung registriert ist.
Domäne der zweiten Ebene	Namen mit variabler Länge, die für eine Person oder Organisation zur Verwendung im Internet registriert sind. Diese Namen basieren immer auf einer geeigneten Domäne auf oberster Ebene, abhängig von der Art der Organisation oder dem geografischen Standort, an dem ein Name verwendet wird.	contoso.com. ist der Domänenname der zweiten Ebene, der von der Internet-DNS-Domänennamenregistrierungsstelle für Contoso registriert wurde.
Subdomain	Andere Namen, die eine Organisation erstellen kann und die vom registrierten Domänennamen der zweiten Ebene abgeleitet sind. Zu den Unterdomänen gehören Namen, die hinzugefügt wurden, um die DNS-Namensstruktur einer Organisation zu erweitern und sie in Abteilungen oder geografische Standorte zu unterteilen.	example.contoso.com. ist eine Unterdomäne, die von Contoso zur Verwendung in Dokumentationsbeispielnamen zugewiesen wird.
Host- oder Ressourcenname	Namen, die ein Blatt in der DNS-Namensstruktur darstellen und eine bestimmte Ressource identifizieren. In der Regel identifiziert die Bezeichnung ganz links in einem DNS-Domänennamen einen bestimmten Computer im Netzwerk. Ein Name auf dieser Ebene in einem Hostressourceneintrag (A) wird beispielsweise zur Suche der IP-Adresse des Computers basierend auf dem Hostnamen verwendet.	host-a.example.contoso.com. Die erste Bezeichnung (Host A) ist der DNS-Hostname für einen bestimmten Computer im Netzwerk.

DNS und Internetdomänen

Die Internetregistrierungsstellen verwalten das Domain Name System. Die Registrierungsstellen sind für die Wartung der Domänen auf oberster Ebene verantwortlich, die nach Organisation und nach Land/Region zugewiesen werden. Diese Domainnamen folgen dem internationalen Standard für Ländercodes (ISO 3166). Es gibt Hunderte von Namen für Domänen auf oberster Ebene, die von der Öffentlichkeit genutzt werden können. In der folgenden Tabelle werden einige häufige TLDs sowie Beispiele für Abkürzungen mit zwei Buchstaben aufgeführt, die für Länder und Regionen verwendet werden.

DNS-Domänenname	Typ der Organisation
.com	Kommerzielle Organisationen
.edu	Bildungseinrichtungen
.org	Gemeinnützige Organisationen
.net	Netzwerke (das Rückgrat des Internets)
.gov	Nichtmilitärische staatliche Organisationen
.mil	Militärische staatliche Organisationen
.arpa	Reverse DNS
.xx	Ländercodes mit zwei Buchstaben (z. B. .us, .au, .ca, .fr)

DNS-Ressourceneinträge

DNS-Ressourceneinträge enthalten die Informationen, die eine Zone zu den in ihr enthaltenen Ressourcen (z. B. Hosts) speichert. Ein typischer Ressourcendatensatz besteht aus Folgendem:

• Name (Host) des Ressourceneintrags
• Informationen dazu, wie lange der Ressourcendatensatz im Cache verbleiben kann
• Ressourceneintragstyp, z. B. Hostressourceneintrag (A)
• Für den Datensatztyp spezifische Daten, wie z. B. die IPv4-Adresse des Hosts.

Sie können Ressourceneinträge direkt hinzufügen. Alternativ können sie automatisch hinzugefügt werden, wenn Windows-basierte Clients mit DHCP-Unterstützung (Dynamic Host Configuration-Protokoll) über dynamische Updates einem Netzwerk beitreten.

Typen von Ressourceneinträgen

Zu den allgemeinen Ressourceneinträgen gehören folgende:

Typ des Ressourcendatensatzes	Description
Hosteinträge (A, AAAA)	Ordnet einen Hostnamen einer IP-Adresse zu.
Aliaseinträge (CNAME)	Weiterleiten eines Aliasdomänennamens oder einer Unterdomäne an einen anderen primären oder kanonischen Namen. Aliasressourceneinträge (CNAME) werden auch als kanonische Namensressourceneinträge bezeichnet. Bei diesen Einträgen können Sie mehrere DNS-Namen verwenden, um auf einen einzelnen Host zu verweisen.
MX-Einträge (Mail-Exchanger)	Gibt den Namen eines Computers an, der E-Mails austauscht oder weiterleitet. E-Mail-Anwendungen verwenden den MX-Ressourceneintrag (Mail-Exchanger), um einen E-Mail-Server anhand eines DNS-Domänennamens in der Zieladresse für den E-Mail-Empfänger zu suchen. Wenn mehrere MX-Ressourceneinträge vorhanden sind, versucht der DNS-Clientdienst, E-Mail-Server in der Prioritätsreihenfolge vom niedrigsten Wert (höchste Priorität) bis zum höchsten Wert (niedrigste Priorität) zu kontaktieren.
Einträge vom Typ „Zeiger“ (PTR)	Wird von Reverse-DNS-Lookups verwendet, um der Domäne eine IP-Adresse zuzuordnen. Ressourceneinträge vom Typ „Zeiger“ (PTR) unterstützen den Reverse-Lookupprozess basierend auf Zonen, die in der Domäne in-addr.arpa erstellt werden und dort ihren Stamm haben. Sie müssen über die entsprechende Reverse-Lookupzone auf Ihrem DNS-Server verfügen, um einen PTR-Eintrag zu erstellen, der eine IP-Adresse einem bestimmten Hostnamen zuordnet.
Dienstidentifizierungseinträge (Service Location, SRV)	Gibt den Host, den Port und das Protokoll für einen Dienst an. SRV-Ressourceneinträge sind erforderlich, wenn Clients DNS verwenden, um Standortdienste wie Active Directory-Domänencontroller zu finden.
Namenservereinträge (NS)	Gibt die autoritativen Namenserver für eine Domäne an.
Texteintrag (TXT)	Ermöglicht die Veröffentlichung von Text in einem DNS-Eintrag. Mit Textdatensätzen können Sie Textinformationen hinzufügen, die von DNS-Abfragen zurückgegeben werden. TXT-Einträge werden häufig verwendet, um den Besitz von DNS-Zonen zu authentifizieren.
Delegierungsnamenseinträge (DNAME)	Stellt einen Alias für eine Domäne bereit, z. B. einen CNAME-Eintrag, enthält aber alle Unterdomänen.
SOA-Einträge (Start of Authority, Autoritätsursprung)	Stellt autoritative Informationen zu einer DNS-Zone bereit. Der SOA-Eintrag enthält den primären Namenserver, die Kontaktdaten des DNS-Zonenadministrators, Aktualisierungsinformationen und weitere Informationen.

Gültigkeitsdauer für Ressourceneinträge

Der Time-to-Live (TTL)-Wert in einem Ressourceneintrag gibt die Zeitspanne an, die von anderen DNS-Servern verwendet wird, um festzulegen, wie lange Informationen für einen Datensatz zwischengespeichert werden sollen, bevor sie ablaufen und verworfen werden. Die meisten Ressourceneinträge, die vom DNS-Server-Dienst erstellt werden, erben beispielsweise die Mindest-TTL (Standard-TTL) von einer Stunde ab dem Start der Autorität (SOA) des Ressourceneintrags, was eine erweiterte Zwischenspeicherung durch andere DNS-Server verhindert.

Ein DNS-Clientresolver speichert die Antworten, die er beim Auflösen von DNS-Abfragen erhält, im Zwischenspeicher. Diese zwischengespeicherten Antworten können anschließend verwendet werden, um spätere Abfragen nach denselben Informationen zu beantworten. Die zwischengespeicherten Daten haben jedoch eine begrenzte Lebensdauer, die im TTL-Parameter angegeben wird, der mit den Antwortdaten zurückgegeben wird. Der TTL-Wert stellt sicher, dass der DNS-Server Informationen nicht so lange aufbewahrt, dass sie nicht mehr aktuell sind. Der TTL-Wert für den Cache kann wie folgt festgelegt werden: in der DNS-Datenbank (pro Ressourceneintrag durch Angabe des TTL-Felds für den Eintrag und pro Zone durch Angabe des Felds für den TTL-Mindestwert des SOA-Eintrags) und im DNS-Clientresolver durch Angabe der maximalen TTL-Werts, die der Resolver zum Zwischenspeichern der Ressourceneinträge zulässt.

Es gibt zwei konkurrierende Faktoren, die beim Festlegen des TTL-Werts berücksichtigt werden müssen. Der erste Faktor bezieht sich auf die Genauigkeit der zwischengespeicherten Informationen. Der zweite Faktor bezieht sich auf die Auslastung der DNS-Server und den Umfang des Netzwerkverkehrs. Wenn der TTL-Wert klein ist, wird die Wahrscheinlichkeit für alte Informationen erheblich reduziert. Die Auslastung von DNS-Servern und der Umfang des Netzwerkdatenverkehrs werden jedoch erhöht, da der DNS-Client bei der nächsten Anforderung die abgelaufenen Daten bei DNS-Servern abfragen muss. Wenn der TTL-Wert groß ist, können die zwischengespeicherten Antworten veraltet sein. Das bedeutet, dass der Resolver falsche Antworten auf Abfragen zurückgeben könnte. Gleichzeitig reduziert ein großer TTL-Wert die Auslastung der DNS-Server und den Umfang des Netzwerkverkehrs, da der DNS-Client Abfragen mithilfe der zwischengespeicherten Daten beantwortet.

Wenn eine Abfrage mit einem Eintrag aus dem Zwischenspeicher beantwortet wird, wird mit der Antwort auch der TTL-Wert des Eintrags übergeben. Auf diese Weise wissen die Resolver, die die Antwort erhalten, wie lange der Eintrag gültig ist. Die Resolver berücksichtigen die vom Antwortserver festgelegte TTL. Sie setzen diese nicht basierend auf ihrer eigenen TTL zurück. Daher laufen Einträge wirklich ab, anstatt dauerhaft zu bestehen, da sie von DNS-Server zu DNS-Server mit einer aktualisierten TTL wechseln.

Note

Sie sollten den TTL-Wert grundsätzlich niemals als null konfigurieren. Der Unterschied zwischen 0 und 60 hat für die Genauigkeit des Datensatzes lediglich minimale Bedeutung. Wenn jedoch die Gültigkeitsdauer auf 0 festgelegt ist, hat dies erhebliche Auswirkungen auf die Leistung des DNS-Servers, da der DNS-Server ständig die abgelaufenen Daten abfragt.

Zonen und Delegierung

Eine DNS-Datenbank kann in mehrere Zonen partitioniert werden. Eine Zone ist ein Bereich der DNS-Datenbank, der die Ressourceneinträge mit den Besitzernamen enthält, die zum zusammenhängenden Bereich des DNS-Namespace gehören. Zonendateien werden auf DNS-Servern verwaltet. Ein einzelner DNS-Server kann so konfiguriert werden, dass er keine, eine oder mehrere Zonen hostet.

Jede Zone ist in einem bestimmten Domänennamen verankert, der als Stammdomäne der Zone bezeichnet wird. Eine Zone enthält Informationen zu allen Namen, die mit dem Stammdomänennamen der Zone enden. Ein DNS-Server gilt als autoritativ für einen Namen, wenn er die Zone mit diesem Namen lädt. Der erste Eintrag in einer Zonendatei ist ein SOA (Start of Authority)-Ressourceneintrag. Der SOA-Ressourceneintrag identifiziert einen primären DNS-Namenserver für die Zone als beste Informationsquelle für die Daten in dieser Zone. Der SOA-Ressourceneintrag dient auch als Entität, die die Aktualisierungen für die Zone verarbeitet.

Ein Name innerhalb einer Zone kann auch an eine andere Zone delegiert werden, die auf einem anderen DNS-Server gehostet wird. Bei der Delegierung handelt es sich um einen Prozess, bei dem die Verantwortung für einen Teil eines DNS-Namespace einem DNS-Server zugewiesen wird, der sich im Besitz einer anderen Entität befindet. Bei dieser anderen Entität kann es sich um eine andere Organisation, Abteilung oder Arbeitsgruppe innerhalb Ihres Unternehmens handeln. Eine solche Delegierung wird durch den NS-Ressourceneintrag dargestellt, der die delegierte Zone und den DNS-Namen des für diese Zone autoritativen Servers angibt. Das Delegieren über mehrere Zonen hinweg war Teil des ursprünglichen Designziels des DNS.

Weitere Informationen zu den Typen und replikationen von DNS-Zonen finden Sie unter DNS-Zonen.

Zu den Gründen für das Delegieren eines DNS-Namespace gehören:

• Die Notwendigkeit, die Verwaltung einer DNS-Domäne an zahlreiche Organisationen oder Abteilungen innerhalb einer Organisation zu delegieren.

• Die Notwendigkeit, den Aufwand für die Verwaltung einer einzelnen großen DNS-Datenbank auf mehrere DNS-Server zu verteilen, um die Leistung der Namensauflösung zu verbessern und eine fehlertolerante DNS-Umgebung zu schaffen.

• Die Notwendigkeit, die organisatorische Zugehörigkeit eines Hosts zu berücksichtigen, indem der Host in die entsprechenden Domänen aufgenommen wird. Die Nameserver (NS)-Ressourceneinträge unterstützen die Delegierung durch die Identifizierung von DNS-Servern für jede Zone und die Anzeige von NS-Ressourceneinträge in allen Zonen. Wann immer ein DNS-Server eine Delegierung durchlaufen muss, um einen Namen aufzulösen, bezieht er sich auf die NS-Ressourceneinträge für die DNS-Server in der Zielzone.

Die folgende Abbildung zeigt, wie die Verwaltung der Domäne contoso.com über zwei Zonen delegiert wird, contoso.com und mydomain.contoso.com.

Note

Wenn mehrere NS-Einträge für eine delegierte Zone vorhanden sind, die mehrere für Abfragen verfügbare DNS-Server identifizieren, kann der Windows Server-DNS-Serverdienst den nächstgelegenen DNS-Server basierend auf den über die Zeit gemessenen Roundtripintervallen für jeden DNS-Server auswählen.

DNS-Dienstarchitektur

Das folgende Diagramm zeigt die Architektur des DNS-Clientdiensts in Bezug auf Namensauflösung und Aktualisierungsvorgänge im Windows-Client und in Windows Server. Die Architektur der Namensauflösung wird mithilfe einer Clientanwendung gezeigt. Aktualisierungen werden durch den DHCP-Client dargestellt.

Das folgende Diagramm zeigt die DNS-Serverdienstarchitektur mit ihren Verwaltungstools und die Windows Management Instrumentation (WMI)-Oberfläche in Windows Server.

In den folgenden Abschnitten werden der DNS-Abfrageprozess und die Behandlung von DNS-Updates beschrieben.

DNS-Abfragen

DNS-Abfragen können von einem DNS-Client (Resolver) an einen DNS-Server oder zwischen zwei DNS-Servern gesendet werden.

Eine DNS-Abfrage ist lediglich eine Anforderung von DNS-Ressourceneinträgen eines bestimmten Ressourceneintragstyps mit einem angegebenen DNS-Namen. Eine DNS-Abfrage kann beispielsweise alle Ressourceneinträge des Typs A (Host) mit einem angegebenen DNS-Namen anfordern.

Es gibt zwei Arten von DNS-Abfragen, die an einen DNS-Server gesendet werden können:

• Rekursiv: Eine rekursive Abfrage erzwingt, dass ein DNS-Server auf eine Anforderung mit einem Fehler oder einer Erfolgsantwort reagiert. DNS-Clients (Resolver) führen in der Regel rekursive Abfragen aus. Bei einer rekursiven Abfrage muss der DNS-Server alle anderen DNS-Server kontaktieren, die er zur Auflösung der Anforderung benötigt. Wenn er eine erfolgreiche Antwort vom anderen DNS-Server (oder von den anderen DNS-Servern) erhält, sendet er eine Antwort an den DNS-Client. Die rekursive Abfrage ist der typische Abfragetyp, den ein Resolver bei der Abfrage eines DNS-Servers und ein DNS-Server bei der Abfrage der Weiterleitung verwendet. Bei einer Weiterleitung handelt es sich um einen anderen DNS-Server, der für die Verarbeitung von Anforderungen konfiguriert ist, die an ihn weitergeleitet werden.

  Wenn ein DNS-Server eine rekursive Abfrage verarbeitet und die Abfrage nicht anhand lokaler Daten (Dateien in der lokalen Zone oder im Zwischenspeicher für frühere Abfragen) aufgelöst werden kann, muss die rekursive Abfrage an einen DNS-Stammserver eskaliert werden. Jede standardbasierte DNS-Implementierung enthält eine Cache-Datei (oder Stammserverhinweise), die Einträge für die DNS-Stammserver der Internetdomänen enthält. (Wenn der DNS-Server mit einer Weiterleitung konfiguriert ist, wird die Weiterleitung verwendet, bevor ein Stammserver verwendet wird.)

• Iterativ: Eine iterative Abfrage ist eine Abfrage, in der der DNS-Server erwartet wird, mit den besten lokalen Informationen zu antworten, die er hat, basierend auf dem, was der DNS-Server aus lokalen Zonendateien oder vom Zwischenspeichern kennt. Diese Antwort wird auch als Verweis bezeichnet, wenn der DNS-Server für den Namen nicht autoritativ ist. Wenn ein DNS-Server keine lokalen Informationen besitzt, mit denen die Abfrage beantwortet werden kann, sendet er einfach eine negative Antwort. Ein DNS-Server führt diese Art von Abfragen aus, wenn er versucht, Namen außerhalb seiner lokalen Domäne (oder seiner lokalen Domänen) zu finden (wenn er nicht mit einer Weiterleitung konfiguriert ist). Möglicherweise müssen externe DNS-Server abgefragt werden, um den Namen aufzulösen.

Die folgende Abbildung zeigt ein Beispiel für beide Arten von Abfragen.

Das Diagramm zeigt die Verwendung mehrerer Abfragen zur Ermittlung der IP-Adresse für www.contoso.com. Die Abfragesequenz wird wie folgt beschrieben:

1. Rekursive Abfrage für www.contoso.com (ein Ressourceneintrag).

2. Iterative Abfrage für www.contoso.com (ein Ressourcendatensatz).

3. Verweis auf den Namenserver .com (NS-Ressourceneinträge, für .com); der Einfachheit halber wurden iterative A-Abfragen durch den DNS-Server zur Auflösung der IP-Adressen der Hostnamen des Namenservers ausgelassen, die von anderen DNS-Servern zurückgegeben werden.

4. Iterative Abfrage für www.contoso.com (ein Ressourcendatensatz).

5. Verweis auf den contoso.com Namenserver (NS-Ressourceneintrag, für contoso.com).

6. Iterative Abfrage für www.contoso.com (ein Ressourcendatensatz).

7. Antwort auf die iterative Abfrage des Servers contoso.com (die IP-Adresse von www.contoso.com).

8. Antwort auf die ursprüngliche rekursive Abfrage des lokalen DNS-Servers für den Resolver (die IP-Adresse von www.contoso.com).

Aktualisieren von DNS

Ressourceneinträge ändern sich häufig, wenn Computer, Server und Geräte zum Netzwerk hinzugefügt oder aus dem Netzwerk entfernt werden. Die DNS-Implementierung in Windows Server unterstützt sowohl statische als auch dynamische Updates der DNS-Datenbank.

Ressourceneinträge können einer vorhandenen Zone mithilfe des PowerShell-Befehls "Add-DNSServerResourceRecord" hinzugefügt werden. Einige gängige Ressourceneintragstypen verfügen über andere PowerShell-Befehle, bei denen Sie den Ressourceneintragstyp nicht angeben müssen. Sie können Ressourceneinträge auch mithilfe der DNS-Manager-Konsole hinzufügen. Unter Verwalten von DNS-Ressourceneinträgen finden Sie Anleitungen zur Verwendung von Ressourceneinträgen und erfahren u. a., wie Sie vorhandene Ressourceneinträge aller Typen erstellen und ändern.

Unterstützung von Unicode-Zeichen

Als DNS als Teil von RFC 1035 eingeführt wurde, waren Namen auf die Verwendung von Groß- und Kleinbuchstaben (A-Z, a-z), Zahlen (0–9) und Bindestrichen (-) eingeschränkt. Darüber hinaus kann das erste Zeichen des DNS-Namens eine Zahl sein. Namen müssen codiert und mit US-ASCII-basierten Zeichen dargestellt werden. Für die Verwendung von DNS in internationalen Umgebungen führt diese Anforderung zu erheblichen Einschränkungen, wenn erweiterte Zeichensätze für lokale Benennungsstandards verwendet werden. Der Windows Server-DNS-Dienst stellt über die RFC 1035-Spezifikation hinaus eine erweiterte Unterstützung für UTF-8-Zeichen bereit.

Was ist UTF-8?

UTF-8 ist der empfohlene Zeichensatz für Protokolle über die Verwendung von ASCII hinaus. Das UTF-8-Protokoll ermöglicht die Unterstützung erweiterter ASCII-Zeichen und die Übersetzung von UCS-2, einem 16-Bit-Unicode-Zeichensatz, der die meisten Schriftsysteme der Welt berücksichtigt. UTF-8 ermöglicht daher eine weitaus größere Auswahl an Namen, als dies mit der ASCII- oder der erweiterten ASCII-Codierung für Zeichendaten erreicht werden kann.

Computer mit Windows Server 2008 sind UTF-8-fähig. Wenn UTF-8-codierte Zeichen als Daten vom Server empfangen oder verwendet werden, kann der Server diese Daten in seinen Zonen laden und speichern. Obwohl Windows-basierte DNS-Server UTF-8-fähig sind, bleiben sie mit anderen DNS-Servern kompatibel, die eine herkömmliche US-ASCII Datencodierung und aktuelle DNS-Standards verwenden.

Implementierung von UTF-8 durch den DNS-Dienst

Um die Kompatibilität von Standards und die Interoperabilität mit anderen DNS-Implementierungen sicherzustellen, verwendet der DNS-Dienst eine einheitliche Kleinschreibung aller empfangenen Zeichendaten. Bei diesem Vorgang konvertiert der DNS-Dienst aus folgenden Gründen alle Großbuchstaben, die in standardmäßigen US-ASCII-Daten verwendet werden, in die entsprechenden Kleinbuchstaben:

• Zur Wahrung der Kompatibilität mit aktuellen und vorhandenen DNS-Standards.
• Zur Wahrung der Interoperabilität mit DNS-Serverimplementierungen, die die UTF-8-Codierung nicht erkennen oder unterstützen.

Um zu verstehen, warum ein einheitliches Downcasing gewählt wurde, müssen zunächst mehrere verwandte Punkte aus den aktuellen überarbeiteten Internetstandards für DNS berücksichtigt werden. Mehrere wichtige Punkte in den Standards beziehen sich direkt darauf, wie Zeichendaten zwischen DNS-Servern und anderen Servern und Clients behandelt werden sollen. Wichtige Punkte sind:

• Jede binäre Zeichenfolge kann in einem DNS-Namen verwendet werden. (RFC 2181)
• DNS-Server müssen in der Lage sein, Namen ohne Berücksichtigung von Groß- und Kleinschreibung zu vergleichen. (RFC 1035)
• Bei der Eingabe von Zeichendaten in das System sollte die Groß-/Kleinschreibung möglichst beibehalten werden. (RFC 1035)

Da die Nicht-Berücksichtigung von Groß-/Kleinschreibung ein erforderlicher Bestandteil des Kern-DNS-Standards ist und die Erhaltung der Groß-/Kleinschreibung eine optionale Empfehlung ist, wurde eine einheitliche Downcasing-Lösung ausgewählt, um eine effektive, standardkonforme Lösung bereitzustellen. Durch die Kleinschreibung von UTF-8-codierten Namen vor der Übertragung können andere DNS-Server (die nicht UTF-8-fähig sind) erfolgreiche binäre Vergleiche der Daten empfangen und ausführen und die gewünschten Ergebnisse erzielen.

Überlegungen zur Interoperabilität mit UTF-8

Der DNS-Serverdienst kann so festgelegt werden, dass die Verwendung von UTF-8-Zeichen für jeden Server zugelassen oder blockiert wird. Einige DNS-Server, die UTF-8 nicht unterstützen, akzeptieren möglicherweise Zonen mit UTF-8-Namen, haben jedoch möglicherweise Probleme beim Speichern oder erneuten Laden dieser Namen. Seien Sie daher vorsichtig, wenn Sie Zonen mit UTF-8-Namen auf Server übertragen, die UTF-8 nicht unterstützen.

Einige Protokolle schränken die Zeichen ein, die in einem Namen zulässig sind. Darüber hinaus sollten Namen, die global sichtbar sein sollen (RFC 1958), reine ASCII-Zeichen enthalten, wie in RFC 1123 empfohlen.

Die Verwendung von UTF-8 zum Transformieren von Unicode-Zeichen ist für Benutzer nicht sichtbar. UTF-8-codierte Zeichen werden jedoch angezeigt, wenn Sie den Netzwerkmonitor oder ein ähnliches Tool zum Analysieren des DNS-Datenverkehrs verwenden.

Zusätzlich zur Unterstützung für das UTF-8-Codierungsformat durch DNS-Server verwendet der Clientresolver standardmäßig das UTF-8-Zeichencodierungsformat.

Im UTF-8-Format codierte Namen dürfen die in RFC 2181 beschriebenen Größenbeschränkungen nicht überschreiten, die maximal 63 Oktette pro Bezeichnung und 255 Oktette pro Name betragen. Die Zeichenzahl reicht nicht aus, um die Größe zu bestimmen, da einige UTF-8-Zeichen länger als ein Oktett sind.

Das UTF-8-Codierungsprotokoll kann für die Verwendung mit vorhandenen DNS-Protokollimplementierungen angepasst werden, die US-ASCII-Zeichen erwarten, da die Darstellung von US-ASCII-Zeichen in UTF-8 mit der US-ASCII-Darstellung Byte für Byte identisch ist. DNS-Client- oder -Serverimplementierungen, die UTF-8-Zeichen nicht erkennen, codieren Namen stets im US-ASCII-Format. Der DNS-Serverdienst kann diese Namen korrekt interpretieren.

Der DNS-Dienst kann die Namensüberprüfung so konfigurieren, dass die Verwendung von UTF-8-Zeichen in DNS-Daten zugelassen oder eingeschränkt wird.

Standardmäßig wird die UTF-8-Multibyte-Namensprüfung verwendet, die die größte Toleranz bei der Verarbeitung von Zeichen durch den DNS-Dienst ermöglicht. Die UTF-8-Multibyte-Namensprüfung ist die bevorzugte Methode zur Namensprüfung für die meisten privat ausgeführten DNS-Server, die keinen Namensdienst für Internethosts bereitstellen.