4. The HTTP Exchange (Der HTTP-Austausch)

4.1. The HTTP Request (Die HTTP-Anfrage)

Ein DoH-Client kodiert eine einzelne DNS-Abfrage in eine HTTP-Anfrage unter Verwendung der HTTP-GET- oder POST-Methode sowie der anderen Anforderungen dieses Abschnitts. Der DoH-Server definiert den von der Anfrage verwendeten URI über eine URI-Vorlage (URI Template).

Die in diesem Dokument definierte URI-Vorlage wird ohne Variablen verarbeitet, wenn die HTTP-Methode POST ist. Bei der HTTP-Methode GET wird die einzelne Variable „dns" als Inhalt der DNS-Anfrage (wie in Abschnitt 6 beschrieben) definiert, kodiert mit base64url [RFC4648].

Zukünftige Spezifikationen für neue Medientypen für DoH MÜSSEN die für die URI-Vorlagenverarbeitung mit diesem Protokoll verwendeten Variablen definieren.

DoH-Server MÜSSEN sowohl die POST- als auch die GET-Methode implementieren.

Bei Verwendung der POST-Methode wird die DNS-Abfrage als Nachrichtenrumpf der HTTP-Anfrage eingeschlossen, und das Content-Type-Anfrage-Headerfeld gibt den Medientyp der Nachricht an. POST-Anfragen sind im Allgemeinen kleiner als ihre GET-Äquivalente.

Die Verwendung der GET-Methode ist für viele HTTP-Cache-Implementierungen freundlicher.

Der DoH-Client SOLLTE ein HTTP-Accept-Anfrage-Headerfeld einschließen, um anzugeben, welche Art von Inhalt als Antwort verstanden werden kann. Unabhängig vom Wert des Accept-Anfrage-Headerfelds MUSS der Client in der Lage sein, „application/dns-message"-Antworten (wie in Abschnitt 6 beschrieben) zu verarbeiten, KANN aber auch andere DNS-bezogene Medientypen verarbeiten, die er empfängt.

Um die HTTP-Cache-Freundlichkeit zu maximieren, SOLLTEN DoH-Clients, die Medienformate verwenden, die das ID-Feld aus dem DNS-Nachrichtenkopf enthalten (wie „application/dns-message"), in jeder DNS-Anfrage eine DNS-ID von 0 verwenden. HTTP korreliert Anfrage und Antwort und macht damit die ID in einem Medientyp wie „application/dns-message" überflüssig. Die Verwendung einer variierenden DNS-ID kann dazu führen, dass semantisch äquivalente DNS-Abfragen separat gecacht werden.

DoH-Clients können HTTP/2-Padding und -Komprimierung [RFC7540] auf dieselbe Weise verwenden wie andere HTTP/2-Clients.

4.1.1. HTTP Request Examples (HTTP-Anfrage-Beispiele)

Diese Beispiele verwenden die HTTP/2-Formatierung aus [RFC7540].

Diese Beispiele verwenden einen DoH-Dienst mit einer URI-Vorlage „https://dnsserver.example.net/dns-query{?dns}" zur Auflösung von IN-A-Einträgen.

Die Anfragen werden als Rümpfe mit dem Medientyp „application/dns-message" dargestellt.

Die erste Beispielanfrage verwendet GET, um „www.example.com" aufzulösen:

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message

Dieselbe DNS-Abfrage für „www.example.com" mit der POST-Methode wäre:

:method = POST
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query
accept = application/dns-message
content-type = application/dns-message
content-length = 33

<33 Bytes dargestellt durch folgende Hex-Kodierung>
00 00 01 00 00 01 00 00  00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
01

In diesem Beispiel sind die 33 Bytes die DNS-Nachricht im DNS-Wire-Format [RFC1035], beginnend mit dem DNS-Kopf.

4.2. The HTTP Response (Die HTTP-Antwort)

Der einzige in diesem Dokument definierte Antworttyp ist „application/dns-message", aber es ist möglich, dass in Zukunft andere Antwortformate definiert werden. Ein DoH-Server MUSS in der Lage sein, „application/dns-message"-Anfragenachrichten zu verarbeiten.

Verschiedene Antwort-Medientypen liefern mehr oder weniger Informationen aus einer DNS-Antwort. Zum Beispiel könnte ein Antworttyp Informationen aus den DNS-Kopf-Bytes enthalten, während ein anderer sie weglässt. Die Menge und Art der Informationen, die ein Medientyp liefert, liegt ausschließlich beim Format, das in diesem Protokoll nicht definiert ist.

Jedes DNS-Anfrage-Antwort-Paar wird einem HTTP-Austausch zugeordnet. Die Antworten können in beliebiger Reihenfolge unter Verwendung der HTTP-Multi-Streaming-Funktionalität verarbeitet und transportiert werden (siehe Abschnitt 5 von [RFC7540]).

4.2.1. Handling DNS and HTTP Errors (Behandlung von DNS- und HTTP-Fehlern)

DNS-Antwortcodes zeigen entweder Erfolg oder Misserfolg für die DNS-Abfrage an. Eine erfolgreiche HTTP-Antwort mit einem 2xx-Statuscode (siehe Abschnitt 6.3 von [RFC7231]) wird für jede gültige DNS-Antwort verwendet, unabhängig vom DNS-Antwortcode. Zum Beispiel wird ein erfolgreicher 2xx-HTTP-Statuscode auch dann verwendet, wenn eine DNS-Nachricht einen DNS-Antwortcode enthält, der auf Fehler hinweist, wie SERVFAIL oder NXDOMAIN.

HTTP-Antworten mit nicht erfolgreichen HTTP-Statuscodes enthalten keine Antworten auf die ursprüngliche DNS-Frage in der HTTP-Anfrage. DoH-Clients müssen dieselbe semantische Verarbeitung nicht erfolgreicher HTTP-Statuscodes wie andere HTTP-Clients verwenden.

4.2.2. HTTP Response Example (HTTP-Antwort-Beispiel)

Dies ist ein Beispiel für eine Antwort auf eine Abfrage nach IN-AAAA-Einträgen für „www.example.com" mit aktivierter Rekursion. Die Antwort enthält einen Antwortdatensatz mit der Adresse 2001:db8🔡12:1:2:3:4 und einer TTL von 3709 Sekunden.

:status = 200
content-type = application/dns-message
content-length = 61
cache-control = max-age=3709

<61 Bytes dargestellt durch folgende Hex-Kodierung>
00 00 81 80 00 01 00 01  00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 1c 00
01 c0 0c 00 1c 00 01 00  00 0e 7d 00 10 20 01 0d
b8 ab cd 00 12 00 01 00  02 00 03 00 04