DNS-over-HTTPS (DoH)

Google Public DNS bietet zwei unterschiedliche DoH APIs an diesen Endpunkten:

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

Hinweis :Unter https://dns.google/ gibt es auch eine nutzerfreundliche Weboberfläche. Diese Webanwendung zeigt JSON-Ergebnisse in einem Browser an, implementiert jedoch keine API. Verwirren Sie dies nicht: https://dns.google/query? URLs mit den beiden API-URLs.

Auf der Seite Übersicht über sichere Transporte finden Sie curl-Befehlszeilenbeispiele für die Verwendung beider APIs sowie Details zu TLS und anderen gemeinsamen Funktionen von DNS über TLS (DoT) und DoH.

DoH wird auch für den reinen IPv6-Google Public DNS64-Dienst unterstützt.

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

HTTP-Methoden

GET

Die GET-Methode kann die Latenz reduzieren, da sie effektiver zwischengespeichert wird. RFC 8484-GET-Anfragen müssen einen ?dns=-Abfrageparameter mit einer base64Url-codierten DNS-Nachricht enthalten. Die GET-Methode ist die einzige unterstützte Methode für die JSON API.

POST

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

HEAD

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

Bei anderen Methoden wird der Fehler „501 Not Implemented“ zurückgegeben.

HTTP-Statuscodes

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

Abgeschlossen

200 OK

Das HTTP-Parsing und die Kommunikation mit dem DNS-Resolver waren erfolgreich. Der Inhalt des Antworttexts ist eine DNS-Antwort in Binär- oder JSON-Codierung, abhängig vom Abfrageendpunkt, dem Accept-Header und den GET-Parametern.

Hinweis: Ein HTTP-Erfolg kann dennoch ein DNS-Fehler sein. Prüfen Sie den DNS-Antwortcode (JSON-Feld „Status“) auf die DNS-Fehler SERVFAIL, FORMERR, REFUSED und NOTIMP.

Weiterleitungen

301-Fehler dauerhaft verschoben

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

Andere Codes wie 302 Found, 307 Temporary Redirect oder 308 Permanent Redirect können in Zukunft verwendet werden. DoH-Clients sollten alle vier Codes verarbeiten.

Antworten mit den permanenten 301- und 308-Codes sollten für unbegrenzte Zeit im Cache gespeichert werden. Nutzer können gegebenenfalls aufgefordert werden, ihre ursprüngliche Konfiguration mithilfe der neuen URL zu aktualisieren.

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

Fehler

In Fehlerantworten wird der HTTP-Status im Text entweder im HTML-Text oder im Nur-Text-Format erklärt.

400 Fehlerhafte Anfrage

Probleme beim Parsen der GET-Parameter oder eine ungültige Nachricht zur DNS-Anfrage Bei fehlerhaften GET-Parametern sollte der Fehler im HTTP-Text angegeben werden. Die meisten ungültigen DNS-Nachrichten erhalten mit einem FORMERR 200 OK. Der HTTP-Fehler wird bei unleserlichen Nachrichten ohne Frageabschnitt, bei einem QR-Flag, das eine Antwort anzeigt, oder bei anderen unsinnigen Flag-Kombinationen mit binären DNS-Parsing-Fehlern zurückgegeben.

413 Payload Too Large (Nutzlast zu groß)

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

414 URI Too Long (URI zu lang)

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

415 Nicht unterstützter Medientyp

Der POST-Textkörper hatte keinen application/dns-message Content-Type-Header.

429 Zu viele Anfragen

Der Client hat zu viele Anfragen in einem bestimmten Zeitraum gesendet. Clients sollten das Senden von Anfragen bis zu dem im Header „Wiederholen“ angegebenen Zeitpunkt stoppen (eine relative Zeit in Sekunden).

500 Interner Serverfehler

Interne DoH-Fehler bei Google Public DNS.

501 Nicht implementiert

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

502 Fehlerhaftes Gateway

Der DoH-Dienst konnte keine Google Public DNS-Resolver kontaktieren.

Bei einer 502-Antwort wäre ein Versuch mit einer alternativen Google Public DNS-Adresse hilfreich, eine effektivere Fallback-Antwort wäre es jedoch, einen anderen DoH-Dienst zu verwenden oder zum traditionellen UDP- oder TCP-DNS unter 8.8.8.8 zu wechseln.

Vorteile des DoH

Die Verwendung von HTTPS und nicht nur der TLS-Verschlüsselung bietet einige praktische Vorteile:

• Breiter verfügbare und gut unterstützte 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 und vermeidet so die Einschränkungen vorhandener Browser- und Betriebssystem-DNS-APIs, die im Allgemeinen nur Host-zu-Adress-Lookups unterstützen.
• Clients, die QUIC-UDP-basierte HTTPS-Unterstützung implementieren, können Probleme wie die Head-of-Line-Blockierung vermeiden, die bei der Verwendung von TCP-Transport auftreten können.

Best Practices für Datenschutz bei DoH

Entwickler von DoH-Anwendungen sollten die Best Practices zum Datenschutz berücksichtigen, die in RFC 8484 beschrieben sind und weiter unten aufgeführt sind:

• 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 Verstöße, aber selbst die gesendeten Header können verwirrend sein. Senden Sie nur die HTTP-Header, die für DoH erforderlich sind, um dieses Risiko zu minimieren: Host, Content-Type (für POST) und ggf. Accept. Der User-Agent sollte in allen Entwicklungs- oder Testversionen enthalten sein.

• EDNS-Padding-Optionen verwenden

  Folgen Sie der Anleitung in RFC 8467 für die Verwendung von EDNS-Padding-Optionen, um DoH-Abfragen mit einigen gängigen Längen aufzufüllen, um sich vor Traffic-Analysen zu schützen. Die Verwendung von HTTP/2-Padding ist ebenfalls möglich. Im Gegensatz zum EDNS-Padding wird bei Antworten von DoH-Servern jedoch kein Padding ausgelöst.

• Verwenden Sie RFC 8484 POST nur für Anwendungen, die vertrauliche Daten enthalten, oder für Browsermodi.

  Die Verwendung von POST für DoH-Abfragen reduziert die Cache-Fähigkeit von Antworten und kann die DNS-Latenz erhöhen. Daher wird POST generell nicht empfohlen. Bei datenschutzempfindlichen Anwendungen ist eine Reduzierung des Cachings jedoch wahrscheinlich wünschenswert und kann vor zeitlichen Angriffen von Webanwendungen schützen, die versuchen zu ermitteln, welche Domains der Nutzer in letzter Zeit besucht hat.

Probleme

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