4. NAMESERVER (NAME SERVERS)

4.1. Einführung (Introduction)

Nameserver sind die Repositories von Informationen, die die Domänendatenbank bilden. Die Datenbank ist in Abschnitte unterteilt, die Zonen genannt werden und unter den Nameservern verteilt sind. Während Nameserver mehrere optionale Funktionen und Datenquellen haben können, ist die wesentliche Aufgabe eines Nameservers, Abfragen unter Verwendung von Daten in seinen Zonen zu beantworten. Durch das Design können Nameserver Abfragen auf einfache Weise beantworten; die Antwort kann immer nur unter Verwendung lokaler Daten generiert werden und enthält entweder die Antwort auf die Frage oder eine Verweisung auf andere Nameserver, die der gewünschten Information "näher" sind.

Eine bestimmte Zone wird von mehreren Nameservern verfügbar sein, um ihre Verfügbarkeit trotz Host- oder Kommunikationslinkausfällen sicherzustellen. Durch administrative Anordnung verlangen wir, dass jede Zone auf mindestens zwei Servern verfügbar ist, und viele Zonen haben mehr Redundanz als das.

Ein bestimmter Nameserver wird typischerweise eine oder mehrere Zonen unterstützen, aber dies gibt ihm nur autoritative Informationen über einen kleinen Abschnitt des Domänenbaums. Er kann auch einige gecachte nicht-autoritative Daten über andere Teile des Baums haben. Der Nameserver markiert seine Antworten auf Abfragen, sodass der Anfragende sagen kann, ob die Antwort von autoritativen Daten stammt oder nicht.

4.2. Wie die Datenbank in Zonen unterteilt ist (How the database is divided into zones)

Die Domänendatenbank ist auf zwei Arten partitioniert: nach Klasse und durch "Schnitte" im Namensraum zwischen Knoten.

Klassenpartitionierung (Class partitioning)

Die Klassenpartition ist einfach. Die Datenbank für jede Klasse ist separat von allen anderen Klassen organisiert, delegiert und gepflegt. Da konventionsgemäß die Namensräume für alle Klassen gleich sind, können die separaten Klassen als Array paralleler Namensraum-Bäume betrachtet werden. Beachten Sie, dass die an Knoten angehängten Daten für diese verschiedenen parallelen Klassen unterschiedlich sein werden. Die häufigsten Gründe für die Erstellung einer neuen Klasse sind die Notwendigkeit eines neuen Datenformats für bestehende Typen oder der Wunsch nach einer separat verwalteten Version des bestehenden Namensraums.

Zonenschnitte (Zone cuts)

Innerhalb einer Klasse können "Schnitte" im Namensraum zwischen zwei beliebigen benachbarten Knoten vorgenommen werden. Nachdem alle Schnitte vorgenommen wurden, ist jede Gruppe von verbundenem Namensraum eine separate Zone. Die Zone gilt als autoritativ für alle Namen in der verbundenen Region. Beachten Sie, dass die "Schnitte" im Namensraum für verschiedene Klassen an unterschiedlichen Stellen sein können, die Nameserver unterschiedlich sein können usw.

Diese Regeln bedeuten, dass jede Zone mindestens einen Knoten und damit einen Domänennamen hat, für den sie autoritativ ist, und alle Knoten in einer bestimmten Zone verbunden sind. Aufgrund der Baumstruktur hat jede Zone einen höchsten Knoten, der näher an der Wurzel ist als jeder andere Knoten in der Zone. Der Name dieses Knotens wird oft verwendet, um die Zone zu identifizieren.

Es wäre möglich, wenn auch nicht besonders nützlich, den Namensraum so zu partitionieren, dass jeder Domänenname in einer separaten Zone wäre oder dass alle Knoten in einer einzigen Zone wären. Stattdessen wird die Datenbank an Punkten partitioniert, an denen eine bestimmte Organisation die Kontrolle über einen Teilbaum übernehmen möchte. Sobald eine Organisation ihre eigene Zone kontrolliert, kann sie die Daten in der Zone einseitig ändern, neue Baumabschnitte wachsen lassen, die mit der Zone verbunden sind, bestehende Knoten löschen oder neue Subzonen unter ihrer Zone delegieren.

