Explication du chiffrement des DNS

Le Domain Name System (DNS) est le carnet d'adresses d'Internet. Lorsque vous consultez cloudflare.com ou tout autre site, votre navigateur demandera à un résolveur DNS l'adresse IP où se trouve le site. Malheureusement, ces requêtes et réponses DNS ne sont généralement pas protégées. Le chiffrement des DNS renforcerait la confidentialité et la sécurité des utilisateurs. Dans cet article, nous examinerons deux mécanismes de chiffrement de DNS, appelés DNS over TLS (DoT) et DNS over HTTPS (DoH), et expliquerons leur fonctionnement.

Les applications qui veulent résoudre un nom de domaine vers une adresse IP utilisent généralement des DNS. En général, ce n'est pas le programmeur qui a écrit l'application qui le fait de manière explicite. Au lieu de cela, il écrit quelque chose qui ressemble à fetch("https://example.com/news") et demande à une bibliothèque logicielle de gérer la traduction de "example.com" en une adresse IP.

En arrière-plan, la librairie logicielle se charge de découvrir le résolveur DNS récursif externe, de s'y connecter et de lui communiquer le protocole DNS (voir la figure ci-dessous) afin de résoudre le nom demandé par l'application. Le choix du résolveur DNS externe et la question de savoir si la confidentialité et la sécurité sont assurées ne dépendent pas de l'application. Cela dépend de la bibliothèque logicielle utilisée et des politiques définies par le système d'exploitation de l'appareil qui exécute le logiciel.

Généralités sur les requêtes et réponses DNS

Le système d'exploitation apprend généralement l'adresse du résolveur par le réseau local en utilisant le protocole DHCP (Dynamic Host Configuration Protocol). Dans les réseaux domestiques et mobiles, il finit généralement par utiliser le résolveur du fournisseur d'accès à Internet (FAI). Dans les réseaux d'entreprise, le résolveur sélectionné est généralement contrôlé par l'administrateur réseau. S'ils le souhaitent, les utilisateurs qui contrôlent leurs appareils peuvent remplacer le résolveur par une adresse spécifique, comme par exemple l'adresse d'un résolveur public comme 8.8.8.8 de Google ou 1.1.1.1 de Cloudflare, mais la plupart des utilisateurs ne s’ennuient pas à le faire lorsqu'ils se connectent à un point d’accès Wi-Fi public dans un café ou un aéroport.

Le choix d'un résolveur externe a un impact direct sur la qualité de l’expérience de l’utilisateur. La plupart des utilisateurs ne modifient pas leurs paramètres de résolveur et finiront probablement par utiliser le résolveur DNS de leur FAI. L'amélioration la plus visible est la rapidité et l'exactitude de la résolution des noms. Les améliorations en matière de confidentialité ou de sécurité ne seront peut-être pas immédiatement perceptibles, mais elles permettront d'empêcher d'autres personnes de faire du profilage ou d'interférer avec votre navigation. Ceci est particulièrement important dans le cas des réseaux Wi-Fi publics où quiconque se trouvant physiquement à proximité peut capturer et déchiffrer le trafic du réseau sans fil.

Depuis leur création en 1987, les DNS ont été la plupart du temps non chiffrés. Quiconque se trouvant entre votre appareil et le résolveur est capable d'espionner ou même de modifier vos requêtes et réponses DNS. Il peut s'agir de toute personne sur votre réseau Wi-Fi local, de votre fournisseur d'accès Internet (FAI) et des fournisseurs de transit. Cela peut avoir une incidence sur votre confidentialité en révélant les noms des domaines que vous visitez.

Que peuvent-ils voir ? Prenons l'exemple de cette capture de paquets réseau sur un ordinateur portable connecté à un réseau domestique :

On peut faire les observations suivantes :

• Le port source UDP est le 53, qui est le numéro de port standard pour les DNS non chiffrés. Le payload UDP peut donc être une réponse DNS.

• Cela laisse supposer que l'adresse IP source 192.168.2.254 est un résolveur DNS alors que l'adresse IP de destination 192.168.2.14 est le client DNS.

• La payload UDP pourrait en effet être analysée comme une réponse DNS, et révèle que l'utilisateur essayait de se connecter à twitter.com.

• S'il y a des connexions futures vers 104.244.42.129 ou 104.244.42.42.1, alors c'est très probablement le trafic qui est dirigé vers "twitter.com".

