Zum Hauptinhalt springen

3. DOMÄNENNAMEN-RAUM und RESSOURCENEINTRÄGE (DOMAIN NAME SPACE and RESOURCE RECORDS)

3.1. Namensraum-Spezifikationen und Terminologie (Name space specifications and terminology)​

Der Domänennamen-Raum ist eine Baumstruktur. Jeder Knoten und jedes Blatt im Baum entspricht einer Ressourcenmenge (die leer sein kann). Das Domänensystem unterscheidet nicht zwischen der Verwendung von inneren Knoten und Blättern, und dieses Memo verwendet den Begriff "Knoten (node)" für beide.

Jeder Knoten hat ein Label, das 0 bis 63 Oktette lang ist. Geschwisterknoten dürfen nicht dasselbe Label haben, obwohl dasselbe Label für Knoten verwendet werden kann, die keine Geschwister sind. Ein Label ist reserviert, und das ist das Null-Label (d.h. Länge Null), das für die Wurzel verwendet wird.

Der Domänenname eines Knotens ist die Liste der Labels auf dem Pfad vom Knoten zur Wurzel des Baumes. Konventionsgemäß werden die Labels, die einen Domänennamen bilden, von links nach rechts gedruckt oder gelesen, vom spezifischsten (niedrigsten, am weitesten von der Wurzel entfernt) zum am wenigsten spezifischen (höchsten, am nächsten zur Wurzel).

Interne Darstellung (Internal representation)​

Intern sollten Programme, die Domänennamen manipulieren, diese als Sequenzen von Labels darstellen, wobei jedes Label ein Längenoktett ist, gefolgt von einer Oktettzeichenkette. Da alle Domänennamen an der Wurzel enden, die eine Nullzeichenkette als Label hat, können diese internen Darstellungen ein Längenbyte von Null verwenden, um einen Domänennamen zu beenden.

Groß-/Kleinschreibung (Case sensitivity)​

Konventionsgemäß können Domänennamen mit beliebiger Groß-/Kleinschreibung gespeichert werden, aber Domänennamenvergleiche für alle gegenwärtigen Domänenfunktionen werden auf eine Weise durchgeführt, die die Groß-/Kleinschreibung nicht berücksichtigt, unter der Annahme eines ASCII-Zeichensatzes und eines höherwertigen Nullbits. Dies bedeutet, dass Sie frei sind, einen Knoten mit dem Label "A" oder einen Knoten mit dem Label "a" zu erstellen, aber nicht beide als Geschwister; Sie könnten sich auf beide mit "a" oder "A" beziehen. Wenn Sie einen Domänennamen oder ein Label erhalten, sollten Sie dessen Groß-/Kleinschreibung beibehalten. Die Begründung für diese Wahl ist, dass wir eines Tages möglicherweise vollständige binäre Domänennamen für neue Dienste hinzufügen müssen; bestehende Dienste würden nicht geändert.

Absolute und relative Namen (Absolute and relative names)​

Wenn ein Benutzer einen Domänennamen eingeben muss, wird die Länge jedes Labels weggelassen und die Labels werden durch Punkte (".") getrennt. Da ein vollständiger Domänenname mit dem Wurzellabel endet, führt dies zu einer gedruckten Form, die mit einem Punkt endet. Wir verwenden diese Eigenschaft, um zwischen Folgendem zu unterscheiden:

  • Absolute Namen (Absolute names): Eine Zeichenkette, die einen vollständigen Domänennamen darstellt (oft "absolut" genannt). Zum Beispiel "poneria.ISI.EDU."

  • Relative Namen (Relative names): Eine Zeichenkette, die die Anfangslabels eines Domänennamens darstellt, der unvollständig ist und von lokaler Software unter Verwendung der Kenntnis der lokalen Domäne vervollständigt werden sollte (oft "relativ" genannt). Zum Beispiel "poneria", verwendet in der ISI.EDU-Domäne.