Wenn die Organisation eine Unterstruktur hat, möchte sie möglicherweise weitere interne Partitionen vornehmen, um verschachtelte Delegierungen der Namensraumkontrolle zu erreichen. In einigen Fällen werden solche Aufteilungen rein vorgenommen, um die Datenbankwartung bequemer zu machen.

4.2.1. Technische Überlegungen (Technical considerations)

Die Daten, die eine Zone beschreiben, haben vier Hauptteile:

• Autoritative Daten (Authoritative data) für alle Knoten innerhalb der Zone.
• Daten, die den obersten Knoten definieren (Data that defines the top node) der Zone (können als Teil der autoritativen Daten betrachtet werden).
• Daten, die delegierte Subzonen beschreiben (Data that describes delegated subzones), d.h. Schnitte um den Boden der Zone herum.
• Daten, die den Zugriff auf Nameserver für Subzonen ermöglichen (Data that allows access to name servers for subzones) (manchmal "Kleber"-Daten genannt).

All diese Daten werden in Form von RRs ausgedrückt, sodass eine Zone vollständig in Bezug auf eine Menge von RRs beschrieben werden kann. Ganze Zonen können zwischen Nameservern übertragen werden, indem die RRs übertragen werden, entweder in einer Reihe von Nachrichten oder durch FTP einer Masterdatei, die eine textuelle Darstellung ist.

Autoritative Daten (Authoritative data)

Die autoritativen Daten für eine Zone sind einfach alle RRs, die an alle Knoten vom obersten Knoten der Zone bis zu den Blattknoten oder Knoten oberhalb von Schnitten am unteren Rand der Zone angehängt sind.

Obwohl logisch Teil der autoritativen Daten, sind die RRs, die den obersten Knoten der Zone beschreiben, besonders wichtig für die Verwaltung der Zone. Diese RRs sind von zwei Typen: Nameserver-RRs, die einen pro RR alle Server für die Zone auflisten, und ein einzelner SOA-RR, der Zonenverwaltungsparameter beschreibt.

Delegierungsdaten (Delegation data)

Die RRs, die Schnitte um den Boden der Zone herum beschreiben, sind NS-RRs, die die Server für die Subzonen benennen. Da die Schnitte zwischen Knoten liegen, sind diese RRs NICHT Teil der autoritativen Daten der Zone und sollten genau dieselben sein wie die entsprechenden RRs im obersten Knoten der Subzone. Da Nameserver immer mit Zonengrenzen verbunden sind, werden NS-RRs nur an Knoten gefunden, die der oberste Knoten einer Zone sind. In den Daten, die eine Zone bilden, werden NS-RRs am obersten Knoten der Zone gefunden (und sind autoritativ) und an Schnitten um den Boden der Zone herum (wo sie nicht autoritativ sind), aber niemals dazwischen.

Kleberdaten (Glue data)

Eines der Ziele der Zonenstruktur ist, dass jede Zone alle Daten hat, die erforderlich sind, um Kommunikationen mit den Nameservern für beliebige Subzonen einzurichten. Das heißt, Elternzonen haben alle Informationen, die benötigt werden, um auf Server für ihre Kindzonen zuzugreifen. Die NS-RRs, die die Server für Subzonen benennen, reichen für diese Aufgabe oft nicht aus, da sie die Server benennen, aber ihre Adressen nicht angeben. Insbesondere wenn der Name des Nameservers selbst in der Subzone ist, könnten wir mit der Situation konfrontiert sein, in der die NS-RRs uns sagen, dass wir, um die Adresse eines Nameservers zu lernen, den Server unter Verwendung der Adresse kontaktieren sollten, die wir lernen möchten. Um dieses Problem zu beheben, enthält eine Zone "Kleber"-RRs, die nicht Teil der autoritativen Daten sind und Adress-RRs für die Server sind. Diese RRs sind nur notwendig, wenn der Name des Nameservers "unterhalb" des Schnitts ist, und werden nur als Teil einer Verweisungsantwort verwendet.

4.2.2. Administrative Überlegungen (Administrative considerations)

