Zum Hauptinhalt springen

4. Messages (Nachrichten)

Alle Kommunikationen innerhalb des Domänenprotokolls werden in einem einzigen Format namens Nachricht übertragen.

4.1. Format​

Das Format auf oberster Ebene einer Nachricht ist in 5 Abschnitte unterteilt (von denen einige in bestimmten Fällen leer sind):

    +---------------------+
    |        Header       |
    +---------------------+
    |       Question      | die Frage an den Nameserver
    +---------------------+
    |        Answer       | RRs, die die Frage beantworten
    +---------------------+
    |      Authority      | RRs, die auf eine Autorität verweisen
    +---------------------+
    |      Additional     | RRs mit zusätzlichen Informationen
    +---------------------+

Abschnittsbeschreibungen:

  • Header: Immer vorhanden. Enthält Felder, die angeben, welche verbleibenden Abschnitte vorhanden sind und ob die Nachricht eine Abfrage oder Antwort, eine Standardabfrage oder ein anderer Opcode ist usw.

  • Question: Enthält Felder, die eine Frage an einen Nameserver beschreiben. Diese Felder sind ein Abfragetyp (QTYPE), eine Abfrageklasse (QCLASS) und ein Abfragedomänenname (QNAME).

  • Answer: Enthält RRs, die die Frage beantworten.

  • Authority: Enthält RRs, die auf einen autoritativen Nameserver verweisen.

  • Additional: Enthält RRs, die sich auf die Abfrage beziehen, aber nicht strikt Antworten auf die Frage sind.

Die letzten drei Abschnitte haben dasselbe Format: eine möglicherweise leere Liste verketteter Ressourceneinträge (RRs).

4.1.1. Header Section Format (Header-Abschnittsformat)​

Der Header enthält die folgenden Felder:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                       |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Feldbeschreibungen​

ID (16 Bits):

  • Ein 16-Bit-Identifikator, der vom Programm zugewiesen wird, das jede Art von Abfrage generiert
  • Dieser Identifikator wird in die entsprechende Antwort kopiert
  • Kann vom Anforderer verwendet werden, um Antworten mit ausstehenden Abfragen abzugleichen

QR (1 Bit):

  • Abfrage/Antwort-Flag (Query/Response Flag)
  • Gibt an, ob diese Nachricht eine Abfrage (0) oder eine Antwort (1) ist

OPCODE (4 Bits):

  • Gibt die Art der Abfrage in dieser Nachricht an
  • Wird vom Initiator einer Abfrage gesetzt und in die Antwort kopiert
  • Werte:
    • 0 - Standardabfrage (QUERY)
    • 1 - Inverse Abfrage (IQUERY)
    • 2 - Serverstatusanfrage (STATUS)
    • 3-15 - Reserviert für zukünftige Verwendung

AA (1 Bit):

  • Autoritative Antwort (Authoritative Answer)
  • Gültig in Antworten
  • Gibt an, dass der antwortende Nameserver eine Autorität für den Domänennamen im Frageabschnitt ist
  • Hinweis: Der Antwortabschnitt kann aufgrund von Aliasen mehrere Eigentümernamen haben. Das AA-Bit entspricht dem Namen, der dem Abfragenamen entspricht, oder dem ersten Eigentümernamen im Antwortabschnitt.

TC (1 Bit):

  • Abschneidung (TrunCation)
  • Gibt an, dass diese Nachricht aufgrund einer Länge abgeschnitten wurde, die auf dem Übertragungskanal größer als zulässig ist

RD (1 Bit):

  • Rekursion gewünscht (Recursion Desired)
  • Kann in einer Abfrage gesetzt werden und wird in die Antwort kopiert
  • Wenn RD gesetzt ist, weist es den Nameserver an, die Abfrage rekursiv zu verfolgen
  • Unterstützung für rekursive Abfragen ist optional

RA (1 Bit):

  • Rekursion verfügbar (Recursion Available)
  • Wird in einer Antwort gesetzt oder gelöscht
  • Gibt an, ob Unterstützung für rekursive Abfragen im Nameserver verfügbar ist

Z (3 Bits):

  • Reserviert für zukünftige Verwendung
  • Muss in allen Abfragen und Antworten null sein

RCODE (4 Bits):

  • Antwortcode
  • Als Teil von Antworten gesetzt
  • Werte:
    • 0 - Keine Fehlerbedingung
    • 1 - Formatfehler - Der Nameserver konnte die Abfrage nicht interpretieren
    • 2 - Serverfehler - Der Nameserver konnte diese Abfrage aufgrund eines Problems mit dem Nameserver nicht verarbeiten
    • 3 - Namensfehler - Nur für Antworten von einem autoritativen Nameserver sinnvoll, dieser Code bedeutet, dass der in der Abfrage referenzierte Domänenname nicht existiert
    • 4 - Nicht implementiert - Der Nameserver unterstützt die angeforderte Art von Abfrage nicht
    • 5 - Abgelehnt - Der Nameserver lehnt es aus politischen Gründen ab, die angegebene Operation auszuführen
    • 6-15 - Reserviert für zukünftige Verwendung

