Extended DNS

Unter Extended DNS (EDNS) werden verschiedene Protokoll-Erweiterungen des Domain Name Systems (DNS) zusammengefasst, die den Transport von DNS-Daten in UDP-Paketen betreffen.

Motivation

Das in der ersten Hälfte der 1980er entwickelte DNS wurde im Laufe der Jahre mit zahlreichen weiteren Funktionen ausgestattet. Die in DNS-Paketen vorhandenen Flags, Returncodes und Label-Typen reichten schließlich nicht mehr aus, alle Situationen zu beschreiben. Ein weiteres gravierendes Problem ergab sich aus der Längenbeschränkung des DNS-UDP-Pakets von 512 Bytes. Diese Einschränkungen machten eine Erweiterung des DNS-Paket-Formats unumgänglich. 1999 wurde von Paul Vixie im RFC 2671^[1] ein entsprechender Standard formuliert.

Funktionsweise

Da im DNS-Header kein Flag mehr zur Verfügung stand, um zwischen herkömmlichem und EDNS-Format zu unterscheiden, wurde ein sogenannter Pseudo-Record eingeführt, der sogenannte OPT Resource Record. Ein derartiger Pseudo-RR wird nur auf dem Transportweg zwischen Client und Server verwendet. Er erscheint niemals in Zonendateien oder in Caches. Ein DNS-Teilnehmer, der ein DNS-Paket als EDNS kennzeichnen möchte, fügt einen entsprechenden Pseudo-RR in die Additional Data Section der DNS-Anfrage oder -Antwort ein.

Neben der Aufgabe, ein Paket als EDNS-Paket zu markieren, hat ein OPT-Resource-Record folgende Funktionen:

Bereitstellung von 16 zusätzlichen Flags
Erweiterung des Response-Codes um acht Bytes (damit können in einem Paket insgesamt drei Response-Codes untergebracht werden)

Außerdem sind die Gesamtlänge des UDP-Pakets und die Versions-Nummer (zurzeit 0) enthalten. In einem Datenfeld variabler Länge können zukünftig weitere Informationen eingetragen werden.

Eine weitere im RFC 2671^[1] spezifizierte Erweiterung bezieht sich auf das Label-Format. Ursprünglich gab es in DNS-Paketen zwei Label-Typen, die durch die ersten beiden Bits definiert werden (RFC 1035^[2]):

00 = Standard-Label
11 = komprimiertes Label

Um eine größere Anzahl weiterer Label-Typen zu ermöglichen, wird der Typ 01 = "Extended Label" definiert. Aus den folgenden 6 Bits des ersten Bytes können damit insgesamt 63 Label-Untertypen gebildet werden.

Praxis

EDNS ist bei DNSSEC zwingend notwendig, da das DO-Flag (DNSSEC OK) nicht mehr im Standard-Header untergebracht werden kann. Das DO-Flag ist auch das erste neu definierte Flag.

Im Zusammenhang mit älteren Firewalls können Schwierigkeiten auftreten, wenn diese von einer maximalen DNS-Nachrichten-Länge von 512 Bytes ausgehen und längere Pakete verwerfen.^[3]

Beispiel der Darstellung von OPT-Daten bei der Ausgabe des dig-Tools:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

Normen und Standards

RFC: 2671 – Extension Mechanisms for DNS (EDNS0). 1999 (englisch).

Einzelnachweise

↑ ^a ^b RFC: 2671 – Extension Mechanisms for DNS (EDNS0). 1999 (englisch).
↑ RFC: 1035 – Domain Names – Implementation and Specification. (englisch).
↑ Nach der Bereitstellung eines Windows-basierten DNS-Servers sind einige DNS-Namensabfragen nicht erfolgreich. In: Microsoft Support. 24. April 2017, abgerufen am 28. Januar 2019.

[RFC2671-1] RFC: 2671 – Extension Mechanisms for DNS (EDNS0). 1999 (englisch).

[2] RFC: 1035 – Domain Names – Implementation and Specification. (englisch).

[3] Nach der Bereitstellung eines Windows-basierten DNS-Servers sind einige DNS-Namensabfragen nicht erfolgreich. In: Microsoft Support. 24. April 2017, abgerufen am 28. Januar 2019.

[1]

[2]

[3]