Zum Hauptinhalt springen

6. Name Server Implementation (Name-Server-Implementierung)

Dieses Kapitel behandelt Implementierungsüberlegungen für DNS-Nameserver.

6.1. Architecture (Architektur)​

Die optimale Struktur für den Nameserver hängt vom Host-Betriebssystem ab und davon, ob der Nameserver mit Resolver-Operationen integriert ist, entweder durch Unterstützung rekursiver Dienste oder durch Teilen seiner Datenbank mit einem Resolver.

Dieser Abschnitt behandelt Implementierungsüberlegungen für einen Nameserver, der eine Datenbank mit einem Resolver teilt, aber die meisten dieser Bedenken sind in jedem Nameserver vorhanden.

6.1.1. Control (Steuerung)​

Ein Nameserver muss (MUST) mehrere gleichzeitige Aktivitäten einsetzen, unabhängig davon, ob sie als separate Aufgaben im Betriebssystem des Hosts implementiert sind oder innerhalb eines einzelnen Nameserverprogramms gemultiplext werden.

Anforderungen:

  • UDP nicht-blockierend: Es ist einfach inakzeptabel, dass ein Nameserver den Dienst von UDP-Anfragen blockiert, während er auf TCP-Daten für Aktualisierungs- oder Abfrageaktivitäten wartet

  • Parallele Verarbeitung: Ein Nameserver sollte (SHOULD NOT) nicht versuchen, rekursiven Dienst bereitzustellen, ohne solche Anfragen parallel zu verarbeiten, obwohl er wählen kann:

    • Anfragen von einem einzelnen Client zu serialisieren
    • Identische Anfragen vom selben Client als Duplikate zu betrachten

  • Nicht-blockierende Zonenoperationen: Ein Nameserver sollte (SHOULD NOT) Anfragen nicht wesentlich verzögern, während er:

    • Eine Zone aus Masterdateien neu lädt
    • Eine neu aktualisierte Zone in seine Datenbank einbindet

6.1.2. Database (Datenbank)​

Während Nameserver-Implementierungen frei sind, beliebige interne Datenstrukturen zu verwenden, besteht die vorgeschlagene Struktur aus drei Hauptteilen:

Vorgeschlagene Datenbankstruktur​

1. Katalog-Datenstruktur (Catalog Data Structure):

  • Listet die für diesen Server verfügbaren Zonen auf
  • Enthält einen "Zeiger" auf die Zonendatenstruktur
  • Hauptzweck: die nächste Vorgängerzone, falls vorhanden, für eingehende Standardabfragen zu finden

2. Zonendatenstrukturen (Zone Data Structures):

  • Separate Datenstrukturen für jede der vom Nameserver gehaltenen Zonen
  • Enthält autoritative Daten für die Zone

3. Cache-Datenstruktur (Cache Data Structure):

  • Eine Datenstruktur für zwischengespeicherte Daten
  • Kann separate Caches für verschiedene Klassen haben

Implementierungsüberlegungen​

Baumstruktur: Alle diese Datenstrukturen können in einem identischen Baumstrukturformat implementiert werden, wobei verschiedene Daten an den Knoten in verschiedenen Teilen verkettet sind:

  • Im Katalog: Daten sind Zeiger auf Zonen
  • In Zonen- und Cache-Datenstrukturen: Daten werden RRs sein

Anforderungen an die Abfrageverarbeitung: Beim Entwurf des Baumrahmenwerks sollte der Designer erkennen, dass:

  • Die Abfrageverarbeitung den Baum mit groß-/kleinschreibungsunabhängigen Label-Vergleichen durchlaufen muss
  • In echten Daten haben einige Knoten einen sehr hohen Verzweigungsfaktor (100-1000 oder mehr)
  • Die überwiegende Mehrheit hat einen sehr niedrigen Verzweigungsfaktor (0-1)

Groß-/kleinschreibungsunabhängige Speicherlösung​

Eine Möglichkeit, das Groß-/Kleinschreibungsproblem zu lösen, besteht darin, die Labels für jeden Knoten in zwei Teilen zu speichern:

  1. Eine standardisierte Groß-/Kleinschreibungsdarstellung des Labels, bei der alle ASCII-Zeichen in einer einzigen Groß-/Kleinschreibung sind
  2. Eine Bitmaske, die angibt, welche Zeichen tatsächlich eine andere Groß-/Kleinschreibung haben

Optimierung des Verzweigungsfaktors​

Die Vielfalt der Verzweigungsfaktoren kann behandelt werden durch:

  • Verwendung einer einfachen verketteten Liste für einen Knoten, bis der Verzweigungsfaktor einen bestimmten Schwellenwert überschreitet
  • Übergang zu einer Hash-Struktur nach Überschreitung des Schwellenwerts