Wenn eine Organisation ihre eigene Domäne kontrollieren möchte, besteht der erste Schritt darin, die richtige Elternzone zu identifizieren und die Eigentümer der Elternzone dazu zu bringen, der Delegierung der Kontrolle zuzustimmen. Während es keine besonderen technischen Einschränkungen gibt, wo im Baum dies getan werden kann, gibt es einige administrative Gruppierungen, die in [RFC-1032] diskutiert werden, die sich mit der Organisation auf oberster Ebene befassen, und Zonen auf mittlerer Ebene können frei ihre eigenen Regeln erstellen. Zum Beispiel könnte eine Universität wählen, eine einzige Zone zu verwenden, während eine andere wählen könnte, sich durch Subzonen zu organisieren, die einzelnen Abteilungen oder Schulen gewidmet sind. [RFC-1033] katalogisiert verfügbare DNS-Software und diskutiert Verwaltungsverfahren.

Sobald der richtige Name für die neue Subzone ausgewählt ist, sollten die neuen Eigentümer aufgefordert werden, redundante Nameserver-Unterstützung nachzuweisen. Beachten Sie, dass es keine Anforderung gibt, dass die Server für eine Zone in einem Host mit einem Namen in dieser Domäne residieren. In vielen Fällen wird eine Zone für das Internet insgesamt zugänglicher sein, wenn ihre Server weit verteilt sind, anstatt sich in den physischen Einrichtungen zu befinden, die von derselben Organisation kontrolliert werden, die die Zone verwaltet. Zum Beispiel befindet sich im aktuellen DNS einer der Nameserver für das Vereinigte Königreich oder die UK-Domäne in den USA. Dies ermöglicht es US-Hosts, UK-Daten zu erhalten, ohne begrenzte transatlantische Bandbreite zu verwenden.

Als letzter Installationsschritt sollten die Delegierungs-NS-RRs und Kleber-RRs, die erforderlich sind, um die Delegierung wirksam zu machen, zur Elternzone hinzugefügt werden. Die Administratoren beider Zonen sollten sicherstellen, dass die NS- und Kleber-RRs, die beide Seiten des Schnitts markieren, konsistent sind und bleiben.

4.3. Nameserver-Interna (Name server internals)

4.3.1. Abfragen und Antworten (Queries and responses)

Die Hauptaktivität von Nameservern ist es, Standardabfragen zu beantworten. Sowohl die Abfrage als auch ihre Antwort werden in einem Standardnachrichtenformat übertragen, das in [RFC-1035] beschrieben wird. Die Abfrage enthält einen QTYPE, QCLASS und QNAME, die die Arten und Klassen der gewünschten Information und den Namen von Interesse beschreiben.

Die Art und Weise, wie der Nameserver die Abfrage beantwortet, hängt davon ab, ob er im rekursiven Modus arbeitet oder nicht:

• Nicht-rekursiver Modus (Non-recursive mode): Der einfachste Modus für den Server ist nicht-rekursiv, da er Abfragen nur unter Verwendung lokaler Informationen beantworten kann: Die Antwort enthält einen Fehler, die Antwort oder eine Verweisung auf einen anderen Server, der der Antwort "näher" ist. Alle Nameserver müssen nicht-rekursive Abfragen implementieren.

• Rekursiver Modus (Recursive mode): Der einfachste Modus für den Client ist rekursiv, da in diesem Modus der Nameserver in der Rolle eines Resolvers agiert und entweder einen Fehler oder die Antwort zurückgibt, aber niemals Verweisungen. Dieser Dienst ist in einem Nameserver optional, und der Nameserver kann auch wählen, die Clients einzuschränken, die den rekursiven Modus verwenden können.

Wann rekursiver Dienst zu verwenden ist (When to use recursive service)

Rekursiver Dienst ist in mehreren Situationen hilfreich:

• Ein relativ einfacher Anfragender, dem die Fähigkeit fehlt, etwas anderes als eine direkte Antwort auf die Frage zu verwenden.
• Eine Anfrage, die Protokoll- oder andere Grenzen überschreiten muss und an einen Server gesendet werden kann, der als Vermittler fungieren kann.
• Ein Netzwerk, in dem wir den Cache konzentrieren möchten, anstatt einen separaten Cache für jeden Client zu haben.

Nicht-rekursiver Dienst ist angemessen, wenn der Anfragende in der Lage ist, Verweisungen zu verfolgen und an Informationen interessiert ist, die zukünftige Anfragen unterstützen.