Relative Namen werden entweder relativ zu einem bekannten Ursprung oder zu einer Liste von Domänen genommen, die als Suchliste verwendet wird. Relative Namen erscheinen hauptsächlich an der Benutzerschnittstelle, wo ihre Interpretation von Implementierung zu Implementierung variiert, und in Masterdateien, wo sie relativ zu einem einzelnen Ursprungs-Domänennamen sind. Die häufigste Interpretation verwendet die Wurzel "." entweder als einzelnen Ursprung oder als eines der Mitglieder der Suchliste, sodass ein relativer Name mit mehreren Labels oft einer ist, bei dem der nachgestellte Punkt weggelassen wurde, um Tipparbeit zu sparen.

Längenbeschränkungen (Length limitations)​

Um Implementierungen zu vereinfachen, ist die Gesamtzahl der Oktette, die einen Domänennamen darstellen (d.h. die Summe aller Label-Oktette und Labellängen), auf 255 begrenzt.

Domänen- und Subdomänenbeziehungen (Domain and subdomain relationships)​

Eine Domäne wird durch einen Domänennamen identifiziert und besteht aus dem Teil des Domänennamen-Raums, der auf oder unter dem Domänennamen liegt, der die Domäne spezifiziert. Eine Domäne ist eine Subdomäne einer anderen Domäne, wenn sie in dieser Domäne enthalten ist. Diese Beziehung kann getestet werden, indem man prüft, ob der Name der Subdomäne mit dem Namen der enthaltenden Domäne endet. Zum Beispiel ist A.B.C.D eine Subdomäne von B.C.D, C.D, D und " ".

3.2. Administrative Richtlinien zur Verwendung (Administrative guidelines on use)​

Als Frage der Politik schreiben die technischen DNS-Spezifikationen keine bestimmte Baumstruktur oder Regeln für die Auswahl von Labels vor; ihr Ziel ist es, so allgemein wie möglich zu sein, damit es zum Aufbau beliebiger Anwendungen verwendet werden kann. Insbesondere wurde das System so konzipiert, dass der Namensraum nicht entlang der Linien von Netzwerkgrenzen, Nameservern usw. organisiert werden muss. Die Begründung dafür ist nicht, dass der Namensraum keine implizite Semantik haben sollte, sondern vielmehr, dass die Wahl der impliziten Semantik offen gelassen werden sollte, um für das vorliegende Problem verwendet zu werden, und dass verschiedene Teile des Baumes unterschiedliche implizite Semantik haben können. Zum Beispiel ist die IN-ADDR.ARPA-Domäne nach Netzwerk und Host-Adresse organisiert und verteilt, da ihre Rolle darin besteht, von Netzwerk- oder Hostnummern zu Namen zu übersetzen; NetBIOS-Domänen [RFC-1001, RFC-1002] sind flach, weil dies für diese Anwendung angemessen ist.

Es gibt jedoch einige Richtlinien, die für die "normalen" Teile des Namensraums gelten, die für Hosts, Mailboxen usw. verwendet werden, die den Namensraum einheitlicher machen, Wachstum ermöglichen und Probleme minimieren, wenn Software von der älteren Hosttabelle konvertiert wird. Die politischen Entscheidungen über die obersten Ebenen des Baumes stammen aus RFC-920. Die aktuelle Politik für die obersten Ebenen wird in [RFC-1032] diskutiert. MILNET-Konvertierungsprobleme werden in [RFC-1031] behandelt.

Untere Domänen, die schließlich in mehrere Zonen aufgeteilt werden, sollten an der Spitze der Domäne Verzweigungen bieten, damit die eventuelle Zerlegung ohne Umbenennung durchgeführt werden kann. Knotenlabels, die Sonderzeichen, führende Ziffern usw. verwenden, werden wahrscheinlich ältere Software brechen, die von restriktiveren Auswahlmöglichkeiten abhängt.

3.3. Technische Richtlinien zur Verwendung (Technical guidelines on use)​

