DNS-over-HTTPS (DoH)

Google Public DNS bietet zwei verschiedene DoH-APIs an diesen Endpunkten:

• https://dns.google/dns-query – RFC 8484 (GET und POST)
• https://dns.google/resolve – JSON API (GET)

Auf der Seite Secure Transports – Übersicht finden Sie curl-Befehlszeilenbeispiele für die Verwendung beider APIs sowie Details zu TLS und anderen Funktionen, die für DNS über TLS (DoT) und DoH gelten.

DoH wird auch für den Nur-IP6-Dienst von Google Public DNS64 unterstützt, der nur IPv6 unterstützt.

Google Public DNS unterstützt keine unsicheren http:-URLs für API-Aufrufe.

HTTP-Methoden

NEUIGKEITEN

Mit der GET-Methode lässt sich die Latenz verringern, da sie effektiver im Cache gespeichert wird. RFC 8484-GET-Anfragen müssen einen ?dns=-Abfrageparameter mit einer Base64Url-codierten DNS-Nachricht haben. Für die JSON API wird nur die GET-Methode unterstützt.

POST

Die POST-Methode wird nur für die RFC 8484 API unterstützt und verwendet eine binäre DNS-Nachricht mit dem Inhaltstyp „application/dns-message“ im Anfragetext und in der DoH-HTTP-Antwort.

HEAD

HEAD wird derzeit nicht unterstützt und gibt einen 400-Fehler „Bad Request“ zurück.

Bei anderen Methoden werden Fehler des Typs 501 (Nicht implementiert) zurückgegeben.

HTTP-Statuscodes

Google Public DNS DoH gibt die folgenden HTTP-Statuscodes zurück:

Erfolg

200 OK

Das HTTP-Parsing und die Kommunikation mit dem DNS-Resolver waren erfolgreich und der Inhalt des Antworttexts ist eine DNS-Antwort mit Binär- oder JSON-Codierung, je nach Abfrageendpunkt, Header akzeptieren und GET-Parameter.

Weiterleitungen

301 Dauerhaft verschoben

Kunden sollten es unter der im Location:-Header angegebenen URL noch einmal versuchen. Wenn die ursprüngliche Abfrage eine POST-Anfrage war, sollten Clients den Vorgang mit GET nur dann wiederholen, wenn die neue URL das GET-Parameter-Argument dns angibt. Andernfalls sollten die Clients mit POST wiederholen.

Andere Codes wie „302 Found“, „307 Temporäre Weiterleitung“ oder „308 Dauerhafte Weiterleitung“ können in Zukunft verwendet werden und DoH-Clients sollten alle vier Codes verarbeiten.

Antworten mit den permanenten 301- und 308-Codes sollten auf unbestimmte Zeit im Cache gespeichert werden. Gegebenenfalls können Nutzer jedoch aufgefordert werden, ihre ursprüngliche Konfiguration mit der neuen URL zu aktualisieren.

POST-Anfragen, die 307- oder 308-Antworten empfangen, sollten immer mit POST wiederholt werden.

Fehler

Die Fehlerantworten enthalten eine Erläuterung des HTTP-Status im Textkörper (entweder im HTML- oder im Nur-Text-Format).

400 Fehlerhafte Anfrage

Probleme beim Parsen der GET-Parameter oder einer ungültigen DNS-Anfragenachricht. Bei fehlerhaften GET-Parametern sollte der Fehler im HTTP-Text angegeben werden. Die meisten ungültigen DNS-Nachrichten erhalten mit einem FORMERR-Objekt die Antwort „200 OK“. Der HTTP-Fehler wird für verzerrte Nachrichten ohne Fragenbereich, ein QR-Flag, das eine Antwort angibt, oder andere unsinnige Flag-Kombinationen mit binären DNS-Parsing-Fehlern zurückgegeben.

413 Nutzlast zu groß

Ein POST-Anfragetext nach RFC 8484 hat die maximale Nachrichtengröße von 512 Byte überschritten.

414 URI zu lang