• Si un trafic HTTPS chiffré supplémentaire est acheminé vers cette adresse IP, suivi d'autres requêtes DNS, cela pourrait indiquer qu'un navigateur Web a chargé des ressources supplémentaires à partir de cette page. Cela pourrait potentiellement révéler les pages qu'un utilisateur a consultées sur twitter.com.

Étant donné que les messages DNS ne sont pas protégés, d'autres attaques sont possibles :

• Les requêtes pourraient être dirigées vers un résolveur qui effectue un détournement du DNS. Par exemple, au Royaume-Uni, Virgin Media et BT renvoient une réponse fausse pour des domaines qui n'existent pas, et redirigent les utilisateurs vers une page de recherche. Cette redirection est possible parce que l'ordinateur ou le téléphone font aveuglément confiance au résolveur DNS qui a été annoncé en utilisant DHCP par le routeur de passerelle fourni par le FAI.

• Les pare-feu peuvent facilement intercepter, bloquer ou modifier n'importe quel trafic DNS non chiffré en fonction du seul numéro du port. Il est à noter que l'inspection textuelle n'est pas une solution miracle pour atteindre les objectifs de visibilité, car il est possible de contourner le résolveur DNS.

Le chiffrement des DNS rend beaucoup plus difficile aux pirates informatiques qui surveillent vos messages DNS ou qui les corrompent pendant le transit. Tout comme le Web est passé du HTTP non chiffré au HTTPS chiffré, il existe désormais des mise à niveau du protocole DNS qui chiffre le protocole DNS. Le chiffrement du Web a permis de sécuriser et privatiser les communications et de développer le commerce. Le chiffrement des DNS améliorera encore davantage la confidentialité des utilisateurs.

Il existe deux mécanismes normalisés permettant de sécuriser le transport DNS entre vous et le résolveur : DNS over TLS (2016) et DNS Queries over HTTPS (2018). Les deux sont basés sur le protocole Transport Layer Security (TLS) qui est également utilisé pour sécuriser la communication entre vous et un site Web en utilisant HTTPS. Dans TLS, le serveur (qu'il s'agisse d'un serveur Web ou d'un résolveur DNS) s'authentifie auprès du client (votre périphérique) à l'aide d'un certificat. Ceci garantit que personne d'autre ne puisse se faire passer pour le serveur (le résolveur).

Avec DNS over TLS (DoT), le message DNS original est directement intégré dans le canal TLS sécurisé. De l'extérieur, on ne peut ni savoir quel nom a été demandé, ni le modifier. L'application client prévue sera capable de déchiffrer TLS de la manière suivante :

Dans le suivi des paquets pour les DNS non chiffrés, il était évident qu'une requête DNS pouvait être envoyée directement par le client, suivie d'une réponse DNS du résolveur. Dans le cas du DoT chiffré, cependant, certains messages de handshake TLS sont échangés avant l'envoi de messages DNS chiffrés :

• Le client envoie un Client Hello, annonçant les capacités TLS prises en charge.

• Le serveur répond par un Server Hello, acceptant les paramètres TLS qui seront utilisés pour sécuriser la connexion. Le message Certificate contient l'identité du serveur tandis que le message Certificate Verify contiendra une signature numérique qui peut être vérifiée par le client en utilisant le certificat du serveur. Le client vérifie généralement ce certificat par rapport à sa liste locale d'autorités de certification de confiance, mais la spécification DoT mentionne d'autres mécanismes de confiance alternatifs comme l’épinglage de clé publique.

• Une fois le handshake TLS achevé par le client et le serveur, ces derniers peuvent enfin commencer à échanger des messages chiffrés.

• Bien que l'image ci-dessus contienne une requête et une réponse DNS, dans la pratique, la connexion TLS sécurisée restera ouverte et sera réutilisée pour de futures requêtes DNS.

La sécurisation des protocoles non chiffrés en plaçant TLS sur un nouveau port a déjà été effectuée auparavant :

• Web traffic: HTTP (tcp/80) -> HTTPS (tcp/443)

• Sending email: SMTP (tcp/25) -> SMTPS (tcp/465)

• Receiving email: IMAP (tcp/143) -> IMAPS (tcp/993)

• Now: DNS (tcp/53 or udp/53) -> DoT (tcp/853)

Le problème de l'introduction d'un nouveau port est qu'il peut être bloqué par les pare-feu existants. Soit parce qu'ils ont recours à des listes blanches où les nouveaux services doivent être activés explicitement, soit parce qu'un administrateur réseau bloque explicitement un service. Si la solution sécurisée (DoT) est moins facilement disponible que la solution non sécurisée, les utilisateurs et les applications pourraient être tentés de se rabattre sur les DNS non chiffrés. Cela pourrait par la suite permettre aux attaquants de forcer les utilisateurs à utiliser une version non sécurisée.