Rekursionsverhandlung (Recursion negotiation)

Die Verwendung des rekursiven Modus ist auf Fälle beschränkt, in denen sowohl der Client als auch der Nameserver seiner Verwendung zustimmen. Die Vereinbarung wird durch die Verwendung von zwei Bits in Abfrage- und Antwortnachrichten ausgehandelt:

• Das Rekursion-verfügbar-Bit (RA) (The recursion available bit) wird von einem Nameserver in allen Antworten gesetzt oder gelöscht. Das Bit ist wahr, wenn der Nameserver bereit ist, rekursiven Dienst für den Client bereitzustellen, unabhängig davon, ob der Client rekursiven Dienst angefordert hat. Das heißt, RA signalisiert Verfügbarkeit statt Verwendung.

• Abfragen enthalten ein Rekursion-gewünscht-Bit (RD) (Queries contain a recursion desired bit). Dieses Bit gibt an, ob der Anfragende rekursiven Dienst für diese Abfrage wünscht. Clients können rekursiven Dienst von jedem Nameserver anfordern, sollten sich aber nur auf den Empfang von Servern verlassen, die zuvor ein RA gesendet haben, oder von Servern, die zugestimmt haben, Dienste durch private Vereinbarung oder auf andere Weise außerhalb des DNS-Protokolls bereitzustellen.

Der rekursive Modus tritt auf, wenn eine Abfrage mit gesetztem RD an einem Server ankommt, der bereit ist, rekursiven Dienst bereitzustellen; der Client kann verifizieren, dass der rekursive Modus verwendet wurde, indem er prüft, dass sowohl RA als auch RD in der Antwort gesetzt sind. Beachten Sie, dass der Nameserver niemals rekursiven Dienst ausführen sollte, es sei denn, er wird über RD angefordert, da dies die Fehlerbehebung von Nameservern und ihren Datenbanken beeinträchtigt.

Antworttypen (Response types)

Wenn rekursiver Dienst angefordert und verfügbar ist, wird die rekursive Antwort auf eine Abfrage eine der folgenden sein:

• Die Antwort auf die Abfrage, möglicherweise eingeleitet von einem oder mehreren CNAME-RRs, die Aliase angeben, die auf dem Weg zu einer Antwort angetroffen wurden.
• Ein Namensfehler, der anzeigt, dass der Name nicht existiert. Dies kann CNAME-RRs enthalten, die anzeigen, dass der ursprüngliche Abfragename ein Alias für einen Namen war, der nicht existiert.
• Eine temporäre Fehleranzeige.

Wenn rekursiver Dienst nicht angefordert oder nicht verfügbar ist, wird die nicht-rekursive Antwort eine der folgenden sein:

• Ein autoritativer Namensfehler, der anzeigt, dass der Name nicht existiert.
• Eine temporäre Fehleranzeige.
• Eine Kombination aus:
  • RRs, die die Frage beantworten, zusammen mit einer Angabe, ob die Daten aus einer Zone stammen oder gecacht sind.
  • Eine Verweisung auf Nameserver, die Zonen haben, die nähere Vorfahren des Namens sind als der Server, der die Antwort sendet.
  • RRs, von denen der Nameserver denkt, dass sie für den Anfragenden nützlich sein werden.

4.3.2. Algorithmus (Algorithm)

Der tatsächliche Algorithmus, der vom Nameserver verwendet wird, hängt vom lokalen Betriebssystem und den Datenstrukturen ab, die zum Speichern von RRs verwendet werden. Der folgende Algorithmus nimmt an, dass die RRs in mehreren Baumstrukturen organisiert sind, eine für jede Zone und eine weitere für den Cache:

1. Setzen oder löschen Sie den Wert von Rekursion verfügbar (Set or clear the value of recursion available) in der Antwort je nachdem, ob der Nameserver bereit ist, rekursiven Dienst bereitzustellen. Wenn rekursiver Dienst verfügbar und über das RD-Bit in der Abfrage angefordert ist, gehen Sie zu Schritt 5, sonst Schritt 2.

2. Durchsuchen Sie die verfügbaren Zonen (Search the available zones) nach der Zone, die der nächste Vorfahre von QNAME ist. Wenn eine solche Zone gefunden wird, gehen Sie zu Schritt 3, sonst Schritt 4.