Der GET-Anfrageheader war zu groß oder der dns-Parameter enthielt eine Base64Url-codierte DNS-Nachricht, die die maximale Nachrichtengröße von 512 Byte überschreitet.

415 Nicht unterstützter Medientyp

Der POST-Text hatte keinen application/dns-message-Inhaltstyp-Header.

429 Zu viele Anfragen

Der Client hat zu viele Anfragen innerhalb eines bestimmten Zeitraums gesendet. Clients sollten keine Anfragen mehr bis zur im Wiederholungsheader angegebenen Zeit senden (eine relative Zeit in Sekunden).

500 Interner Serverfehler

Interne DNS-Fehler bei Google Public DNS.

501 Nicht implementiert

Nur GET- und POST-Methoden werden implementiert, andere erhalten diesen Fehler.

502 Fehlerhaftes Gateway

Der DoH-Dienst konnte keine Verbindung zu den Google-DNS-Resolvern herstellen.

Im Fall einer 502-Antwort kann ein effektiverer Fallback-Antwortvorgang helfen, wenn Sie einen anderen DoH-Dienst ausprobieren oder zu herkömmlichem UDP oder TCP-DNS unter 8.8.8.8 wechseln, obwohl das noch einmal versuchen kann.

Vorteile von DoH

Die Verwendung von HTTPS statt nur der TLS-Verschlüsselung hat einige praktische Vorteile:

• Die allgemein verfügbaren und gut unterstützten HTTPS APIs vereinfachen die Implementierung sowohl für Google Public DNS selbst als auch für potenzielle Clients.
• Ein HTTPS-Dienst bietet Webanwendungen Zugriff auf alle DNS-Eintragstypen, wodurch die Einschränkungen vorhandener Browser- und Betriebssystem-DNS-APIs vermieden werden, die in der Regel nur Host-zu-Adresse-Lookups unterstützen.
• Clients, die QUIC UDP-basierte HTTPS-Unterstützung implementieren, können Probleme wie die Head-of-Line-Blockierung vermeiden, die beim TCP-Transport auftreten kann.

Best Practices für den Datenschutz bei DoH

Entwickler von DoH-Anwendungen sollten die in RFC 8484 beschriebenen und im Folgenden erweiterten Best Practices für den Datenschutz berücksichtigen:

• Verwendung von HTTP-Headern einschränken

  HTTP-Header enthalten Informationen zur DoH-Implementierung des Clients und können zur Deanonymisierung von Clients verwendet werden. Header wie Cookie, User-Agent und Accept-Language sind die schlimmsten Straftatbestände, aber selbst die Header der gesendeten Informationen können eingeblendet werden. Senden Sie zum Minimieren dieses Risikos nur die für DoH erforderlichen HTTP-Header: Host, Content-Type (für POST) und gegebenenfalls „Accept“. Der User-Agent muss in allen Entwicklungs- und Testversionen enthalten sein.

• EDNS-Padding-Optionen verwenden

  Beachten Sie die Hinweise in RFC 8467 zur Verwendung von EDNS-Padding-Optionen, um DoH-Abfragen auf ein paar übliche Längen aufzufüllen, um die Daten vor Traffic-Analysen zu schützen. Auch HTTP/2-Padding kann verwendet werden. Im Gegensatz zum EDNS-Padding wird kein Padding bei Antworten von DoH-Servern ausgelöst.

• RFC 8484 POST nur für datenschutzkonforme Anwendungen oder Browsermodi verwenden

  Die Verwendung von POST für DoH-Abfragen verringert die Cache-Fähigkeit von Antworten und kann die DNS-Latenz erhöhen, daher wird sie im Allgemeinen nicht empfohlen. Allerdings ist eine Verringerung des Cachings bei datenschutzsensiblen Anwendungen wahrscheinlich wünschenswert. Sie kann dadurch vor Timing-Angriffen von Webanwendungen schützen, die versuchen, die Domains zu ermitteln, die der Nutzer in letzter Zeit besucht hat.

Probleme

Wenn Sie einen Fehler melden oder eine neue Funktion anfordern möchten, öffnen Sie bitte ein Problem für DoH.