Bevor das DNS verwendet werden kann, um Namensgebungsinformationen für eine Art von Objekt zu halten, müssen zwei Bedürfnisse erfüllt werden:

  • Eine Konvention für die Zuordnung zwischen Objektnamen und Domänennamen. Dies beschreibt, wie auf Informationen über ein Objekt zugegriffen wird.

  • RR-Typen und Datenformate zur Beschreibung des Objekts.

Diese Regeln können recht einfach oder ziemlich komplex sein. Sehr oft muss der Designer bestehende Formate berücksichtigen und die Aufwärtskompatibilität für bestehende Nutzung planen. Mehrere Zuordnungen oder Zuordnungsebenen können erforderlich sein.

Hostnamen-Zuordnung (Host name mapping)​

Für Hosts hängt die Zuordnung von der bestehenden Syntax für Hostnamen ab, die eine Teilmenge der üblichen Textdarstellung für Domänennamen ist, zusammen mit RR-Formaten zur Beschreibung von Host-Adressen usw. Da wir eine zuverlässige umgekehrte Zuordnung von Adresse zu Hostname benötigen, ist auch eine spezielle Zuordnung für Adressen in die IN-ADDR.ARPA-Domäne definiert.

Mailbox-Zuordnung (Mailbox mapping)​

Für Mailboxen ist die Zuordnung etwas komplexer. Die übliche Mail-Adresse <local-part>@<mail-domain> wird in einen Domänennamen umgewandelt, indem <local-part> in ein einzelnes Label konvertiert wird (unabhängig von den darin enthaltenen Punkten), <mail-domain> unter Verwendung des üblichen Textformats für Domänennamen in einen Domänennamen konvertiert wird (Punkte kennzeichnen Labelgrenzen) und die beiden verkettet werden, um einen einzelnen Domänennamen zu bilden. Somit wird die Mailbox [email protected] als Domänenname durch HOSTMASTER.SRI-NIC.ARPA dargestellt. Eine Würdigung der Gründe hinter diesem Design muss auch das Schema für Mail-Austausch [RFC-974] berücksichtigen.

Der typische Benutzer ist nicht mit der Definition dieser Regeln befasst, sollte aber verstehen, dass sie normalerweise das Ergebnis zahlreicher Kompromisse zwischen dem Wunsch nach Aufwärtskompatibilität mit alter Nutzung, Wechselwirkungen zwischen verschiedenen Objektdefinitionen und dem unvermeidlichen Drang sind, neue Funktionen hinzuzufügen, wenn die Regeln definiert werden. Die Art und Weise, wie das DNS zur Unterstützung eines Objekts verwendet wird, ist oft entscheidender als die im DNS inhärenten Einschränkungen.

3.4. Beispiel-Namensraum (Example name space)​

Die folgende Abbildung zeigt einen Teil des aktuellen Domänennamen-Raums und wird in vielen Beispielen in diesem RFC verwendet. Beachten Sie, dass der Baum eine sehr kleine Teilmenge des tatsächlichen Namensraums ist.

                               |
                               |
         +---------------------+------------------+
         |                     |                  |
        MIL                   EDU                ARPA
         |                     |                  |
         |                     |                  |
   +-----+-----+               |     +------+-----+-----+
   |     |     |               |     |      |           |
  BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
                               |
   +--------+------------------+---------------+--------+
   |        |                  |               |        |
  UCI      MIT                 |              UDEL     YALE
            |                 ISI
            |                  |
        +---+---+              |
        |       |              |
       LCS  ACHILLES  +--+-----+-----+--------+
        |             |  |     |     |        |
        XX            A  C   VAXA  VENERA Mockapetris

In diesem Beispiel hat die Wurzeldomäne drei unmittelbare Subdomänen: MIL, EDU und ARPA. Die Domäne LCS.MIT.EDU hat eine unmittelbare Subdomäne namens XX.LCS.MIT.EDU. Alle Blätter sind auch Domänen.

3.5. Bevorzugte Namenssyntax (Preferred name syntax)​