Ces attaques de repli ne relèvent pas de la théorie. Le SSL Stripping a déjà été utilisée pour faire passer les sites Web HTTPS en HTTP, en permettant ainsi aux attaquants de voler des mots de passe ou de pirater des comptes.

Une autre solution, DNS Queries over HTTPS (DoH), a été conçue pour répondre à deux cas d'utilisation fréquents :

• Éviter le problème ci-dessus où les dispositifs sur le trajet interfèrent avec les DNS. Cela comprend le problème de blocage des ports décrit ci-dessus.

• Activer les applications Web pour accéder aux DNS via les API de navigateur existantes.DoH est essentiellement HTTPS, le standard chiffré utilisé par le Web, et réutilise le même numéro de port (tcp/443). Les navigateurs Web ont déjà désapprouvé le HTTP non sécurisé en faveur du HTTPS. Cela fait de HTTPS un excellent choix pour transporter les messages DNS en toute sécurité. Vous trouverez un exemple de ce type de requête DoH ici.

DoH : Requête et réponse DNS transportées via un flux HTTPS sécurisé

Certains utilisateurs craignent que l'utilisation de HTTPS ne porte atteinte à leur vie privée en raison de l'utilisation potentielle de cookies de suivi. Les concepteurs du protocole DoH ont tenu compte de divers aspects de la protection de la vie privée et ont explicitement déconseillé l'utilisation de cookies HTTP pour empêcher le suivi, et cette recommandation est largement respectée. La reprise de la session TLS améliore les performances du handshake TLS 1.2, mais peut potentiellement être utilisée pour corréler les connexions TLS. Heureusement, l'utilisation de TLS 1.3 permet d'éviter la reprise d'une session TLS en réduisant le nombre d'allers-retours par défaut, ce qui répond efficacement aux préoccupations en matière de confidentialité.

L'utilisation de HTTPS signifie que les améliorations du protocole HTTP peuvent également bénéficier à DoH. Par exemple, le protocole HTTP/3 en cours de développement, basé sur QUIC, pourrait apporter des améliorations supplémentaires en cas de perte de paquets due à l'absence de blocage en tête de file. Cela signifie que plusieurs requêtes DNS peuvent être envoyées simultanément sur le canal sécurisé sans se bloquer les unes les autres lorsqu'un paquet est perdu.

Un projet de DNS over QUIC (DNS/QUIC) existe également et est semblable à DoT, mais sans le problème de blocage en tête de file dû à l'utilisation de QUIC. Cependant, HTTP/3 et DNS/QUIC exigent tous deux qu'un port UDP soit accessible. En théorie, les deux pourraient basculer vers DoH over HTTP/2 et DoT, respectivement.

Étant donné que DoT et DoH sont relativement nouveaux, ils ne sont pas encore déployés partout. Côté serveur, les principaux résolveurs publics, comme 1.1.1.1 de Cloudflare et Google DNS le prennent en charge. Cependant, de nombreux résolveurs de FAI ne le prennent toujours pas en charge. Une petite liste des résolveurs publics prenant en charge DoH est disponible sur la page DNS server sources et une autre liste des résolveurs publics prenant en charge DoT et DoH est disponible sur DNS Privacy Public Resolvers.

Il existe deux méthodes pour activer DoT ou DoH sur les appareils des utilisateurs finaux :

• Ajouter la prise en charge aux applications, en contournant le service de résolveur du système d'exploitation.

• Ajouter la prise en charge au système d'exploitation, en assurant de manière transparente la prise en charge des applications.

Il existe généralement trois types de configuration pour DoT ou DoH côté client :

• Désactivé : Les DNS ne seront pas chiffrés.

• Mode opportuniste : essayer d'utiliser un transport sécurisé pour les DNS, mais revenir aux DNS non chiffrés si ce dernier n'est pas disponible. Ce mode est vulnérable aux attaques par déclassement qui permettent à un attaquant de forcer un périphérique à utiliser des DNS non chiffrés. Il permet de protéger la confidentialité lorsqu'il n'y a pas d'attaquants actifs sur le chemin.

• Mode strict : essayer d'utiliser les DNS sur un protocole de transport sécurisé. S'il n'est pas disponible, tout est interrompu et l'utilisateur voit une erreur s'afficher.

The current state for system-wide configuration of DNS over a secure transport:

• Android 9: supports DoT through its “Private DNS” feature. Modes:
  • Opportunistic mode (“Automatic”) is used by default. The resolver from network settings (typically DHCP) will be used.
  • Strict mode can be configured by setting an explicit hostname. No IP address is allowed, the hostname is resolved using the default resolver and is also used for validating the certificate. (Relevant source code)
• iOS and Android users can also install the 1.1.1.1 app to enable either DoH or DoT support in strict mode. Internally it uses the VPN programming interfaces to enable interception of unencrypted DNS traffic before it is forwarded over a secure channel.
• Linux with systemd-resolved from systemd 239: DoT through the DNSOverTLS option.
  • Off is the default.
  • Opportunistic mode can be configured, but no certificate validation is performed.
  • Strict mode is available since systemd 243. Any certificate signed by a trusted certificate authority is accepted. However, there is no hostname validation with the GnuTLS backend while the OpenSSL backend expects an IP address.
  • In any case, no Server Name Indication (SNI) is sent. The certificate name is not validated, making a on-path attacker rather trivial.
• Linux, macOS, and Windows can use a DoH client in strict mode. The cloudflared proxy-dns command uses the Cloudflare DNS resolver by default, but users can override it through the proxy-dns-upstream option.

État actuel de la configuration DNS à l'échelle du système sur un protocole de transport sécurisé :

• Android 9 : prend en charge DoT grâce à sa fonction « Private DNS ». Modes :

• Le mode opportuniste (« automatique ») est utilisé par défaut. Le résolveur des paramètres réseau (généralement DHCP) sera utilisé.

• Le mode strict peut être configuré en définissant un nom d'hôte explicite. Aucune adresse IP n'est autorisée, le nom d'hôte est résolu à l'aide du résolveur par défaut et est également utilisé pour valider le certificat. (code source pertinent)

• Les utilisateurs d'iOS et d'Android peuvent également installer l'application 1.1.1.1 pour activer la prise en charge DoH ou DoT en mode strict. Elle utilise en interne les interfaces de programmation VPN pour permettre l'interception du trafic DNS non chiffré avant sa transmission sur un canal sécurisé.

• Linux avec systemd-resolved de systemd 239  DoT par l'option DNSOverTLS.

• Désactivé est la valeur par défaut.

• Le mode opportuniste peut être configuré, mais aucune validation de certificat n'est effectuée.

• Le mode strict est disponible depuis systemd 243. Tout certificat signé par une autorité de certification de confiance est accepté. Cependant, il n'y a pas de validation du nom d'hôte avec le backend GnuTLS alors que le backend OpenSSL attend une adresse IP.

• Dans tous les cas, aucune indication de nom de serveur (SNI) n'est envoyée. Le nom du certificat n'est pas validé, ce qui rend une attaque de l'homme du milieu (HDM) plutôt insignifiante.

• Linux, macOS et Windows peuvent utiliser un client DoH en mode strict. La commande proxy-dns de Cloudflare utilise le résolveur DNS de Cloudflare par défaut, mais les utilisateurs peuvent le remplacer par l’option proxy-dns-upstream.

Les navigateurs Web prennent en charge DoH au lieu de DoT :

• Firefox 62 prend en charge DoH et propose plusieurs paramètres trusted Recursive Resolver (TRR). DoH est désactivé par défaut, mais Mozilla procède actuellement à une expérience visant à activer DoH pour certains utilisateurs aux États-Unis. Cette expérience utilise actuellement le résolveur 1.1.1.1 de Cloudflare, car nous sommes le seul fournisseur qui satisfait actuellement à la politique en matière de résolveurs stricte exigée par Mozilla. Étant donné que de nombreux résolveurs DNS ne prennent toujours pas en charge le transport DNS chiffré, la démarche de Mozilla garantira que davantage d'utilisateurs seront protégés par DoH.

• Lorsqu'il sera activé au cours de l'expérience, ou via l'option « Activer DNS over HTTPS » dans les paramètres réseau, Firefox utilisera le mode opportuniste (network.trr.mode=2 at about:config).

• Il est possible d'activer le mode strict avec network.trr.mode=3, mais nécessite la spécification d’une adresse IP de résolveur explicite (par exemple, network.trr.bootstrapAddress=1.1.1.1).

• Bien que Firefox ignore le résolveur par défaut du système, il peut être configuré avec d'autres résolveurs. En outre, les versions professionnelles qui utilisent un résolveur qui ne prend pas en charge DoH ont la possibilité de désactiver DoH.

