Le DNS public de Google fournit deux API DoH distinctes au niveau de ces points de terminaison:
La page de présentation des transferts sécurisés contient des exemples de ligne de commande curl permettant d'utiliser les deux API, ainsi que des informations sur TLS et d'autres fonctionnalités communes au DNS sur TLS (DoT) et à DoH.
DoH est également compatible avec le service public DNS64 de Google IPv6 uniquement.
Le DNS public de Google n'accepte pas les URL http: non sécurisées pour les appels d'API.
Méthodes HTTP
- GET
- La méthode GET permet de réduire la latence, car elle est mise en cache de manière plus efficace.
Les requêtes GET RFC 8484 doivent comporter un paramètre de requête
?dns=avec un message DNS encodé en Base64Url. La méthode GET est la seule méthode compatible avec l'API JSON. - POST
- La méthode POST n'est compatible qu'avec l'API RFC 8484 et utilise un message DNS binaire avec Content-Type application/dns-message dans le corps de la requête et la réponse HTTP DoH.
- HEAD
- La balise HEAD n'est pas acceptée pour le moment et renvoie une erreur "400 Bad Request".
D'autres méthodes renvoient des erreurs "501 Not Implemented".
Codes d'état HTTP
Google Public DNS DoH renvoie les codes d'état HTTP suivants:
Réussite
- 200 OK
- L'analyse HTTP et la communication avec le résolveur DNS ont abouti, et le corps de la réponse est une réponse DNS au format binaire ou JSON, en fonction du point de terminaison de la requête, de l'en-tête Accept et des paramètres GET.
Redirections
- 301 (Changement d'adresse définitif)
- Les clients doivent réessayer à l'URL fournie dans l'en-tête
Location:. Si la requête d'origine était une requête POST, les clients ne doivent effectuer une nouvelle tentative avec GET que si la nouvelle URL spécifie un argument de paramètre GETdns. Sinon, ils doivent effectuer une nouvelle tentative avec POST.
D'autres codes tels que "302 Found", "307 Temporary Redirect" ou "308 Permanent Redirect" peuvent être utilisés à l'avenir. Les clients DoH doivent gérer les quatre codes.
Les réponses contenant les codes permanents 301 et 308 doivent être mises en cache indéfiniment. Si possible, les utilisateurs peuvent être invités à mettre à jour leur configuration d'origine à l'aide de la nouvelle URL.
Les requêtes POST qui reçoivent des réponses 307 ou 308 doivent toujours être relancées avec la méthode POST.
Erreurs
Les réponses d'erreur contiendront une explication de l'état HTTP dans le corps, au format HTML ou texte brut.
- 400 Requête incorrecte
- Problèmes lors de l'analyse des paramètres GET ou message de requête DNS non valide. En cas de paramètres GET incorrects, le corps HTTP doit expliquer l'erreur. La plupart des messages DNS non valides obtiennent un code d'erreur 200 avec FORMERR. L'erreur HTTP est renvoyée pour les messages illisibles sans section "Question", un indicateur QR indiquant une réponse ou d'autres combinaisons d'indicateurs absurdes avec des erreurs d'analyse DNS binaire.
- 413 Payload Too Large (Charge utile trop élevée)
- Le corps d'une requête POST RFC 8484 dépassait la taille maximale d'un message de 512 octets.
- 414 URI Too Long (URI trop long)
- L'en-tête de requête GET est trop volumineux, ou le paramètre
dnscomporte un message DNS encodé en Base64Url dépassant la taille maximale de message de 512 octets. - 415 Type de contenu non accepté
- Le corps POST ne comportait pas d'en-tête "Content-Type"
application/dns-message. - 429 Trop de requêtes
- Le client a envoyé trop de requêtes sur un laps de temps donné. Les clients doivent cesser d'envoyer des requêtes jusqu'à l'heure spécifiée dans l'en-tête Réessayer-After (temps relatif en secondes).
- 500 Erreur interne au serveur
- Erreurs DoH internes du DNS public de Google.
- 501 Non implémenté
- Seules les méthodes GET et POST sont implémentées. Les autres méthodes reçoivent cette erreur.
- 502 Passerelle incorrecte
- Le service DoH n'a pas pu contacter les résolveurs DNS publics Google.
Dans le cas d'une réponse 502, bien qu'une nouvelle tentative sur une autre adresse DNS publique Google puisse aider, une réponse de remplacement plus efficace consisterait à essayer un autre service DoH, ou à passer au DNS UDP ou TCP traditionnel à l'adresse 8.8.8.8.
Avantages de DoH
En plus du chiffrement TLS, l'utilisation du protocole HTTPS présente des avantages pratiques:
- Les API HTTPS largement disponibles et bien prises en charge simplifient l'implémentation pour le DNS public de Google lui-même et pour les clients potentiels.
- Un service HTTPS fournit aux applications Web un accès à tous les types d'enregistrements DNS, évitant ainsi les limites des API DNS de navigateur et d'OS existantes, qui ne prennent généralement en charge que les recherches hôte à adresse.
- Les clients qui implémentent la compatibilité HTTPS basée sur le protocole QUIC UDP peuvent éviter des problèmes tels que le blocage en tête de ligne qui peut survenir lors de l'utilisation du transport TCP.
Bonnes pratiques concernant la confidentialité pour DoH
Les développeurs d'applications DoH doivent tenir compte des bonnes pratiques en matière de confidentialité décrites dans le document RFC 8484 et développées ci-dessous:
Limiter l'utilisation des en-têtes HTTP
Les en-têtes HTTP fournissent des informations sur l'implémentation DoH du client et peuvent être utilisés pour désanonymiser les clients. Des en-têtes tels que "Cookie", "User-Agent" et "Accept-Language" sont les pires contrevenants, mais même l'ensemble d'en-têtes envoyés peut être révélateur. Pour réduire ce risque, n'envoyez que les en-têtes HTTP requis pour DoH: Host, Content-Type (pour POST) et, si nécessaire, Accept. Le user-agent doit être inclus dans toutes les versions de développement ou de test.
Utiliser les options de marge intérieure EDNS
Suivez les conseils de la RFC 8467 concernant l'utilisation des options de marge intérieure EDNS pour remplir les requêtes DoH sur quelques longueurs courantes afin de vous protéger contre l'analyse du trafic. L'utilisation du remplissage HTTP/2 est également possible, mais contrairement au remplissage EDNS, il n'entraîne pas de remplissage pour les réponses des serveurs DoH.
Utilisez la norme POST RFC 8484 uniquement pour les applications ou les modes de navigation sensibles à la confidentialité.
L'utilisation de la méthode POST pour les requêtes DoH réduit la mise en cache des réponses et peut augmenter la latence DNS. Elle n'est donc généralement pas recommandée. Toutefois, la réduction de la mise en cache est probablement souhaitable pour les applications sensibles à la confidentialité. Elle peut vous protéger contre les attaques temporelles des applications Web qui tentent de déterminer les domaines que l'utilisateur a consultés dernièrement.
Problèmes
Pour signaler un bug ou demander une nouvelle fonctionnalité, veuillez signaler un problème lié à DoH.