Die DNS-Spezifikationen versuchen, bei den Regeln für die Konstruktion von Domänennamen so allgemein wie möglich zu sein. Die Idee ist, dass der Name jedes bestehenden Objekts mit minimalen Änderungen als Domänenname ausgedrückt werden kann. Wenn jedoch ein Domänenname für ein Objekt zugewiesen wird, wird der umsichtige Benutzer einen Namen auswählen, der sowohl die Regeln des Domänensystems als auch alle bestehenden Regeln für das Objekt erfüllt, unabhängig davon, ob diese Regeln veröffentlicht sind oder durch bestehende Programme impliziert werden.

Zum Beispiel sollte der Benutzer beim Benennen einer Mail-Domäne sowohl die Regeln dieses Memos als auch die in RFC-822 erfüllen. Beim Erstellen eines neuen Hostnamens sollten die alten Regeln für HOSTS.TXT befolgt werden. Dies vermeidet Probleme, wenn alte Software zur Verwendung von Domänennamen konvertiert wird.

Die folgende Syntax führt zu weniger Problemen mit vielen Anwendungen, die Domänennamen verwenden (z.B. Mail, TELNET).

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= eines der 52 alphabetischen Zeichen A bis Z in
             Großbuchstaben und a bis z in Kleinbuchstaben

<digit> ::= eine der zehn Ziffern 0 bis 9

Beachten Sie, dass, obwohl Groß- und Kleinbuchstaben in Domänennamen erlaubt sind, keine Bedeutung an die Groß-/Kleinschreibung gebunden ist. Das heißt, zwei Namen mit derselben Schreibweise, aber unterschiedlicher Groß-/Kleinschreibung, sind als identisch zu behandeln.

Die Labels müssen den Regeln für ARPANET-Hostnamen folgen. Sie müssen mit einem Buchstaben beginnen, mit einem Buchstaben oder einer Ziffer enden und als innere Zeichen nur Buchstaben, Ziffern und Bindestriche haben. Es gibt auch einige Längenbeschränkungen. Labels müssen 63 Zeichen oder weniger lang sein.

Zum Beispiel identifizieren die folgenden Zeichenketten Hosts im Internet:

A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA

3.6. Ressourceneinträge (Resource Records)​

Ein Domänenname identifiziert einen Knoten. Jeder Knoten hat eine Menge von Ressourceninformationen, die leer sein kann. Die Menge von Ressourceninformationen, die mit einem bestimmten Namen verbunden sind, besteht aus separaten Ressourceneinträgen (RRs). Die Reihenfolge der RRs in einer Menge ist nicht signifikant und muss nicht von Nameservern, Resolvern oder anderen Teilen des DNS beibehalten werden.

Wenn wir über einen bestimmten RR sprechen, nehmen wir an, dass er Folgendes hat:

owner (Eigentümer)​

Der Domänenname, wo der RR gefunden wird.

type (Typ)​

Ein kodierter 16-Bit-Wert, der den Typ der Ressource in diesem Ressourceneintrag spezifiziert. Typen beziehen sich auf abstrakte Ressourcen.

Dieses Memo verwendet die folgenden Typen:

  • A: eine Host-Adresse
  • CNAME: identifiziert den kanonischen Namen eines Alias
  • HINFO: identifiziert die CPU und das OS, die von einem Host verwendet werden
  • MX: identifiziert einen Mail-Exchange für die Domäne. Siehe [RFC-974] für Details.
  • NS: der autoritative Nameserver für die Domäne
  • PTR: ein Zeiger auf einen anderen Teil des Domänennamen-Raums
  • SOA: identifiziert den Beginn einer Autoritätszone

class (Klasse)​

Ein kodierter 16-Bit-Wert, der eine Protokollfamilie oder Instanz eines Protokolls identifiziert.

Dieses Memo verwendet die folgenden Klassen:

  • IN: das Internet-System
  • CH: das Chaos-System

TTL​

