5. HTTP Integration (HTTP-Integration)
Dieses Protokoll MUSS mit dem https-URI-Schema [RFC7230] verwendet werden.
Die Abschnitte 8 und 9 erörtern zusätzliche Überlegungen zur Integration mit HTTP.
5.1. Cache Interaction (Cache-Interaktion)
Ein DoH-Austausch kann eine Hierarchie von Caches durchlaufen, die sowohl HTTP- als auch DNS-spezifische Caches umfassen. Diese Caches können zwischen dem DoH-Server und dem Client existieren oder auf dem DoH-Client selbst vorhanden sein. HTTP-Caches sind von Natur aus generisch; das heißt, sie verstehen dieses Protokoll nicht. Selbst wenn ein DoH-Client seine Cache-Implementierung so geändert hat, dass er DoH-Semantik versteht, bedeutet das nicht, dass alle vorgelagerten Caches (z. B. Inline-Proxys, serverseitige Gateways und Content-Delivery-Netzwerke) dies ebenfalls tun.
Daher müssen DoH-Server die HTTP-Caching-Metadaten, die sie als Antwort auf GET-Anfragen senden, sorgfältig berücksichtigen (Antworten auf POST-Anfragen sind nicht cachebar, es sei denn, bestimmte Antwort-Headerfelder werden gesendet; dies ist nicht weit verbreitet implementiert und wird für DoH nicht empfohlen).
Insbesondere SOLLTEN DoH-Server eine explizite HTTP-Frischelebensdauer (freshness lifetime) zuweisen (siehe Abschnitt 4.2 von [RFC7234]), damit der DoH-Client mit größerer Wahrscheinlichkeit frische DNS-Daten verwendet.
Die zugewiesene Frischelebensdauer einer DoH-HTTP-Antwort MUSS kleiner oder gleich dem kleinsten TTL-Wert im Antwortabschnitt der DNS-Antwort sein. Eine Frischelebensdauer, die dem kleinsten TTL-Wert im Antwortabschnitt entspricht, wird EMPFOHLEN. Wenn eine HTTP-Antwort beispielsweise drei RRsets mit TTLs von 30, 600 und 300 enthält, sollte die HTTP-Frischelebensdauer 30 Sekunden betragen (was als „Cache-Control: max-age=30" angegeben werden könnte).
Wenn die DNS-Antwort keine Einträge im Antwortabschnitt hat und die DNS-Antwort einen SOA-Eintrag im Autoritätsabschnitt hat, DARF die Antwort-Frischelebensdauer NICHT größer als das MINIMUM-Feld aus diesem SOA-Eintrag sein (siehe [RFC2308]).
Die Cache-Control-Direktiven stale-while-revalidate und stale-if-error [RFC5861] könnten für eine DoH-Implementierung gut geeignet sein, wenn sie durch die Serverrichtlinie erlaubt sind.
DoH-Clients MÜSSEN den Wert des Age-Antwort-Headerfelds [RFC7234] bei der Berechnung der DNS-TTL einer Antwort berücksichtigen. Wenn beispielsweise ein RRset mit einer DNS-TTL von 600 empfangen wird, aber das Age-Headerfeld anzeigt, dass die Antwort 250 Sekunden lang gecacht wurde, beträgt die verbleibende Lebensdauer des RRsets 350 Sekunden.
DoH-Clients können eine nicht gecachte Kopie einer HTTP-Antwort anfordern, indem sie die „no-cache"-Anfrage-Cache-Control-Direktive verwenden (siehe Abschnitt 5.2.1.4 von [RFC7234]).
5.2. HTTP/2
HTTP/2 [RFC7540] ist die mindestens EMPFOHLENE Version von HTTP für die Verwendung mit DoH.
Die Nachrichten im klassischen UDP-basierten DNS [RFC1035] sind von Natur aus ungeordnet und haben einen geringen Overhead. Ein wettbewerbsfähiger HTTP-Transport muss Neuordnung, Parallelität, Priorität und Header-Komprimierung unterstützen, um eine ähnliche Leistung zu erzielen. Diese Funktionen wurden in HTTP/2 [RFC7540] in HTTP eingeführt.
5.3. Server Push (Server-Push)
Bevor DoH-Antwortdaten für die DNS-Auflösung verwendet werden, MUSS der Client feststellen, dass der HTTP-Anfrage-URI für die DoH-Abfrage verwendet werden kann. Für HTTP-Anfragen, die vom DoH-Client initiiert werden, ist dies implizit in der Auswahl des URI. Für HTTP-Server-Push (siehe Abschnitt 8.2 von [RFC7540]) muss besondere Sorgfalt walten, um sicherzustellen, dass der gepushte URI einer ist, an den der Client dieselbe Abfrage gerichtet hätte, wenn der Client die Anfrage initiiert hätte.
5.4. Content Negotiation (Inhaltsaushandlung)
Um die Interoperabilität zu maximieren, MÜSSEN DoH-Clients und DoH-Server den Medientyp „application/dns-message" unterstützen. Andere Medientypen KÖNNEN wie durch HTTP-Inhaltsaushandlung definiert verwendet werden (siehe Abschnitt 3.4 von [RFC7231]). Diese Medientypen MÜSSEN flexibel genug sein, um jede DNS-Abfrage auszudrücken, die normalerweise in DNS über UDP gesendet würde (einschließlich Abfragen und Antworten, die DNS-Erweiterungen verwenden, aber nicht solche, die mehrere Antworten erfordern).