• Chrome 78 accepte le DoH opportuniste si l'adresse du résolveur du système correspond à celle de l'un des fournisseurs DoH programmée en dur (changement de code source). Cette expérience est activée sur toutes les plates-formes sauf Linux et iOS, et exclut les versions professionnelles par défaut.

• Opera 65 ajoute une option pour activer DoH via le résolveur 1.1.1.1 de Cloudflare. Cette fonctionnalité est désactivée par défaut. Une fois activée, elle semble utiliser le mode opportuniste : si 1.1.1.1:443 (sans SNI) est accessible, il sera utilisé. Sinon, il revient au résolveur non chiffré par défaut.

La page DNS over HTTPS du projet Curl contient une liste complète des fournisseurs du DoH et des applications supplémentaires.

Comme alternative au chiffrement du chemin réseau complet entre l'appareil et le résolveur DNS externe, il est possible d'opter pour une solution intermédiaire : utiliser un DNS non chiffré entre les appareils et la passerelle du réseau local, mais chiffrer tout le trafic DNS entre le routeur passerelle et le résolveur DNS externe. En se basant sur un réseau filaire ou sans fil sécurisé, cela protégerait tous les appareils du réseau local contre un FAI indiscret, ou d'autres prédateurs sur internet. Dans la mesure où les points d’accès Wi-Fi publics ne sont pas considérés comme sûrs, cette solution ne le serait pas sur les réseaux Wi-Fi publics. Même s'il est protégé par mot de passe avec une clé WPA2-PSK, des intrus pourront toujours s'infiltrer pour modifier les DNS non chiffrés.

Les sections précédentes décrivaient les modes de transport DNS sécurisés DoH et DoT. Ils ne feront que garantir que votre client recevra la réponse non altérée de la part du résolveur DNS. Il ne protège cependant pas le client contre un résolveur qui renvoie la mauvaise réponse (par des attaques par détournement de DNS ou par empoisonnement du cache des DNS). La « vraie » réponse est déterminée par le propriétaire d'un domaine ou d'une zone tel que rapporté par le serveur de nom faisant autorité. DNSSEC permet aux clients de vérifier l'intégrité de la réponse DNS renvoyée et de détecter toute modification non autorisée sur le chemin entre le client et le serveur de noms officiel.

Cependant, le déploiement de DNSSEC est entravé par des dispositifs intermédiaires qui transfèrent incorrectement les messages DNS, et même si les informations sont disponibles, les résolveurs stub utilisés par les applications pourraient même ne pas valider les résultats. Un rapport publié en 2016 a révélé que seuls 26 % des utilisateurs utilisent des résolveurs validant DNSSEC.

DoH et DoT protègent le transport entre le client et le résolveur public. Il se peut que le résolveur public doive faire appel à d'autres serveurs de noms reconnus pour résoudre un nom. Traditionnellement, le chemin d'accès entre tout résolveur et le serveur de noms officiel utilise des DNS non chiffrés. Pour protéger également ces messages DNS, nous avons fait une expérience avec Facebook, en utilisant DoT entre 1.1.1.1 et les serveurs de noms faisant autorité de Facebook. Bien que la mise en place d'un canal sécurisé à l'aide de TLS augmente la latence, elle peut être amortie sur de nombreuses requêtes.

Le chiffrement du transport permet de protéger les résultats du résolveur et les métadonnées. Par exemple, les informations EDNS Client Subnet (ECS) comprises dans les requêtes DNS pourraient révéler l'adresse originale du client qui a lancé la requête DNS. Le fait de cacher ces renseignements tout au long du chemin améliore la confidentialité. Cela permet également d'éviter que des dispositifs intermédiaires défaillants ne perturbent le DNSSEC en raison de problèmes de transfert DNS.

Le chiffrement des DNS peut représenter un problème pour les personnes ou les entreprises qui sont tributaires de la surveillance ou de la modification du trafic DNS. Les dispositifs de sécurité utilisant la surveillance passive surveillent tout le trafic réseau entrant et sortant sur une machine ou sur la périphérie d'un réseau. À partir de requêtes DNS non chiffrées, ils peuvent par exemple identifier des machines infectées par des logiciels malveillants. Si la requête DNS est chiffrée, les solutions de surveillance passive ne pourront pas surveiller les noms de domaine.

Certains s'attendent à ce que les résolveurs DNS appliquent le filtrage de contenu dans les buts suivants :

• Bloquer les domaines utilisés pour diffuser des logiciels malveillants.

• Bloquer les publicités.