Die Time-to-Live des RR. Dieses Feld ist eine 32-Bit-Ganzzahl in Einheiten von Sekunden und wird hauptsächlich von Resolvern verwendet, wenn sie RRs cachen. Der TTL beschreibt, wie lange ein RR gecacht werden kann, bevor er verworfen werden sollte.

RDATA​

Die typ- und manchmal klassenabhängigen Daten, die die Ressource beschreiben:

  • A: Für die IN-Klasse eine 32-Bit-IP-Adresse. Für die CH-Klasse ein Domänenname gefolgt von einer 16-Bit-Oktal-Chaos-Adresse.
  • CNAME: ein Domänenname.
  • MX: ein 16-Bit-Präferenzwert (niedriger ist besser), gefolgt von einem Hostnamen, der bereit ist, als Mail-Exchange für die Eigentümerdomäne zu fungieren.
  • NS: ein Hostname.
  • PTR: ein Domänenname.
  • SOA: mehrere Felder.

RR-Strukturüberlegungen (RR structure considerations)​

Der Eigentümername ist oft implizit, anstatt einen integralen Teil des RR zu bilden. Zum Beispiel bilden viele Nameserver intern Baum- oder Hash-Strukturen für den Namensraum und verketten RRs von Knoten. Die verbleibenden RR-Teile sind der feste Header (Typ, Klasse, TTL), der für alle RRs konsistent ist, und ein variabler Teil (RDATA), der den Bedürfnissen der beschriebenen Ressource entspricht.

Die Bedeutung des TTL-Feldes ist eine Zeitbegrenzung dafür, wie lange ein RR in einem Cache gehalten werden kann. Diese Begrenzung gilt nicht für autoritative Daten in Zonen; diese werden auch zeitlich begrenzt, aber durch die Auffrischungsrichtlinien für die Zone. Der TTL wird vom Administrator für die Zone zugewiesen, aus der die Daten stammen. Während kurze TTLs verwendet werden können, um das Caching zu minimieren, und ein TTL von Null das Caching verbietet, legen die Realitäten der Internet-Performance nahe, dass diese Zeiten für den typischen Host in der Größenordnung von Tagen liegen sollten. Wenn eine Änderung vorhergesehen werden kann, kann der TTL vor der Änderung reduziert werden, um Inkonsistenz während der Änderung zu minimieren, und dann nach der Änderung auf seinen früheren Wert zurückerhöht werden.

Die Daten im RDATA-Abschnitt von RRs werden als Kombination von Binärzeichenketten und Domänennamen transportiert. Die Domänennamen werden häufig als "Zeiger" auf andere Daten im DNS verwendet.

3.6.1. Textuelle Darstellung von RRs (Textual expression of RRs)​

RRs werden in den Paketen des DNS-Protokolls in binärer Form dargestellt und werden normalerweise in stark kodierter Form dargestellt, wenn sie in einem Nameserver oder Resolver gespeichert werden. In diesem Memo übernehmen wir einen Stil ähnlich dem in Masterdateien verwendeten, um den Inhalt von RRs zu zeigen. In diesem Format werden die meisten RRs in einer einzelnen Zeile angezeigt, obwohl Fortsetzungszeilen mit Klammern möglich sind.

Der Anfang der Zeile gibt den Eigentümer des RR an. Wenn eine Zeile mit einem Leerzeichen beginnt, wird angenommen, dass der Eigentümer derselbe ist wie der des vorherigen RR. Leerzeilen werden oft zur Lesbarkeit eingefügt.

Nach dem Eigentümer listen wir den TTL, Typ und die Klasse des RR auf. Klasse und Typ verwenden die oben definierten Mnemonics, und TTL ist eine Ganzzahl vor dem Typfeld. Um Mehrdeutigkeit beim Parsen zu vermeiden, sind Typ- und Klassen-Mnemonics disjunkt, TTLs sind Ganzzahlen, und das Typ-Mnemonic ist immer zuletzt. Die IN-Klasse und TTL-Werte werden in Beispielen oft aus Gründen der Klarheit weggelassen.

Der Ressourcendaten- oder RDATA-Abschnitt des RR wird unter Verwendung der Kenntnis der typischen Darstellung für die Daten angegeben.