Wichtig: Hash-Strukturen, die zum Speichern von Baumabschnitten verwendet werden, müssen sicherstellen, dass Hash-Funktionen und -Verfahren die Groß-/Kleinschreibungskonventionen des DNS bewahren.

Vorteile separater Strukturen​

Die Verwendung separater Strukturen für die verschiedenen Teile der Datenbank ist durch mehrere Faktoren motiviert:

1. Katalogstabilität:

  • Die Katalogstruktur kann eine nahezu statische Struktur sein
  • Muss sich nur ändern, wenn der Systemadministrator die vom Server unterstützten Zonen ändert
  • Kann auch Parameter speichern, die zur Steuerung von Aktualisierungsaktivitäten verwendet werden

2. Atomarer Zonenaustausch:

  • Einzelne Datenstrukturen für Zonen ermöglichen es, eine Zone einfach durch Ändern eines Zeigers im Katalog zu ersetzen
  • Zonenaktualisierungsoperationen können eine neue Struktur aufbauen und sie nach Abschluss über einen einfachen Zeigeraustausch in die Datenbank einfügen
  • Kritisch: Wenn eine Zone aktualisiert wird, sollten (SHOULD NOT) Abfragen nicht gleichzeitig alte und neue Daten verwenden

3. Datenpriorität:

  • Mit den richtigen Suchverfahren werden autoritative Daten in Zonen immer zwischengespeicherte Daten "verstecken" und daher Vorrang haben

4. Fehlerisolierung:

  • Fehler in Zonendefinitionen, die überlappende Zonen verursachen, können fehlerhafte Antworten auf Abfragen verursachen
  • Die Problembestimmung ist vereinfacht
  • Der Inhalt einer "schlechten" Zone kann keine andere beschädigen

5. Cache-Verwaltung:

  • Da der Cache am häufigsten aktualisiert wird, ist er am anfälligsten für Beschädigung während Systemneustarts
  • Er kann auch voll von abgelaufenen RR-Daten werden
  • In beiden Fällen kann er leicht verworfen werden, ohne Zonendaten zu stören

Wiederherstellung nach Absturz​

Ein wichtiger Aspekt des Datenbankentwurfs ist die Auswahl einer Struktur, die es dem Nameserver ermöglicht, mit Abstürzen des Nameserver-Hosts umzugehen.

Statusinformationen, die ein Nameserver über Systemabstürze hinweg speichern sollte (SHOULD):

  • Die Katalogstruktur (einschließlich des Aktualisierungsstatus für jede Zone)
  • Die Zonendaten selbst

6.1.3. Time (Zeit)​

Sowohl die TTL-Daten für RRs als auch die Zeitdaten für Aktualisierungsaktivitäten hängen von 32-Bit-Timern in Sekundeneinheiten ab.

Zeitdarstellung​

Konzeptionelles Modell:

  • Innerhalb der Datenbank "zählen" Aktualisierungstimer und TTLs für zwischengespeicherte Daten konzeptionell "herunter"
  • Daten in der Zone bleiben mit konstanten TTLs

Empfohlene Implementierungsstrategie:

Zeit auf zwei Arten speichern: als relativer Inkrement und als absolute Zeit.

Eine Möglichkeit, dies zu tun, ist die Verwendung von:

  • Positiven 32-Bit-Zahlen für einen Typ
  • Negativen Zahlen für den anderen

Verwendung:

  • RRs in Zonen verwenden relative Zeiten
  • Aktualisierungstimer und Cache-Daten verwenden absolute Zeiten
  • Absolute Zahlen werden in Bezug auf einen bekannten Ursprung genommen und in relative Werte umgewandelt, wenn sie in die Antwort auf eine Abfrage eingefügt werden
  • Wenn ein absoluter TTL nach der Umwandlung in relativ negativ ist, dann sind die Daten abgelaufen und sollten ignoriert werden

6.2. Standard Query Processing (Standard-Abfrageverarbeitung)​

Der Hauptalgorithmus für die Standard-Abfrageverarbeitung wird in RFC-1034 dargestellt.

Sonderfälle und Regeln​

QCLASS=* Verarbeitung:

  • Beim Verarbeiten von Abfragen mit QCLASS=* oder einer anderen QCLASS, die mehrere Klassen übereinstimmt
  • Die Antwort sollte (SHOULD NOT) niemals autoritativ sein, es sei denn, der Server kann garantieren, dass die Antwort alle Klassen abdeckt

Umgang mit doppelten RRs:

  • Beim Zusammenstellen einer Antwort können RRs, die in den zusätzlichen Abschnitt eingefügt werden sollen, aber RRs in den Antwort- oder Autoritätsabschnitten duplizieren, aus dem zusätzlichen Abschnitt weggelassen werden