3. Beginnen Sie mit der Abwärtsanpassung, Label für Label, in der Zone (Start matching down, label by label, in the zone). Der Anpassungsprozess kann auf mehrere Arten enden:

   a. Wenn das gesamte QNAME übereinstimmt (If the whole of QNAME is matched), haben wir den Knoten gefunden.

   Wenn die Daten am Knoten ein CNAME sind und QTYPE nicht mit CNAME übereinstimmt, kopieren Sie den CNAME-RR in den Antwortabschnitt der Antwort, ändern Sie QNAME auf den kanonischen Namen im CNAME-RR und gehen Sie zurück zu Schritt 1.

   Andernfalls kopieren Sie alle RRs, die mit QTYPE übereinstimmen, in den Antwortabschnitt und gehen Sie zu Schritt 6.

   b. Wenn eine Übereinstimmung uns aus den autoritativen Daten herausführen würde (If a match would take us out of the authoritative data), haben wir eine Verweisung. Dies geschieht, wenn wir auf einen Knoten mit NS-RRs stoßen, die Schnitte entlang des Bodens einer Zone markieren.

   Kopieren Sie die NS-RRs für die Subzone in den Autoritätsabschnitt der Antwort. Setzen Sie verfügbare Adressen in den zusätzlichen Abschnitt unter Verwendung von Kleber-RRs, wenn die Adressen nicht aus autoritativen Daten oder dem Cache verfügbar sind. Gehen Sie zu Schritt 4.

   c. Wenn bei einem Label eine Übereinstimmung unmöglich ist (If at some label, a match is impossible) (d.h. das entsprechende Label existiert nicht), prüfen Sie, ob das "*"-Label existiert.

   Wenn das "*"-Label nicht existiert, prüfen Sie, ob der Name, nach dem wir suchen, der ursprüngliche QNAME in der Abfrage ist oder ein Name, dem wir aufgrund eines CNAME gefolgt sind. Wenn der Name ursprünglich ist, setzen Sie einen autoritativen Namensfehler in der Antwort und beenden Sie. Andernfalls beenden Sie einfach.

   Wenn das ""-Label existiert, gleichen Sie RRs an diesem Knoten mit QTYPE ab. Wenn welche übereinstimmen, kopieren Sie sie in den Antwortabschnitt, setzen Sie aber den Eigentümer des RR auf QNAME und nicht auf den Knoten mit dem ""-Label. Gehen Sie zu Schritt 6.

4. Beginnen Sie mit der Abwärtsanpassung im Cache (Start matching down in the cache). Wenn QNAME im Cache gefunden wird, kopieren Sie alle daran angehängten RRs, die mit QTYPE übereinstimmen, in den Antwortabschnitt. Wenn es keine Delegierung aus autoritativen Daten gab, suchen Sie nach der besten aus dem Cache und setzen Sie sie in den Autoritätsabschnitt. Gehen Sie zu Schritt 6.

5. Verwenden Sie den lokalen Resolver (Using the local resolver) oder eine Kopie seines Algorithmus (siehe Resolver-Abschnitt dieses Memos), um die Abfrage zu beantworten. Speichern Sie die Ergebnisse, einschließlich etwaiger Zwischenstellen-CNAMEs, im Antwortabschnitt der Antwort.

6. Verwenden Sie nur lokale Daten (Using local data only), versuchen Sie, andere RRs hinzuzufügen, die für den zusätzlichen Abschnitt der Abfrage nützlich sein können. Beenden.

4.3.3. Wildcards

Im vorherigen Algorithmus wurde RRs mit Eigentümernamen, die mit dem Label "*" beginnen, eine besondere Behandlung zuteil. Solche RRs werden Wildcards genannt. Wildcard-RRs können als Anweisungen zur Synthese von RRs betrachtet werden. Wenn die entsprechenden Bedingungen erfüllt sind, erstellt der Nameserver RRs mit einem Eigentümernamen, der dem Abfragenamen entspricht, und Inhalten, die aus den Wildcard-RRs stammen.

