DNS sur TLS

Introduction

Les requêtes et les réponses DNS traditionnelles sont envoyées via UDP ou TCP sans chiffrement. Cette méthode est vulnérable à l'espionnage et au spoofing (y compris au filtrage Internet basé sur DNS). Les réponses des résolveurs récursifs aux clients sont les plus vulnérables aux modifications indésirables ou malveillantes, tandis que les communications entre les résolveurs récursifs et les serveurs de noms primaires intègrent souvent une protection supplémentaire.

Pour résoudre ces problèmes, le DNS public de Google propose une résolution DNS sur les connexions TCP chiffrées par TLS, comme spécifié dans le document RFC 7858. DNS-over-TLS améliore la confidentialité et la sécurité entre les clients et les résolveurs. Cela complète DNSSEC et protège les résultats validés par DNSSEC contre les modifications ou le spoofing sur le chemin du client.

Fonctionnement

Remarque :Cette section présente l'opération DNS-over-TLS lors des communications avec le résolveur DNS public Google (nommé dns.google). Si vous souhaitez en savoir plus, consultez la spécification RFC pour le DNS sur Transport Layer Security et les profils d'utilisation pour DNS sur TLS et DNS sur DTLS.

Un système client peut utiliser DNS sur TLS avec l'un des deux profils : confidentialité stricte ou opportuniste. Avec le profil de confidentialité strict, l'utilisateur configure un nom de serveur DNS (le nom de domaine d'authentification dans le document RFC 8310) pour le service DNS sur TLS. Le client doit pouvoir créer une connexion TLS sécurisée sur le port 853 vers le serveur DNS. L'échec d'une connexion sécurisée est une erreur difficile et n'entraîne l'absence de service DNS pour le client.

Avec le profil de confidentialité opportuniste, l'adresse IP du serveur DNS peut être configurée directement par l'utilisateur ou obtenue à partir du réseau local (via DHCP ou un autre moyen). Le résolveur client tente d'établir une connexion sécurisée sur le port 853 vers le serveur DNS spécifié. Si une connexion sécurisée est établie, les requêtes de l'utilisateur sont protégées par des observateurs passifs sur le chemin. Comme le client ne vérifie pas l'authenticité du serveur, il n'est pas protégé contre un pirate informatique actif. Si le client ne peut pas établir de connexion sécurisée sur le port 853, il communique avec le serveur DNS sur le port DNS 53 standard via UDP ou TCP, sans aucune sécurité ni confidentialité. L'utilisation de la confidentialité opportuniste vise à faciliter le déploiement progressif de la confidentialité accrue en vue de l'adoption généralisée du profil de confidentialité strict.

Lorsque vous utilisez un profil de confidentialité strict, les résolveurs bouchon établissent une connexion DNS sur TLS en procédant comme suit.

1. Le résolveur bouchon est configuré avec le nom de résolveur DNS-over-TLS dns.google.
2. Le résolveur bouchon obtient la ou les adresses IP pour dns.google à l'aide du résolveur DNS local.
3. Le résolveur bouchon établit une connexion TCP sur le port 853 au niveau de cette adresse IP.
4. Le résolveur bouchon initie un handshake TLS avec le résolveur DNS public Google.
5. Le serveur DNS public de Google renvoie son certificat TLS, ainsi qu'une chaîne complète de certificats TLS jusqu'à un certificat racine de confiance.
6. Le résolveur bouchon vérifie l'identité du serveur en fonction des certificats présentés.
   • Si l'identité ne peut pas être validée, la résolution du nom DNS échoue et le résolveur de bouchon renvoie une erreur.
7. Une fois la connexion TLS établie, le résolveur de bouchon dispose d'un chemin de communication sécurisé entre un serveur DNS public Google.
8. Le résolveur bouchon peut désormais envoyer des requêtes DNS et recevoir des réponses via la connexion.

Lorsqu'il utilise un profil de confidentialité opportuniste, le client tente d'abord de créer une connexion TLS sécurisée avec le serveur. Cette opération s'effectue de la même manière que ci-dessus, avec une différence importante : le client ne procède à aucune validation de certificat. Cela signifie que l'identité du serveur ne peut pas être approuvée. Si une connexion TLS sur le port 853 vers le serveur ne peut pas être établie, le résolveur bouchon passe en communication avec le serveur DNS sur le port 53.

Remarque :Pour éviter les attaques par déni de service et l'épuisement des ressources sur le serveur, le DNS public de Google peut fermer les connexions DNS sur TLS qui sont inactives trop longtemps ou lorsqu'un grand nombre de requêtes ont été reçues sur la connexion. La prochaine fois que le client devra effectuer des requêtes DNS, le résolveur bouchon répétera les étapes ci-dessus pour rétablir la connexion au résolveur DNS public Google.

Confidentialité

Nos Règles de confidentialité s'appliquent au service DNS sur TLS.

Le 27/06/2019, nous avons réactivé le sous-réseau client EDNS (ECS) pour le service DNS sur TLS. ECS a été désactivé lors du lancement du service.

Prise en charge des standards

Le DNS public de Google implémente le protocole DNS sur TLS conformément au document RFC 7858. De plus, nous acceptons les recommandations suivantes afin de fournir un service DNS de haute qualité et à faible latence.

• TLS 1.3 (RFC 8846)
• TCP (RFC 7413)
• Exigences de mise en œuvre du transport DNS sur TCP (RFC 7766)

Commencer à l'utiliser

Consultez les instructions pour le configurer sur un appareil équipé d'Android 9 (Pie) ou version ultérieure.

DNS-over-TLS est également compatible avec le service DNS64 public de Google IPv6 uniquement. Notez que la configuration de DNS64 pour un appareil mobile devant être connecté à plusieurs réseaux n'est pas recommandée, car DNS64 ne fonctionne que lorsque IPv6 est disponible.