Zum Beispiel könnten wir die in einer Nachricht getragenen RRs wie folgt zeigen:

ISI.EDU.        MX      10 VENERA.ISI.EDU.
                MX      10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A       128.9.0.32
                A       10.1.0.52
VAXA.ISI.EDU.   A       10.2.0.27
                A       128.9.0.33

Die MX-RRs haben einen RDATA-Abschnitt, der aus einer 16-Bit-Zahl gefolgt von einem Domänennamen besteht. Die Adress-RRs verwenden ein Standard-IP-Adressformat, um eine 32-Bit-Internetadresse zu enthalten.

Dieses Beispiel zeigt sechs RRs, mit zwei RRs bei jedem der drei Domänennamen.

Ähnlich könnten wir sehen:

XX.LCS.MIT.EDU. IN      A       10.0.0.44
                CH      A       MIT.EDU. 2420

Dieses Beispiel zeigt zwei Adressen für XX.LCS.MIT.EDU, jede einer anderen Klasse.

3.6.2. Aliase und kanonische Namen (Aliases and canonical names)​

In bestehenden Systemen haben Hosts und andere Ressourcen oft mehrere Namen, die dieselbe Ressource identifizieren. Zum Beispiel identifizieren die Namen C.ISI.EDU und USC-ISIC.ARPA beide denselben Host. Ähnlich stellen im Fall von Mailboxen viele Organisationen viele Namen bereit, die tatsächlich zur selben Mailbox gehen; zum Beispiel gehen [email protected], [email protected] und [email protected] alle zur selben Mailbox (obwohl der Mechanismus dahinter etwas kompliziert ist).

Die meisten dieser Systeme haben eine Vorstellung, dass einer der äquivalenten Namen der kanonische oder primäre Name ist und alle anderen Aliase sind.

CNAME-Einträge (CNAME records)​

Das Domänensystem bietet eine solche Funktion unter Verwendung des kanonischen Namens (CNAME) RR. Ein CNAME-RR identifiziert seinen Eigentümernamen als Alias und spezifiziert den entsprechenden kanonischen Namen im RDATA-Abschnitt des RR. Wenn ein CNAME-RR an einem Knoten vorhanden ist, sollten keine anderen Daten vorhanden sein; dies stellt sicher, dass die Daten für einen kanonischen Namen und seine Aliase nicht unterschiedlich sein können. Diese Regel stellt auch sicher, dass ein gecachter CNAME verwendet werden kann, ohne mit einem autoritativen Server nach anderen RR-Typen zu prüfen.

CNAME-RRs verursachen spezielle Aktionen in DNS-Software. Wenn ein Nameserver einen gewünschten RR in der Ressourcenmenge, die mit dem Domänennamen verbunden ist, nicht findet, prüft er, ob die Ressourcenmenge aus einem CNAME-Eintrag mit einer übereinstimmenden Klasse besteht. Wenn dies der Fall ist, fügt der Nameserver den CNAME-Eintrag in die Antwort ein und startet die Abfrage beim Domänennamen neu, der im Datenfeld des CNAME-Eintrags angegeben ist. Die einzige Ausnahme von dieser Regel ist, dass Abfragen, die mit dem CNAME-Typ übereinstimmen, nicht neu gestartet werden.

Angenommen, ein Nameserver verarbeitete eine Abfrage für USC-ISIC.ARPA, forderte Typ-A-Informationen an und hatte die folgenden Ressourceneinträge:

USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

C.ISI.EDU       IN      A       10.0.0.52

Beide dieser RRs würden in der Antwort auf die Typ-A-Abfrage zurückgegeben, während eine Typ-CNAME- oder *-Abfrage nur den CNAME zurückgeben sollte.

Domänennamen in RRs, die auf einen anderen Namen zeigen, sollten immer auf den primären Namen und nicht auf den Alias zeigen. Dies vermeidet zusätzliche Indirektionen beim Zugriff auf Informationen. Zum Beispiel sollte der Adresse-zu-Name-RR für den obigen Host sein:

52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

anstatt auf USC-ISIC.ARPA zu zeigen. Natürlich sollte Domänensoftware nach dem Robustheitsprinzip nicht versagen, wenn ihr CNAME-Ketten oder -Schleifen präsentiert werden; CNAME-Ketten sollten verfolgt und CNAME-Schleifen als Fehler signalisiert werden.

3.7. Abfragen (Queries)​

Abfragen sind Nachrichten, die an einen Nameserver gesendet werden können, um eine Antwort zu provozieren. Im Internet werden Abfragen in UDP-Datagrammen oder über TCP-Verbindungen übertragen. Die Antwort des Nameservers beantwortet entweder die in der Abfrage gestellte Frage, verweist den Anfragenden an eine andere Gruppe von Nameservern oder signalisiert einen Fehlerzustand.

Im Allgemeinen generiert der Benutzer keine Abfragen direkt, sondern stellt stattdessen eine Anfrage an einen Resolver, der wiederum eine oder mehrere Abfragen an Nameserver sendet und mit den möglicherweise auftretenden Fehlerbedingungen und Verweisen umgeht. Natürlich prägt die Art der möglichen Fragen, die in einer Abfrage gestellt werden können, die Art des Dienstes, den ein Resolver bieten kann.

Nachrichtenformat (Message format)​

DNS-Abfragen und -Antworten werden in einem Standardnachrichtenformat übertragen. Das Nachrichtenformat hat einen Header, der eine Anzahl fester Felder enthält, die immer vorhanden sind, und vier Abschnitte, die Abfrageparameter und RRs tragen.

Das wichtigste Feld im Header ist ein Vier-Bit-Feld namens Opcode, das verschiedene Abfragen trennt. Von den möglichen 16 Werten ist einer (Standardabfrage) Teil des offiziellen Protokolls, zwei (inverse Abfrage und Statusabfrage) sind Optionen, einer (Vervollständigung) ist veraltet, und der Rest ist nicht zugewiesen.

Die vier Abschnitte sind:

  • Question (Frage): Trägt den Abfragenamen und andere Abfrageparameter.
  • Answer (Antwort): Trägt RRs, die die Abfrage direkt beantworten.
  • Authority (Autorität): Trägt RRs, die andere autoritative Server beschreiben. Kann optional den SOA-RR für die autoritativen Daten im Antwortabschnitt tragen.
  • Additional (Zusätzlich): Trägt RRs, die bei der Verwendung der RRs in den anderen Abschnitten hilfreich sein können.

Beachten Sie, dass der Inhalt, aber nicht das Format dieser Abschnitte mit dem Header-Opcode variiert.

3.7.1. Standardabfragen (Standard queries)​

Eine Standardabfrage spezifiziert einen Ziel-Domänennamen (QNAME), einen Abfragetyp (QTYPE) und eine Abfrageklasse (QCLASS) und fordert RRs an, die übereinstimmen. Dieser Abfragetyp macht eine so große Mehrheit der DNS-Abfragen aus, dass wir den Begriff "Abfrage" verwenden, um Standardabfrage zu bedeuten, sofern nicht anders angegeben. Die QTYPE- und QCLASS-Felder sind jeweils 16 Bit lang und sind eine Obermenge der definierten Typen und Klassen.

Das QTYPE-Feld kann enthalten:

  • <beliebiger Typ>: entspricht nur diesem Typ. (z.B. A, PTR).
  • AXFR: spezieller Zonentransfer-QTYPE.
  • MAILB: entspricht allen mailbox-bezogenen RRs (z.B. MB und MG).
  • *: entspricht allen RR-Typen.

Das QCLASS-Feld kann enthalten:

  • <beliebige Klasse>: entspricht nur dieser Klasse (z.B. IN, CH).
  • *: entspricht allen RR-Klassen.

