Il DNS pubblico di Google fornisce due diverse API DoH in questi endpoint:
La pagina Panoramica sui trasporti sicuri contiene curl esempi di riga di comando per l'utilizzo di entrambe le API e dettagli di TLS e di altre funzionalità comuni a DNS tramite TLS (DoT) e DoH.
DoH è supportato anche per il servizio DNS64 pubblico Google solo per IPv6.
Il DNS pubblico di Google non supporta URL http: non sicuri per le chiamate API.
Metodi HTTP
- GET
- L'utilizzo del metodo GET può ridurre la latenza poiché viene memorizzato nella cache in modo più efficace.
Le richieste GET RFC 8484 devono avere un parametro di query
?dns=con un messaggio DNS con codifica Base64Url. Il metodo Get è l'unico supportato per l'API JSON. - POST
- Il metodo POST è supportato solo per l'API RFC 8484 e utilizza un messaggio DNS binario con applicazione Content-Type/dns-message nel corpo della richiesta e nella risposta HTTP DoH.
- HEAD
- HEAD non è attualmente supportato e restituisce un errore 400 Bad Request (Richiesta errata).
Gli altri metodi restituiscono errori 501 Not Implemented (Non implementato).
Codici di stato HTTP
Google Public DNS DoH restituisce i seguenti codici di stato HTTP:
Operazione riuscita
- 200 OK
- L'analisi HTTP e la comunicazione con il resolver DNS sono riuscite e il contenuto del corpo della risposta è una risposta DNS con codifica binaria o JSON, a seconda dell'endpoint di query, dell'intestazione Accept e dei parametri GET.
Reindirizzamenti
- 301 Spostato in modo permanente
- I clienti dovrebbero riprovare all'URL fornito nell'intestazione
Location:. Se la query originale era una richiesta POST, i client devono riprovare con GET solo se il nuovo URL specifica un argomento del parametro GETdns; in caso contrario, i client devono riprovare con POST.
In futuro potrebbero essere utilizzati altri codici come 302 Found, 307 Temporary Redirect o 308 Permanent Redirect e i client DoH dovrebbero gestire tutti e quattro i codici.
Le risposte con i codici 301 e 308 permanenti devono essere memorizzate nella cache a tempo indeterminato e, se possibile, agli utenti potrebbe essere richiesto di aggiornare la configurazione originale utilizzando il nuovo URL.
Le richieste POST che ricevono risposte 307 o 308 devono sempre essere ritentate con POST.
Errori
Le risposte di errore forniscono una spiegazione dello stato HTTP nel corpo, utilizzando HTML o testo normale.
- richiesta non valida (400)
- Problemi di analisi dei parametri GET o un messaggio di richiesta DNS non valido. Per i parametri GET non validi, il corpo HTTP deve spiegare l'errore. Alla maggior parte dei messaggi DNS non validi viene assegnato un valore di 200 OK con FORMERR; l'errore HTTP viene restituito per i messaggi incomprensibili senza la sezione di domande, un flag QR che indica una risposta o altre combinazioni di flag senza senso con errori di analisi DNS binaria.
- 413 Payload troppo grande
- Il corpo di una richiesta POST RFC 8484 ha superato la dimensione massima del messaggio di 512 byte.
- URI 414 troppo lungo
- L'intestazione della query GET era troppo grande oppure il parametro
dnsaveva un messaggio DNS codificato in Base64Url che superava la dimensione massima del messaggio di 512 byte. - 415 Tipo di supporto non supportato
- Il corpo del POST non aveva un'intestazione Content-Type
application/dns-message. - 429 Troppe richieste
- Il client ha inviato troppe richieste in un determinato periodo di tempo. I client devono interrompere l'invio delle richieste fino al momento specificato nell'intestazione Riprova-Dopo (un tempo relativo in secondi).
- Errore interno del server (500)
- Errori DoH interni del DNS pubblico di Google.
- 501 Non implementato
- Solo i metodi GET e POST sono implementati, altri metodi ricevono questo errore.
- gateway non valido (502)
- Il servizio DoH non è riuscito a contattare i resolver DNS pubblici di Google.
Nel caso di una risposta 502, anche se un nuovo tentativo con un indirizzo Google Public DNS alternativo potrebbe essere utile, una risposta di fallback più efficace potrebbe essere provare un altro servizio DoH o passare al DNS tradizionale UDP o TCP all'indirizzo 8.8.8.8.
Vantaggi di DoH
L'utilizzo di HTTPS, non solo della crittografia TLS, presenta alcuni vantaggi pratici:
- Le API HTTPS ampiamente disponibili e ben supportate semplificano l'implementazione sia per Google Public DNS stesso sia per i potenziali clienti.
- Un servizio HTTPS fornisce alle app web l'accesso a tutti i tipi di record DNS, evitando le limitazioni delle API DNS esistenti del browser e del sistema operativo, che in genere supportano solo le ricerche host-to-address.
- I client che implementano il supporto HTTPS basato su QUIC UDP possono evitare problemi come il blocco head-of-line che può verificarsi quando si utilizza il trasporto TCP.
Best practice sulla privacy per DoH
Gli sviluppatori di applicazioni DoH devono prendere in considerazione le best practice sulla privacy descritte in RFC 8484 ed ampliate di seguito:
Limita l'utilizzo delle intestazioni HTTP
Le intestazioni HTTP rivelano informazioni sull'implementazione DoH del client e possono essere utilizzate per anonimizzare i client. Intestazioni come Cookie, User-Agent e Accetta-Language sono le violazioni peggiori, ma anche l'insieme di intestazioni inviate può essere rivelatore. Per ridurre al minimo questo rischio, invia solo le intestazioni HTTP richieste per DoH: Host, Content-Type (per POST) e, se necessario, Accept. Lo user agent deve essere incluso in qualsiasi versione di sviluppo o test.
Utilizzare le opzioni di spaziatura interna EDNS
Segui le indicazioni riportate in RFC 8467 per l'utilizzo delle opzioni di spaziatura interna EDNS per comprimere le query DoH di poche lunghezze comuni per evitare l'analisi del traffico. È anche possibile l'utilizzo della spaziatura interna HTTP/2 ma, a differenza di quella EDNS, non causerà un spaziatura interna nelle risposte dai server DoH.
Utilizza RFC 8484 POST solo per applicazioni sensibili alla privacy o modalità del browser
L'utilizzo di POST per le query DoH riduce la memorizzazione nella cache delle risposte e può aumentare la latenza DNS, pertanto non è consigliato in genere. Tuttavia, la riduzione della memorizzazione nella cache è probabilmente auspicabile per le applicazioni sensibili alla privacy e potrebbe proteggere dalla tempestività degli attacchi da parte delle app web che cercano di determinare quali domini l'utente ha visitato di recente.
Problemi
Per segnalare un bug o richiedere una nuova funzionalità, apri un problema per DoH.