Diese Einrichtung wird am häufigsten verwendet, um eine Zone zu erstellen, die zum Weiterleiten von E-Mails aus dem Internet an ein anderes E-Mail-System verwendet wird. Die allgemeine Idee ist, dass jeder Name in dieser Zone, der dem Server in einer Abfrage präsentiert wird, als existent angenommen wird, mit bestimmten Eigenschaften, es sei denn, es existieren explizite Beweise für das Gegenteil. Beachten Sie, dass die Verwendung des Begriffs Zone hier anstelle von Domäne absichtlich ist; solche Standards breiten sich nicht über Zonengrenzen hinaus aus, obwohl eine Subzone wählen kann, dieses Aussehen zu erreichen, indem sie ähnliche Standards einrichtet.

Wildcard-Syntax und -Semantik (Wildcard syntax and semantics)

Der Inhalt der Wildcard-RRs folgt den üblichen Regeln und Formaten für RRs. Die Wildcards in der Zone haben einen Eigentümernamen, der die Abfragenamen steuert, mit denen sie übereinstimmen. Der Eigentümername der Wildcard-RRs hat die Form *.<anydomain>, wobei <anydomain> ein beliebiger Domänenname ist. <anydomain> sollte keine anderen -Labels enthalten und sollte in den autoritativen Daten der Zone sein. Die Wildcards gelten potenziell für Nachkommen von <anydomain>, aber nicht für <anydomain> selbst. Eine andere Art, dies zu betrachten, ist, dass das ""-Label immer mindestens ein ganzes Label und manchmal mehr entspricht, aber immer ganzen Labels.

Wann Wildcards nicht gelten (When wildcards do not apply)

Wildcard-RRs gelten nicht:

• Wenn die Abfrage in einer anderen Zone ist (When the query is in another zone). Das heißt, Delegierung hebt die Wildcard-Standards auf.

• Wenn der Abfragename oder ein Name zwischen der Wildcard-Domäne und dem Abfragenamen bekanntermaßen existiert (When the query name or a name between the wildcard domain and the query name is known to exist). Zum Beispiel, wenn ein Wildcard-RR einen Eigentümernamen von "*.X" hat und die Zone auch RRs enthält, die an B.X angehängt sind, würden die Wildcards auf Abfragen für den Namen Z.X zutreffen (vorausgesetzt, es gibt keine expliziten Informationen für Z.X), aber nicht auf B.X, A.B.X oder X.

Ein *-Label, das in einem Abfragenamen erscheint, hat keinen speziellen Effekt, kann aber verwendet werden, um auf Wildcards in einer autoritativen Zone zu testen; eine solche Abfrage ist die einzige Möglichkeit, eine Antwort mit RRs mit einem Eigentümernamen mit * darin zu erhalten. Das Ergebnis einer solchen Abfrage sollte nicht gecacht werden.

Beachten Sie, dass der Inhalt der Wildcard-RRs nicht modifiziert wird, wenn sie zur Synthese von RRs verwendet werden.

Wildcard-Beispiel (Wildcard example)

Um die Verwendung von Wildcard-RRs zu veranschaulichen, nehmen wir an, ein großes Unternehmen mit einem großen Nicht-IP/TCP-Netzwerk wollte ein Mail-Gateway erstellen. Wenn das Unternehmen X.COM hieß und die IP/TCP-fähige Gateway-Maschine A.X.COM hieß, könnten die folgenden RRs in die COM-Zone eingetragen werden:

X.COM           MX      10      A.X.COM

*.X.COM         MX      10      A.X.COM

A.X.COM         A       1.2.3.4
A.X.COM         MX      10      A.X.COM

*.A.X.COM       MX      10      A.X.COM

Dies würde bewirken, dass jede MX-Abfrage für jeden Domänennamen, der auf X.COM endet, einen MX-RR zurückgibt, der auf A.X.COM zeigt. Zwei Wildcard-RRs sind erforderlich, da die Wirkung des Wildcards bei *.X.COM im A.X.COM-Teilbaum durch die expliziten Daten für A.X.COM gehemmt wird. Beachten Sie auch, dass die expliziten MX-Daten bei X.COM und A.X.COM erforderlich sind und dass keiner der obigen RRs mit einem Abfragenamen von XX.COM übereinstimmen würde.

4.3.4. Negatives Antwort-Caching (Negative response caching) (Optional)