Abschneidungspolitik:

  • Wenn eine Antwort so lang ist, dass Abschneidung erforderlich ist
  • Die Abschneidung sollte (SHOULD) am Ende der Antwort beginnen und im Datagramm vorwärts arbeiten
  • Wenn es also Daten für den Autoritätsabschnitt gibt, ist garantiert, dass der Antwortabschnitt eindeutig ist

SOA MINIMUM Feld:

  • Der MINIMUM-Wert im SOA sollte (SHOULD) verwendet werden, um eine Untergrenze für den TTL von Daten festzulegen, die aus einer Zone verteilt werden
  • Diese Untergrenzfunktion sollte (SHOULD) durchgeführt werden, wenn die Daten in eine Antwort kopiert werden
  • Dies ermöglicht es zukünftigen dynamischen Update-Protokollen, das SOA MINIMUM-Feld ohne mehrdeutige Semantik zu ändern

6.3. Zone Refresh and Reload Processing (Zonenaktualisierung und Neuladenverarbeitung)​

Fehlerbehandlung​

Trotz der besten Bemühungen eines Servers kann er möglicherweise nicht:

  • Zonendaten aus einer Masterdatei aufgrund von Syntaxfehlern usw. laden
  • Eine Zone innerhalb ihres Ablaufparameters aktualisieren

In diesem Fall: Der Nameserver sollte (SHOULD) auf Abfragen antworten, als ob er die Zone nicht besitzen soll.

Konsistenz des Zonentransfers​

Wenn ein Master eine Zone über AXFR sendet und eine neue Version während des Transfers erstellt wird:

  • Der Master sollte (SHOULD) die alte Version weiter senden, wenn möglich
  • Auf jeden Fall sollte (MUST NOT) er niemals einen Teil einer Version und einen Teil einer anderen senden
  • Wenn der Abschluss nicht möglich ist, sollte (SHOULD) der Master die Verbindung zurücksetzen, auf der der Zonentransfer stattfindet

6.4. Inverse Queries (Inverse Abfragen) (Optional)​

Inverse Abfragen sind ein optionaler Teil des DNS.

Unterstützungsanforderungen​

  • Nameserver sind nicht erforderlich (NOT REQUIRED), irgendeine Form inverser Abfragen zu unterstützen
  • Wenn ein Nameserver eine inverse Abfrage empfängt, die er nicht unterstützt, gibt er eine Fehlerantwort mit dem "Not Implemented"-Fehler im Header zurück
  • Obwohl die Unterstützung inverser Abfragen optional ist, müssen (MUST) alle Nameserver zumindest in der Lage sein, die Fehlerantwort zurückzugeben

6.4.1. The Contents of Inverse Queries and Responses (Inhalt inverser Abfragen und Antworten)​

Inverse Abfragen kehren die von Standard-Abfrageoperationen durchgeführten Zuordnungen um:

  • Während eine Standardabfrage einen Domänennamen einer Ressource zuordnet
  • Ordnet eine inverse Abfrage eine Ressource einem Domänennamen zu

Beispiel:

  • Eine Standardabfrage kann einen Domänennamen an eine Hostadresse binden
  • Die entsprechende inverse Abfrage bindet die Hostadresse an einen Domänennamen

Format​

Inverse Abfragen nehmen die Form an:

  • Ein einzelner RR im Antwortabschnitt der Nachricht
  • Ein leerer Frageabschnitt
  • Der Eigentümername des Abfrage-RR und seine TTL sind nicht signifikant

Antwort​

Die Antwort trägt Fragen im Frageabschnitt, die alle Namen identifizieren, die den Abfrage-RR besitzen, DIE DER NAMESERVER KENNT.

Wichtige Einschränkungen:

  • Da kein Nameserver den gesamten Domänennamenraum kennt, kann die Antwort niemals als vollständig angenommen werden
  • Daher sind inverse Abfragen hauptsächlich für Datenbankverwaltungs- und Debugging-Aktivitäten nützlich
  • Inverse Abfragen sind KEINE akzeptable Methode zum Zuordnen von Hostadressen zu Hostnamen; verwenden Sie stattdessen die IN-ADDR.ARPA-Domäne

Groß-/kleinschreibungsunabhängige Vergleiche​

Wo möglich, sollten (SHOULD) Nameserver groß-/kleinschreibungsunabhängige Vergleiche für inverse Abfragen bereitstellen:

  • Eine inverse Abfrage nach einem MX RR von Venera.isi.edu sollte (SHOULD) die gleiche Antwort erhalten wie eine Abfrage nach VENERA.ISI.EDU
  • Eine inverse Abfrage nach HINFO RR IBM-PC UNIX sollte (SHOULD) das gleiche Ergebnis liefern wie eine inverse Abfrage nach IBM-pc unix

Hinweis: Dies kann nicht garantiert werden, da Nameserver RRs besitzen können, die Zeichenketten enthalten, aber der Nameserver nicht weiß, dass die Daten Zeichen sind.

