Suivant société Google sur l'intention de mener une expérience pour tester l'implémentation « DNS over HTTPS » (DoH, DNS over HTTPS) en cours de développement pour le navigateur Chrome. Chrome 78, prévu pour le 22 octobre, aura certaines catégories d'utilisateurs par défaut utiliser DoH. Seuls les utilisateurs dont les paramètres système actuels spécifient certains fournisseurs DNS reconnus comme compatibles avec DoH participeront à l'expérience pour activer DoH.
La liste blanche des fournisseurs DNS comprend Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), OpenDNS (208.67.222.222, 208.67.220.220), Quad9 (9.9.9.9, 149.112.112.112), Cleanbrowsing (185.228.168.168. 185.228.169.168, 185.222.222.222) et DNS.SB (185.184.222.222, XNUMX). Si les paramètres DNS de l'utilisateur spécifient l'un des serveurs DNS mentionnés ci-dessus, DoH dans Chrome sera activé par défaut. Pour ceux qui utilisent les serveurs DNS fournis par leur fournisseur Internet local, tout restera inchangé et le résolveur système continuera à être utilisé pour les requêtes DNS.
Une différence importante avec l'implémentation de DoH dans Firefox, qui activait progressivement DoH par défaut déjà à la fin du mois de septembre, il y a un manque de liaison avec un service du DoH. Si dans Firefox par défaut Serveur DNS CloudFlare, alors Chrome mettra à jour uniquement la méthode de travail avec DNS vers un service équivalent, sans changer de fournisseur DNS. Par exemple, si l'utilisateur a spécifié DNS 8.8.8.8 dans les paramètres système, Chrome Service Google DoH (« https://dns.google.com/dns-query »), si DNS est 1.1.1.1, alors service Cloudflare DoH (« https://cloudflare-dns.com/dns-query ») Et
S'il le souhaite, l'utilisateur peut activer ou désactiver DoH à l'aide du paramètre « chrome://flags/#dns-over-https ». Trois modes de fonctionnement sont pris en charge : sécurisé, automatique et désactivé. En mode « sécurisé », les hôtes sont déterminés uniquement sur la base des valeurs sécurisées précédemment mises en cache (reçues via une connexion sécurisée) et des requêtes via DoH ; le repli vers le DNS standard n'est pas appliqué. En mode « automatique », si DoH et le cache sécurisé ne sont pas disponibles, les données peuvent être récupérées du cache non sécurisé et accessibles via le DNS traditionnel. En mode « off », le cache partagé est d'abord vérifié et s'il n'y a pas de données, la requête est envoyée via le DNS du système. Le mode est réglé via kDnsOverHttpsMode et le modèle de mappage de serveur via kDnsOverHttpsTemplates.
L'expérience visant à activer DoH sera menée sur toutes les plates-formes prises en charge dans Chrome, à l'exception de Linux et iOS en raison de la nature non triviale de l'analyse des paramètres du résolveur et de la restriction de l'accès aux paramètres DNS du système. Si, après avoir activé DoH, il y a des problèmes pour envoyer des requêtes au serveur DoH (par exemple, en raison de son blocage, de sa connectivité réseau ou de son échec), le navigateur renverra automatiquement les paramètres DNS du système.
Le but de l'expérience est de tester définitivement l'implémentation de DoH et d'étudier l'impact de l'utilisation de DoH sur les performances. Il convient de noter qu'en réalité, le soutien du DoH a été dans la base de code Chrome en février, mais pour configurer et activer DoH lancer Chrome avec un indicateur spécial et un ensemble d'options non évidents.
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.
Source: opennet.ru