Das DNS bietet einen optionalen Dienst, der es Nameservern ermöglicht, negative Ergebnisse mit TTLs zu verteilen, und Resolvern, diese zu cachen. Zum Beispiel kann ein Nameserver einen TTL zusammen mit einer Namensfehleranzeige verteilen, und ein Resolver, der solche Informationen erhält, darf annehmen, dass der Name während der TTL-Periode nicht existiert, ohne autoritative Daten zu konsultieren. Ähnlich kann ein Resolver eine Abfrage mit einem QTYPE erstellen, der mehreren Typen entspricht, und die Tatsache cachen, dass einige der Typen nicht vorhanden sind.

Diese Funktion kann besonders wichtig in einem System sein, das Namensabkürzungen implementiert, die Suchlisten verwenden, da eine beliebte Abkürzung, die zufällig ein Suffix gegen Ende der Suchliste erfordert, mehrere Namensfehler generiert, wann immer sie verwendet wird.

Implementierungsmethode (Implementation method)

Die Methode besteht darin, dass ein Nameserver einen SOA-RR zum zusätzlichen Abschnitt einer Antwort hinzufügen kann, wenn diese Antwort autoritativ ist. Das SOA muss das der Zone sein, die die Quelle der autoritativen Daten im Antwortabschnitt war, oder Namensfehler, falls zutreffend. Das MINIMUM-Feld des SOA steuert die Zeitdauer, für die das negative Ergebnis gecacht werden kann.

Beachten Sie, dass unter bestimmten Umständen der Antwortabschnitt mehrere Eigentümernamen enthalten kann. In diesem Fall sollte der SOA-Mechanismus nur für die Daten verwendet werden, die mit QNAME übereinstimmen, was die einzigen autoritativen Daten in diesem Abschnitt sind.

Nameserver und Resolver sollten niemals versuchen, SOAs zum zusätzlichen Abschnitt einer nicht-autoritativen Antwort hinzuzufügen oder Ergebnisse zu folgern, die nicht direkt in einer autoritativen Antwort angegeben sind. Es gibt mehrere Gründe dafür, einschließlich: gecachte Informationen reichen normalerweise nicht aus, um RRs und ihre Zonennamen abzugleichen, SOA-RRs können aufgrund direkter SOA-Abfragen gecacht werden, und Nameserver sind nicht verpflichtet, die SOAs im Autoritätsabschnitt auszugeben.

Diese Funktion ist optional, obwohl erwartet wird, dass eine verfeinerte Version in Zukunft Teil des Standardprotokolls wird. Nameserver sind nicht verpflichtet, die SOA-RRs in allen autoritativen Antworten hinzuzufügen, noch sind Resolver verpflichtet, negative Ergebnisse zu cachen. Beides wird empfohlen. Alle Resolver und rekursiven Nameserver müssen mindestens in der Lage sein, den SOA-RR zu ignorieren, wenn er in einer Antwort vorhanden ist.

Einige Experimente wurden auch vorgeschlagen, die diese Funktion verwenden werden. Die Idee ist, dass, wenn bekannt ist, dass gecachte Daten aus einer bestimmten Zone stammen, und wenn eine autoritative Kopie des SOA der Zone erhalten wird, und wenn sich das SERIAL der Zone nicht geändert hat, seit die Daten gecacht wurden, dann der TTL der gecachten Daten auf den MINIMUM-Wert der Zone zurückgesetzt werden kann, wenn er kleiner ist. Diese Verwendung wird nur zu Planungszwecken erwähnt und wird noch nicht empfohlen.

4.3.5. Zonenwartung und -übertragungen (Zone maintenance and transfers)

Ein Teil der Arbeit eines Zonenadministrators besteht darin, die Zonen auf allen Nameservern zu warten, die für die Zone autoritativ sind. Wenn die unvermeidlichen Änderungen vorgenommen werden, müssen sie an alle Nameserver verteilt werden. Während diese Verteilung mit FTP oder einem anderen Ad-hoc-Verfahren erreicht werden kann, ist die bevorzugte Methode der Zonenübertragungsteil des DNS-Protokolls.

Zonenübertragungsmodell (Zone transfer model)