Unter Verwendung des Abfrage-Domänennamens, QTYPE und QCLASS sucht der Nameserver nach übereinstimmenden RRs. Zusätzlich zu relevanten Einträgen kann der Nameserver RRs zurückgeben, die auf einen Nameserver zeigen, der die gewünschten Informationen hat, oder RRs, die bei der Interpretation der relevanten RRs voraussichtlich nützlich sind. Zum Beispiel kann ein Nameserver, der die angeforderten Informationen nicht hat, einen Nameserver kennen, der sie hat; ein Nameserver, der einen Domänennamen in einem relevanten RR zurückgibt, kann auch den RR zurückgeben, der diesen Domänennamen an eine Adresse bindet.

Beispielabfrage und -antwort (Example query and response)​

Zum Beispiel könnte ein Mailer, der versucht, Mail an [email protected] zu senden, den Resolver nach Mail-Informationen über ISI.EDU fragen, was zu einer Abfrage für QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN führt. Der Antwortabschnitt der Antwort wäre:

ISI.EDU.        MX      10 VENERA.ISI.EDU.
                MX      10 VAXA.ISI.EDU.

während der zusätzliche Abschnitt sein könnte:

VAXA.ISI.EDU.   A       10.2.0.27
                A       128.9.0.33
VENERA.ISI.EDU. A       10.1.0.52
                A       128.9.0.32

Weil der Server annimmt, dass, wenn der Anfragende Mail-Exchange-Informationen möchte, er wahrscheinlich bald danach die Adressen der Mail-Exchanges haben möchte.

Beachten Sie, dass die QCLASS=-Konstruktion eine spezielle Interpretation bezüglich Autorität erfordert. Da ein bestimmter Nameserver möglicherweise nicht alle im Domänensystem verfügbaren Klassen kennt, kann er niemals wissen, ob er für alle Klassen autoritativ ist. Daher können Antworten auf QCLASS=-Abfragen niemals autoritativ sein.

3.7.2. Inverse Abfragen (Inverse queries) (Optional)​

Nameserver können auch inverse Abfragen unterstützen, die eine bestimmte Ressource auf einen Domänennamen oder Domänennamen abbilden, die diese Ressource haben. Zum Beispiel könnte eine Standardabfrage einen Domänennamen auf einen SOA-RR abbilden, während die entsprechende inverse Abfrage den SOA-RR zurück auf den Domänennamen abbilden könnte.

Die Implementierung dieses Dienstes ist in einem Nameserver optional, aber alle Nameserver müssen zumindest in der Lage sein, eine inverse Abfragenachricht zu verstehen und eine Nicht-implementiert-Fehlerantwort zurückzugeben.

Das Domänensystem kann die Vollständigkeit oder Eindeutigkeit inverser Abfragen nicht garantieren, da das Domänensystem eher nach Domänenname als nach Host-Adresse oder einem anderen Ressourcentyp organisiert ist. Inverse Abfragen sind primär für Debugging- und Datenbankwartungsaktivitäten nützlich.

Inverse Abfragen geben möglicherweise nicht den richtigen TTL zurück und zeigen keine Fälle an, in denen der identifizierte RR einer von mehreren ist (z.B. eine Adresse für einen Host mit mehreren Adressen). Daher sollten in inversen Abfragen zurückgegebene RRs niemals gecacht werden.

Inverse Abfragen sind KEINE akzeptable Methode zum Abbilden von Host-Adressen auf Hostnamen; verwenden Sie stattdessen die IN-ADDR.ARPA-Domäne.

Eine detaillierte Diskussion inverser Abfragen ist in [RFC-1035] enthalten.

3.8. Statusabfragen (Status queries) (Experimentell)​

Noch zu definieren.

3.9. Vervollständigungsabfragen (Completion queries) (Veraltet)​

Die optionalen Vervollständigungsdienste, die in RFCs 882 und 883 beschrieben sind, wurden gelöscht. Neu gestaltete Dienste können in Zukunft verfügbar werden, oder die Opcodes können für andere Verwendung zurückgewonnen werden.

Letztes Update am