Verarbeitung der Ergebnisse​

Wenn ein Nameserver eine inverse Abfrage verarbeitet, gibt er entweder zurück:

  1. Null, einen oder mehrere Domänennamen für die angegebene Ressource als QNAMEs im Frageabschnitt
  2. Einen Fehlercode, der angibt, dass der Nameserver die inverse Zuordnung des angegebenen Ressourcentyps nicht unterstützt

Antwortänderung​

Wenn die Antwort auf eine inverse Abfrage einen oder mehrere QNAMEs enthält:

  • Der Eigentümername und die TTL des RR im Antwortabschnitt, der die inverse Abfrage definiert, werden geändert, um genau mit einem RR übereinzustimmen, das am ersten QNAME gefunden wurde

Cache-Einschränkungen​

RRs, die in inversen Abfragen zurückgegeben werden, können nicht (CANNOT) mit demselben Mechanismus wie für Antworten auf Standardabfragen zwischengespeichert werden.

Grund: Ein Name kann mehrere RRs desselben Typs haben, und nur einer würde erscheinen. Zum Beispiel könnte eine inverse Abfrage nach einer einzelnen Adresse eines Hosts mit mehreren Adressen den Eindruck erwecken, dass nur eine Adresse existiert.

6.4.2. Inverse Query and Response Example (Beispiel für inverse Abfrage und Antwort)​

Die Gesamtstruktur einer inversen Abfrage zum Abrufen des Domänennamens, der der Internetadresse 10.1.0.52 entspricht:

Abfrage:

+-----------------------------------------+
|  Header   | OPCODE=IQUERY, ID=997       |
+-----------------------------------------+
| Question  | <empty>                     |
+-----------------------------------------+
|  Answer   | <anyname> A IN 10.1.0.52    |
+-----------------------------------------+
| Authority | <empty>                     |
+-----------------------------------------+
|Additional | <empty>                     |
+-----------------------------------------+

Erklärung:

  • Diese Abfrage fordert eine Frage an, deren Antwort die Internetadresse im Stil 10.1.0.52 ist
  • Da der Eigentümername nicht bekannt ist, kann jeder Domänenname als Platzhalter verwendet werden (und wird ignoriert)
  • Ein einzelnes Null-Oktett, das die Root bedeutet, wird üblicherweise verwendet, da es die Länge der Nachricht minimiert
  • Die TTL des RR ist nicht signifikant

Antwort:

+-----------------------------------------+
|  Header   | OPCODE=RESPONSE, ID=997     |
+-----------------------------------------+
| Question  | QTYPE=A, QCLASS=IN,         |
|           | QNAME=VENERA.ISI.EDU        |
+-----------------------------------------+
|  Answer   | VENERA.ISI.EDU A IN         |
|           | 10.1.0.52                   |
+-----------------------------------------+
| Authority | <empty>                     |
+-----------------------------------------+
|Additional | <empty>                     |
+-----------------------------------------+

Hinweis: Der QTYPE in einer Antwort auf eine inverse Abfrage ist derselbe wie das TYPE-Feld im Antwortabschnitt der inversen Abfrage. Antworten auf inverse Abfragen können mehrere Fragen enthalten, wenn das Inverse nicht eindeutig ist. Wenn der Frageabschnitt in der Antwort nicht leer ist, wird der RR im Antwortabschnitt geändert, um eine exakte Kopie eines RR am ersten QNAME zu sein.

6.4.3. Inverse Query Processing (Verarbeitung inverser Abfragen)​

Nameserver, die inverse Abfragen unterstützen, können diese Operationen durch erschöpfende Durchsuchungen ihrer Datenbanken unterstützen, aber dies wird unpraktisch, wenn die Größe der Datenbank zunimmt.

Alternativer Ansatz: Die Datenbank nach dem Suchschlüssel invertieren.

Empfehlung für große Server​

Für Nameserver, die mehrere Zonen und eine große Datenmenge unterstützen, ist der empfohlene Ansatz:

  • Separate Invertierungen für jede Zone
  • Wenn eine bestimmte Zone während einer Aktualisierung geändert wird, müssen nur ihre Invertierungen neu gemacht werden

Hinweis: Unterstützung für die Übertragung dieser Art von Invertierung kann in zukünftigen Versionen des Domänensystems enthalten sein, wird aber in dieser Version nicht unterstützt.

6.5. Completion Queries and Responses (Vervollständigungsabfragen und -antworten)​

Die in RFC-882 und RFC-883 beschriebenen optionalen Vervollständigungsdienste wurden gelöscht.

Neugestaltete Dienste können in Zukunft verfügbar werden.

Weiter: 7. Resolver Implementation (Resolver-Implementierung)

Letztes Update am