QDCOUNT (16 Bits):

  • Eine vorzeichenlose 16-Bit-Ganzzahl, die die Anzahl der Einträge im Frageabschnitt angibt

ANCOUNT (16 Bits):

  • Eine vorzeichenlose 16-Bit-Ganzzahl, die die Anzahl der Ressourceneinträge im Antwortabschnitt angibt

NSCOUNT (16 Bits):

  • Eine vorzeichenlose 16-Bit-Ganzzahl, die die Anzahl der Nameserver-Ressourceneinträge im Autoritätseintragsabschnitt angibt

ARCOUNT (16 Bits):

  • Eine vorzeichenlose 16-Bit-Ganzzahl, die die Anzahl der Ressourceneinträge im zusätzlichen Eintragsabschnitt angibt

4.1.2. Question Section Format (Frageabschnittsformat)​

Der Frageabschnitt wird verwendet, um die "Frage" in den meisten Abfragen zu tragen, d.h. die Parameter, die definieren, was gefragt wird.

Der Abschnitt enthält QDCOUNT (normalerweise 1) Einträge, jeder im folgenden Format:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     QNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QTYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QCLASS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Feldbeschreibungen​

QNAME (variabel):

  • Ein Domänenname, dargestellt als eine Sequenz von Labels
  • Jedes Label besteht aus einem Längen-Oktett, gefolgt von dieser Anzahl von Oktetten
  • Der Domänenname endet mit dem Null-Längen-Oktett für das Null-Label der Root
  • Hinweis: Dieses Feld kann eine ungerade Anzahl von Oktetten haben; es wird keine Auffüllung verwendet

QTYPE (16 Bits):

  • Ein Zwei-Oktett-Code, der den Typ der Abfrage angibt
  • Die Werte für dieses Feld umfassen alle für ein TYPE-Feld gültigen Codes sowie einige allgemeinere Codes, die mehr als einen RR-Typ abgleichen können

QCLASS (16 Bits):

  • Ein Zwei-Oktett-Code, der die Klasse der Abfrage angibt
  • Zum Beispiel ist das QCLASS-Feld IN für Internet

4.1.3. Resource Record Format (Ressourceneintrag-Format)​

Die Antwort-, Autoritäts- und zusätzlichen Abschnitte teilen alle dasselbe Format: eine variable Anzahl von Ressourceneinträgen, wobei die Anzahl der Einträge im entsprechenden Zählfeld im Header angegeben ist.

Jeder Ressourceneintrag hat das folgende Format:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                                               /
    /                      NAME                     /
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     CLASS                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TTL                      |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   RDLENGTH                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
    /                     RDATA                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Feldbeschreibungen​

NAME (variabel):

  • Ein Domänenname, zu dem dieser Ressourceneintrag gehört

TYPE (16 Bits):

  • Zwei Oktette, die einen der RR-Typ-Codes enthalten
  • Dieses Feld gibt die Bedeutung der Daten im RDATA-Feld an

CLASS (16 Bits):

  • Zwei Oktette, die die Klasse der Daten im RDATA-Feld angeben

TTL (32 Bits):

  • Eine vorzeichenlose 32-Bit-Ganzzahl, die das Zeitintervall (in Sekunden) angibt, für das der Ressourceneintrag zwischengespeichert werden kann, bevor er verworfen werden sollte
  • Nullwerte werden so interpretiert, dass der RR nur für die laufende Transaktion verwendet werden kann und nicht zwischengespeichert werden sollte

RDLENGTH (16 Bits):

  • Eine vorzeichenlose 16-Bit-Ganzzahl, die die Länge in Oktetten des RDATA-Feldes angibt

RDATA (variabel):

  • Eine Zeichenkette variabler Länge von Oktetten, die die Ressource beschreibt
  • Das Format dieser Informationen variiert je nach TYPE und CLASS des Ressourceneintrags
  • Wenn zum Beispiel der TYPE A und die CLASS IN ist, ist das RDATA-Feld eine 4-Oktett-ARPA-Internetadresse

4.1.4. Message Compression (Nachrichtenkomprimierung)​

Um die Größe von Nachrichten zu reduzieren, verwendet das Domänensystem ein Komprimierungsschema, das die Wiederholung von Domänennamen in einer Nachricht eliminiert.

Komprimierungsmethode​

In diesem Schema wird ein vollständiger Domänenname oder eine Liste von Labels am Ende eines Domänennamens durch einen Zeiger auf ein vorheriges Vorkommen desselben Namens ersetzt.

Zeigerformat:

Der Zeiger nimmt die folgende Form an:

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    | 1  1|                OFFSET                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  • Die ersten beiden Bits sind Einsen
  • Dies ermöglicht es, einen Zeiger von einem Label zu unterscheiden, da Labels mit zwei Null-Bits beginnen müssen
  • Das OFFSET-Feld gibt einen Versatz vom Beginn der Nachricht an (d.h. das erste Oktett des ID-Feldes im Domänen-Header)
  • Ein Null-Versatz gibt das erste Byte des ID-Feldes an usw.

Komprimierungsregeln​

Das Komprimierungsschema ermöglicht es, einen Domänennamen in einer Nachricht darzustellen als:

  1. Eine Sequenz von Labels, die mit einem Null-Oktett endet
  2. Ein Zeiger
  3. Eine Sequenz von Labels, die mit einem Zeiger endet

Wichtige Einschränkungen:

  • Zeiger können nur für Vorkommen eines Domänennamens verwendet werden, bei denen das Format nicht klassenspezifisch ist
  • Wäre dies nicht der Fall, müsste ein Nameserver oder Resolver das Format aller RRs kennen, die er behandelt
  • Bisher gibt es keine solchen Fälle, aber sie können in zukünftigen RDATA-Formaten auftreten

Komprimierung ist erlaubt:

  • Im NAME-Feld von Ressourceneinträgen
  • Im QNAME-Feld von Frageeinträgen
  • Immer wenn ein Domänenname im RDATA-Feld erscheint (nur für bestimmte RR-Typen, bei denen das Format bekannt ist)

Komprimierung ist NICHT erlaubt:

  • Im RDATA von RR-Typen, bei denen das RDATA-Format unbekannt oder variabel ist

Beispiel​

Wenn eine Abfrage enthält:

www.example.com
mail.example.com

Das zweite Vorkommen von "example.com" kann durch einen Zeiger auf das erste Vorkommen ersetzt werden, wodurch Bytes gespart werden.

4.2. Transport​

DNS-Nachrichten können von verschiedenen Transportprotokollen übertragen werden:

4.2.1. UDP Usage (UDP-Verwendung)​

  • Standard-Transport: UDP ist der bevorzugte Transport für DNS-Abfragen und -Antworten
  • Maximale Größe: DNS-Nachrichten, die über UDP gesendet werden, sollten (SHOULD NOT) 512 Oktette nicht überschreiten
  • Abschneidung: Wenn eine Antwort 512 Oktette überschreitet, sollte (SHOULD) das TC-Bit (Abschneidung) im Header gesetzt werden
  • Wiederholung: Wenn TC=1, sollte (SHOULD) der Client die Abfrage mit TCP wiederholen

Vorteile von UDP:

  • Geringerer Overhead
  • Schneller für kleine Abfragen
  • Keine Verbindungseinrichtung erforderlich

4.2.2. TCP Usage (TCP-Verwendung)​

  • Wann zu verwenden: TCP sollte (SHOULD) verwendet werden, wenn:
    • Die Antwortgröße 512 Oktette überschreitet
    • Zuverlässige Zustellung erforderlich ist
    • Zonentransfers durchgeführt werden
  • Nachrichtenformat: Bei Verwendung von TCP geht jedem Nachricht ein 16-Bit-Längenfeld voraus
  • Verbindungsverwaltung: Verbindungen können persistent sein oder nach jedem Abfrage-Antwort-Paar geschlossen werden

TCP-Nachrichtenformat:

    +---------------------+
    |  Length (16 bits)   |
    +---------------------+
    |                     |
    |   DNS Message       |
    |                     |
    +---------------------+

4.3. Standard Query Example (Standardabfrage-Beispiel)​

Hier ist ein Beispiel für eine Standardabfrage für den A-Eintrag von www.example.com:

Abfragenachrichtenstruktur:

Header:
  ID: 0x1234
  QR: 0 (Query)
  OPCODE: 0 (Standard Query)
  RD: 1 (Recursion Desired)
  QDCOUNT: 1
  ANCOUNT: 0
  NSCOUNT: 0
  ARCOUNT: 0

Question:
  QNAME: www.example.com
  QTYPE: A (1)
  QCLASS: IN (1)

Antwortnachrichtenstruktur:

Header:
  ID: 0x1234
  QR: 1 (Response)
  OPCODE: 0 (Standard Query)
  AA: 1 (Authoritative Answer)
  RD: 1 (Recursion Desired)
  RA: 1 (Recursion Available)
  RCODE: 0 (No Error)
  QDCOUNT: 1
  ANCOUNT: 1
  NSCOUNT: 0
  ARCOUNT: 0

Question:
  QNAME: www.example.com
  QTYPE: A (1)
  QCLASS: IN (1)

Answer:
  NAME: www.example.com
  TYPE: A (1)
  CLASS: IN (1)
  TTL: 3600
  RDLENGTH: 4
  RDATA: 93.184.216.34

Weiter: 5. Master Files (Master-Dateien)

Letztes Update am