• Effectuer un filtrage pour le contrôle parental, en bloquant les domaines proposant du contenu pour adultes.

• Bloquer l'accès aux domaines diffusant des contenus illégaux selon la réglementation locale.

• Proposer un service DNS avec découpage d’horizon pour donner des réponses différentes selon le réseau source.

L'avantage de bloquer l'accès aux domaines via le résolveur DNS est que cela peut être fait de manière centralisée, sans avoir à le refaire dans chaque application. Malheureusement, ce stratagème est également assez approximatif. Imaginons qu'un site Web héberge du contenu destiné à plusieurs utilisateurs sur exemple.com/videos/pour-enfants/ et exemple.com/videos/pour-adultes/. Le résolveur DNS ne pourra voir qu’« exemple.com » et pourra choisir de le bloquer ou non. Dans ce cas, les commandes spécifiques à l'application, telles que les extensions de navigateur, seraient plus efficaces puisqu'elles peuvent en fait examiner les URL et opérer une sélection parmi les contenus pour empêcher ou non l'accès à ces derniers.

La surveillance DNS n'est pas exhaustive. Les logiciels malveillants peuvent ignorer les DNS et coder en dur les adresses IP, ou utiliser d'autres méthodes pour interroger une adresse IP. Cependant, tous les logiciels malveillants ne sont pas nécessairement complexes, de sorte que la surveillance DNS peut toujours servir d'outil de défense en profondeur.

Tous ces cas d'utilisation de surveillance non passive ou de blocage DNS nécessitent l'aide du résolveur DNS. Les configurations qui se basent sur des mises à jour DoH/DoT opportunistes du résolveur actuel conserveront les mêmes fonctionnalités que celles habituellement assurées par les DNS non chiffrés. Malheureusement, cette approche est vulnérable aux attaques par déclassement, comme nous l'avons déjà indiqué. Pour résoudre ce problème, les administrateurs système peuvent diriger les points de terminaison vers un résolveur DoH/DoT en mode strict. Idéalement, cela se fait par le biais de solutions de gestion des périphériques sécurisés (MDM, stratégie de groupe sur Windows, etc.).

L'une des pierres angulaires d'Internet est le mappage des noms vers une adresse en utilisant les DNS. Les DNS utilisent depuis toujours des modes de transport non chiffrés et non sécurisés. Des FAI s'en sont déjà servis à mauvais escient dans le passé pour diffuser de la publicité, mais cela a aussi entraîné des fuites de données personnelles. Les clients d'un cybercafé indiscrets peuvent utiliser des DNS non chiffrés pour surveiller vos activités. Il est possible de résoudre tous ces problèmes en utilisant DNS over TLS (DoT) ou DNS over HTTPS (DoH). Ces techniques de protection de l'utilisateur sont relativement nouvelles et sont de plus en plus répandues.

D'un point de vue technique, DoH est très similaire à HTTPS et suit la tendance générale du secteur qui est de désavouer les solutions non sécurisées. DoT est un mode de transport plus simple que DoH dans la mesure où la couche HTTP est supprimée, mais cela facilite également le blocage, volontaire ou accidentel.

Le choix d'un résolveur DNS vient en complément de l'activation d'un mode de transport sécurisé. Certains prestataires utilisent un résolveur DNS configuré localement, mais tentent de remplacer de manière opportuniste le protocole de transport non chiffré par un protocole plus sécurisé (DoT ou DoH). Malheureusement, le résolveur DNS est généralement par défaut celui fourni par le FAI, qui ne prend pas nécessairement en charge les modes de transport sécurisés.

Mozilla a adopté une approche différente. Plutôt que de compter sur des résolveurs locaux qui ne prennent même pas en charge DoH, ils permettent à l'utilisateur de sélectionner explicitement un résolveur. Les résolveurs recommandés par Mozilla doivent satisfaire à des normes élevées de protection de la vie privée des utilisateurs. Afin de garantir que les fonctions de contrôle parental basées sur les DNS restent fonctionnelles et de prendre en charge le cas d’utilisation du découpage d’horizon, Mozilla a ajouté un mécanisme permettant aux résolveurs privés de désactiver DoH.

Les protocoles de transport DoT et DoH vont pouvoir nous permettre de passer à un Internet plus sûr. Comme on peut le voir dans les suivis de paquets précédents, ces protocoles sont similaires aux mécanismes existants pour sécuriser le trafic des applications. Une fois cette faille de sécurité et de protection de la vie privée colmatée, il en restera encore beaucoup d'autres.