Das allgemeine Modell der automatischen Zonenübertragung oder -aktualisierung ist, dass einer der Nameserver der Master oder Primärserver für die Zone ist. Änderungen werden am Primärserver koordiniert, typischerweise durch Bearbeiten einer Masterdatei für die Zone. Nach der Bearbeitung signalisiert der Administrator dem Masterserver, die neue Zone zu laden. Die anderen Nicht-Master- oder Sekundärserver für die Zone prüfen periodisch auf Änderungen (in einem auswählbaren Intervall) und erhalten neue Zonenkopien, wenn Änderungen vorgenommen wurden.

Änderungserkennung über SERIAL (Change detection via SERIAL)

Um Änderungen zu erkennen, prüfen Sekundärserver einfach das SERIAL-Feld des SOA für die Zone. Zusätzlich zu allen anderen vorgenommenen Änderungen wird das SERIAL-Feld im SOA der Zone immer vorgerückt, wann immer eine Änderung an der Zone vorgenommen wird. Das Vorrücken kann ein einfaches Inkrement sein oder könnte auf dem Schreibdatum und der Zeit der Masterdatei usw. basieren. Der Zweck besteht darin, es möglich zu machen, zu bestimmen, welche von zwei Kopien einer Zone neuer ist, indem Seriennummern verglichen werden. Seriennummernvorrückungen und -vergleiche verwenden Sequenzraumarithmetik, es gibt also eine theoretische Grenze dafür, wie schnell eine Zone aktualisiert werden kann, im Grunde müssen alte Kopien aussterben, bevor die Seriennummer die Hälfte ihres 32-Bit-Bereichs abdeckt. In der Praxis ist die einzige Sorge, dass die Vergleichsoperation Vergleiche um die Grenze zwischen den positivsten und negativsten 32-Bit-Zahlen herum richtig behandelt.

SOA-Parameter für Zonenübertragung (SOA parameters for zone transfer)

Das periodische Abfragen der Sekundärserver wird durch Parameter im SOA-RR für die Zone gesteuert, die die minimal akzeptablen Abfrageintervalle festlegen. Die Parameter heißen REFRESH, RETRY und EXPIRE. Wann immer eine neue Zone in einem Sekundärserver geladen wird, wartet der Sekundärserver REFRESH Sekunden, bevor er beim Primärserver nach einer neuen Seriennummer prüft. Wenn diese Prüfung nicht abgeschlossen werden kann, werden neue Prüfungen alle RETRY Sekunden gestartet. Die Prüfung ist eine einfache Abfrage an den Primärserver nach dem SOA-RR der Zone. Wenn das Serienfeld in der Zonenkopie des Sekundärservers gleich der vom Primärserver zurückgegebenen Seriennummer ist, dann sind keine Änderungen aufgetreten, und das REFRESH-Intervall wartet neu gestartet. Wenn der Sekundärserver findet, dass es unmöglich ist, eine Serienprüfung für das EXPIRE-Intervall durchzuführen, muss er annehmen, dass seine Kopie der Zone veraltet ist, und sie verwerfen.

AXFR-Zonenübertragung (AXFR zone transfer)

Wenn die Abfrage zeigt, dass sich die Zone geändert hat, dann muss der Sekundärserver eine Zonenübertragung über eine AXFR-Anfrage für die Zone anfordern. Das AXFR kann einen Fehler verursachen, wie abgelehnt, wird aber normalerweise durch eine Sequenz von Antwortnachrichten beantwortet. Die ersten und letzten Nachrichten müssen die Daten für den obersten autoritativen Knoten der Zone enthalten. Zwischennachrichten tragen alle anderen RRs aus der Zone, einschließlich sowohl autoritativer als auch nicht-autoritativer RRs. Der Nachrichtenstrom ermöglicht es dem Sekundärserver, eine Kopie der Zone zu konstruieren. Da Genauigkeit wesentlich ist, muss TCP oder ein anderes zuverlässiges Protokoll für AXFR-Anfragen verwendet werden.

Jeder Sekundärserver muss die folgenden Operationen gegen den Master ausführen, kann diese Operationen aber auch optional gegen andere Sekundärserver ausführen. Diese Strategie kann den Übertragungsprozess verbessern, wenn der Primärserver aufgrund von Host-Ausfallzeiten oder Netzwerkproblemen nicht verfügbar ist, oder wenn ein Sekundärserver besseren Netzwerkzugriff auf einen "Zwischen"-Sekundärserver als auf den Primärserver hat.

---