Aufbau einer DNS-Nachricht: Header, Flags und Wire-Format

Jeder DNS-Lookup, vom Browser, der eine Adresse erfragt, bis zum Resolver, der einer Delegierung folgt, ist eine kurze Binärnachricht in einem gemeinsamen Format. Die Bytes bekommen Sie selten zu sehen, doch Tools wie dig geben die Header-Felder als Text aus, und wenn Sie wissen, was sie bedeuten, wird aus dieser Ausgabe kein Rauschen mehr, sondern ein Beleg. Das Format ist seit 1987 in RFC 1035 spezifiziert, eine Verfeinerung von RFC 883 aus dem Jahr 1983, und wurde seither erweitert, nicht ersetzt.

Der 12-Byte-Header

Jede Nachricht beginnt mit denselben 12 Bytes: einer 16-Bit-ID, einem 16-Bit-Wort mit Flags und Codes und vier 16-Bit-Zählern.

Nach dem Header folgen die vier Abschnitte, in dieser Reihenfolge. Der Question-Abschnitt gibt wieder, was gefragt wurde, der Answer-Abschnitt enthält die Records, die darauf antworten, der Authority-Abschnitt verweist auf die für die Zone zuständigen Nameserver, und der Additional-Abschnitt enthält zusätzliche Records, von denen der Server erwartet, dass der Client sie als Nächstes braucht, etwa die Adressen dieser Nameserver.

Mit AA ist Vorsicht geboten. Ein rekursiver Resolver, der aus seinem Cache antwortet, ist für diese Daten keine Autorität und setzt das Flag nicht. Im ursprünglichen Entwurf kennzeichnet ein Server eine Antwort als autoritativ, wenn er aus Zonendaten antwortet, die er selbst hält, im Gegensatz zu gecachten Daten (Mockapetris und Dunlap, 1988). Ein aa in einer Antwort eines der eigenen Nameserver einer Zone ist der Normalfall, außer bei einem Referral an eine untergeordnete Zone: Dieses trägt es auch von einem autoritativen Server nicht.

Die Header-Zeile von dig lesen

dig gibt den Header in zwei Zeilen aus. Eine typische Antwort sieht so aus:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6891
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

opcode und status sind die Felder Opcode und RCODE. Die Zeile flags listet die gesetzten Bits auf, hier qr, rd und ra; zusammen bedeuten sie: eine Antwort auf eine Abfrage, die Rekursion verlangte, von einem Server, der sie anbietet. Die vier Zähler sind die Größen der Abschnitte. Das ADDITIONAL: 1 ist meist der EDNS-Pseudo-Record des Servers, der zurückgegeben wird, weil dig in seiner Abfrage einen mitschickt; es ist keine zusätzliche Adresse.

Der Status lässt sich am schnellsten lesen. RFC 1035 definiert sechs Antwortcodes.

Ein häufiges Ergebnis hat keinen eigenen Code. Ein Name, der existiert, aber keinen Record des abgefragten Typs hat, liefert NOERROR ohne Records dieses Typs im Answer-Abschnitt (ein CNAME kann dennoch erscheinen), was RFC 2308 als NODATA bezeichnet. Der Unterschied ist bei der Fehlersuche wichtig; was jeweils zu tun ist, steht in NXDOMAIN erklärt und DNS-Timeout oder SERVFAIL.

Eine Abfrage, Byte für Byte

Dies ist eine vollständige Abfrage nach dem A-Record von example.com in ihrer klassischen Form, ohne EDNS, so wie ein Client sie mit angeforderter Rekursion senden würde. Sie ist 29 Bytes lang.

1a 2b 01 00 00 01 00 00 00 00 00 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01

Dieselben Bytes laufen auch durch verschlüsselte Transporte. Bei DNS over HTTPS (RFC 8484) etwa wandert dieselbe Nachricht entweder als roher Body eines HTTP-POST oder, bei einer GET-Anfrage, base64url-kodiert in einem dns-Parameter, und Clients wird empfohlen, die ID auf 0 zu setzen; siehe DNS over HTTPS und DNS over TLS erklärt.

Namen, Grenzen und Kompression

Ein Name ist eine Folge von Labels, denen jeweils ihre Länge vorangestellt ist und die mit einem Nullbyte enden. RFC 1035 begrenzt ein Label auf 63 Oktette und einen ganzen Namen auf 255. Da das Längenbyte eines Labels nie größer als 63 ist, sind seine obersten zwei Bits immer null, und das schuf Raum für die Kompression: Sind die obersten zwei Bits beide eins, bilden dieses und das nächste Byte einen Zeiger, und die übrigen 14 Bits geben einen Offset vom Nachrichtenanfang an. In einer Antwort besteht der Name der Antwort sehr häufig aus den zwei Bytes c0 0c, einem Zeiger auf Offset 12, wo gleich nach dem Header der Name der Frage beginnt. Jedes DNS-Programm muss Zeiger in empfangenen Nachrichten verstehen, darf aber darauf verzichten, sie selbst zu erzeugen.

Warum 512 Bytes wichtig waren und was sie ablöste

RFC 1035 beschränkt UDP-Nachrichten auf 512 Bytes, ohne die IP- und UDP-Header. Eine längere Nachricht wird abgeschnitten und das TC-Bit gesetzt, was den Client anweist, es über TCP erneut zu versuchen. Die ursprünglichen Entwickler werteten die Datagrammgrenze als Erfolg und nicht als Problem: Die Leistung war deutlich besser als bei TCP-Verbindungen, und Betriebssystemressourcen wurden nicht gebunden, auch wenn die Entscheidung sorgfältige Strategien für die erneute Übertragung erforderte (Mockapetris und Dunlap, 1988).

Als die Antworten mit IPv6 und DNSSEC wuchsen, wurde die Grenze eng. EDNS(0), definiert in RFC 6891, lässt einen Client in einem OPT-Pseudo-Record eine größere UDP-Nutzlastgröße ankündigen. Der RFC schlägt 4096 Oktette als Ausgangspunkt vor und, falls das scheitert, einen Rückfall auf einen Bereich um 1280 bis 1410 Bytes. Seit RFC 7766 im Jahr 2016 ist die Unterstützung von TCP ein verpflichtender Bestandteil einer vollständigen DNS-Implementierung. Größere UDP-Antworten haben außerdem ihren Preis bei der Sicherheit, denn sie machen Reflection-Angriffe lohnender; DNS-Amplification-Angriffe und offene Resolver behandelt das.

Quellen und weiterführende Literatur

• RFC 1035: Domain Names - Implementation and Specification (Mockapetris, 1987)
• RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) (Andrews, 1998)
• RFC 2535: Domain Name System Security Extensions (Eastlake, 1999)
• RFC 4035: Protocol Modifications for the DNS Security Extensions (Arends et al., 2005)
• RFC 6891: Extension Mechanisms for DNS (EDNS(0)) (Damas, Graff and Vixie, 2013)
• RFC 7766: DNS Transport over TCP - Implementation Requirements (Dickinson et al., 2016)
• Paul V. Mockapetris and Kevin J. Dunlap, Development of the Domain Name System, Proceedings of SIGCOMM '88, Computer Communication Review 18(4), 1988, pp. 123-133
• Paul Albitz and Cricket Liu, DNS and BIND, 5th edition (O'Reilly, 2006)
• Kevin R. Fall and W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, 2nd edition (Addison-Wesley, 2011)