Les développeurs de Firefox ont annoncé l'achèvement des tests de support DNS sur HTTPS (DoH) ainsi que l'intention fin septembre de permettre à cette technologie par défaut pour les utilisateurs de Firefox aux États-Unis.
L'inclusion se fera progressivement puisqu'au départ il n'y aura que quelques utilisateurs, après cela, en l'absence de problèmes, elle augmentera progressivement jusqu'à ce que 100% des utilisateurs aux Etats-Unis disposent de cette fonctionnalité. Mais ce n'est pas unique à la région comme après avoir terminé la couverture américaine. la mise en œuvre dans d'autres pays sera également envisagée.
Les tests réalisés au cours de l'année ont montré la fiabilité et les bonnes performances du service et ils ont également révélé certaines situations dans lesquelles DoH peut générer des problèmes et développer des solutions pour les contourner (par exemple, des problèmes d'optimisation du trafic dans les réseaux de diffusion de contenu, le contrôle parental et le contrôle interne de l'entreprise).
L'importance du chiffrement du trafic DNS est évaluée comme un facteur fondamentalement important dans la protection des utilisateurs, il a donc été décidé d'activer DoH par défaut, mais dans un premier temps uniquement pour les utilisateurs américains.
Après l'activation de DoH, un avertissement sera émis à l'utilisateur, ce qui vous permettra de refuser de contacter les serveurs DNS DoH centralisés et de revenir au schéma traditionnel d'envoi de requêtes non chiffrées au serveur DNS du fournisseur (au lieu de l'infrastructure distribuée des résolveurs DNS, DoH utilise la liaison à un service DoH qui peut être considéré comme un point de défaillance unique).
Lorsque DoH est activé, les systèmes de contrôle parental et les réseaux d'entreprise peuvent être affectés, en utilisant la structure de nom DNS disponible uniquement pour le réseau interne pour traduire les adresses intranet et les hôtes d'entreprise.
Pour résoudre les problèmes avec des systèmes similaires, un système de vérification a été ajouté qui désactive automatiquement DoH. Des vérifications sont effectuées à chaque démarrage du navigateur ou lorsqu'une modification du sous-réseau est détectée.
Un retour automatique à l'utilisation d'un solveur standard est également fourni du système d'exploitation en cas de pannes lors de la résolution via DoH (par exemple, s'il y a violation de la disponibilité du réseau avec le fournisseur DoH ou s'il y a des pannes dans son infrastructure).
La signification de ces vérifications est douteuse, puisque personne n'interfère avec les attaquants qui contrôlent le résolveur ou ne peut interférer avec le trafic, ils simulent ce comportement pour désactiver le cryptage du trafic DNS.
Le problème a été résolu en ajoutant l'élément "DoH always" à la configuration (par défaut il n'est pas actif), lorsqu'il est configuré, l'arrêt automatique n'est pas appliqué, ce qui est un compromis raisonnable.
Pour déterminer les solveurs d'entreprise, des vérifications des domaines de premier niveau (TLD) aberrants et le retour des adresses intranet par le solveur de système sont effectués.
Pour déterminer si le contrôle parental est activé, une tentative est faite pour résoudre le nom exampleadultsite.com et si le résultat ne correspond pas à l'adresse IP réelle, le contenu réservé aux adultes est considéré comme bloqué au niveau DNS.
Travaillez avec un seul service DoH cela peut également entraîner des problèmes d'optimisation du trafic sur les réseaux de distribution de contenu qui équilibrent le trafic à l'aide du DNS (le serveur DNS du CDN génère une réponse basée sur l'adresse du résolveur et diffuse l'hôte le plus proche pour recevoir le contenu).
L'envoi d'une requête DNS depuis le résolveur le plus proche de l'utilisateur sur ces CDN renverra l'adresse de l'hôte le plus proche de l'utilisateur, mais l'envoi d'une requête DNS depuis le résolveur central renverra l'adresse de l'hôte le plus proche du serveur DNS via HTTPS.
Des tests pratiques ont montré que l'utilisation de DNS sur HTTP lors de l'utilisation de CDN n'entraînait pratiquement aucun retard avant le transfert de contenu (pour les connexions rapides, les retards ne dépassaient pas 10 millisecondes et un fonctionnement encore plus lent était observé dans les canaux de communication lents).
source: https://blog.mozilla.org/