Développeurs Firefox
Après avoir activé DoH, un avertissement s'affiche à l'utilisateur, qui permet, s'il le souhaite, de refuser de contacter les serveurs DNS centralisés de DoH et de revenir au schéma traditionnel d'envoi de requêtes non cryptées au serveur DNS du fournisseur. Au lieu d'une infrastructure distribuée de résolveurs DNS, DoH utilise une liaison à un service DoH spécifique, qui peut être considéré comme un point de défaillance unique. Actuellement, le travail est proposé via deux fournisseurs DNS : CloudFlare (par défaut) et
Changer de fournisseur ou désactiver DoH
Rappelons que DoH peut être utile pour empêcher les fuites d'informations sur les noms d'hôtes demandés via les serveurs DNS des fournisseurs, lutter contre les attaques MITM et l'usurpation du trafic DNS (par exemple, lors de la connexion au Wi-Fi public), contrer le blocage au niveau du DNS. (Le DoH ne peut pas remplacer un VPN dans le domaine du contournement des blocages mis en œuvre au niveau DPI) ou pour organiser le travail s'il est impossible d'accéder directement aux serveurs DNS (par exemple, lorsque l'on travaille via un proxy). Si dans une situation normale les requêtes DNS sont directement envoyées aux serveurs DNS définis dans la configuration du système, alors dans le cas de DoH, la requête pour déterminer l'adresse IP de l'hôte est encapsulée dans le trafic HTTPS et envoyée au serveur HTTP, où le résolveur traite requêtes via l’API Web. La norme DNSSEC existante utilise le cryptage uniquement pour authentifier le client et le serveur, mais ne protège pas le trafic contre l'interception et ne garantit pas la confidentialité des demandes.
Pour sélectionner les fournisseurs DoH proposés dans Firefox,
DoH doit être utilisé avec prudence. Par exemple, en Fédération de Russie, les adresses IP 104.16.248.249 et 104.16.249.249 associées au serveur DoH par défaut mozilla.cloudflare-dns.com proposé dans Firefox,
DoH peut également causer des problèmes dans des domaines tels que les systèmes de contrôle parental, l'accès aux espaces de noms internes dans les systèmes d'entreprise, la sélection d'itinéraires dans les systèmes d'optimisation de la diffusion de contenu et le respect des ordonnances des tribunaux dans le domaine de la lutte contre la distribution de contenus illégaux et l'exploitation de mineurs. Pour contourner de tels problèmes, un système de contrôle a été mis en œuvre et testé qui désactive automatiquement DoH dans certaines conditions.
Pour identifier les résolveurs d'entreprise, les domaines de premier niveau (TLD) atypiques sont vérifiés et le résolveur système renvoie les adresses intranet. 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, on considère que le blocage du contenu pour adultes est actif au niveau DNS. Les adresses IP de Google et YouTube sont également vérifiées en tant que signes pour voir si elles ont été remplacées par restrict.youtube.com, forcesafesearch.google.com et restrictmoderate.youtube.com. Ces vérifications permettent aux attaquants qui contrôlent le fonctionnement du résolveur ou sont capables d'interférer avec le trafic de simuler un tel comportement pour désactiver le cryptage du trafic DNS.
Travailler via un seul service DoH peut également potentiellement entraîner des problèmes d'optimisation du trafic dans les réseaux de diffusion de contenu qui équilibrent le trafic à l'aide du DNS (le serveur DNS du réseau CDN génère une réponse en tenant compte de l'adresse du résolveur et fournit 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 dans de tels CDN renvoie l'adresse de l'hôte le plus proche de l'utilisateur, mais l'envoi d'une requête DNS depuis un résolveur centralisé renverra l'adresse de l'hôte la plus proche du serveur DNS sur HTTPS. . Les tests pratiques ont montré que l'utilisation du DNS sur HTTP lors de l'utilisation d'un CDN n'entraînait pratiquement aucun délai avant le début du transfert de contenu (pour les connexions rapides, les délais ne dépassaient pas 10 millisecondes, et des performances encore plus rapides étaient observées sur les canaux de communication lents. ). L’utilisation de l’extension EDNS Client Subnet a également été envisagée pour fournir des informations sur l’emplacement du client au résolveur CDN.
Source: opennet.ru