DNS over HTTPS (DoH) arrive dans les paramètres réseau de Windows 10 : comment ça marche ?
Avec des adresses IP
Notre dossier sur DNS over HTTPS :
Le 06 août 2020 à 15h45
4 min
Logiciel
Logiciel
Après les navigateurs, les OS ! Windows 10 sera-t-il le premier à supporter nativement DNS over HTTPS ? Cela semble bien être le cas puisque l'on peut désormais tester son intégration, passant désormais par les paramètres réseau.
DNS over HTTPS (DoH) est une nouvelle manière d'échanger avec un résolveur DNS. Très simple à mettre en œuvre et difficile à bloquer, il a l'avantage de passer par un flux chiffré. Des points forts qui expliquent sans doute son succès face à d'autres candidats visant le même objectif, comme DNS over TLS (DoT) par exemple.
Jusqu'à maintenant, son intégration était pratiquée au niveau des navigateurs. On peut en effet en profiter sous Firefox, mais aussi dans les versions de test de ceux dérivés de Chromium. Un choix qui pose problème puisque cela revient à accepter que chaque application dispose de ses propres paramètres pour les DNS, outrepassant les règles du système.
- Qu'est-ce que DNS over HTTPS (DoH), qu'est-ce que cela peut vous apporter ?
- DNS over HTTPS (DoH) : au-delà de Firefox, une « question de confiance »
- DNS over HTTPS : pour Stéphane Bortzmeyer, « le diable est dans les détails »
- DNS over HTTPS (DoH) arrive dans Windows 10 : comment ça marche ?
- Comment activer DNS over HTTPS (DoH) ? (à venir)
Une situation qui peut être tolérée à court terme, mais qui ne doit pas durer. Si DNS over HTTPS est une évolution intéressante, son intégration doit plutôt se faire au niveau des routeurs, box de FAI et autres systèmes d'exploitation. Microsoft avait justement promis une évolution rapide de Windows 10 sur ce point. Elle évolue dans sa phase de test.
DoH va intégrer les paramètres réseau
Bonne nouvelle, contrairement à ce qui se pratique en général sous Linux, vous n'aurez pas d'outil spécial tel que Stubby à installer pour profiter de DNS over HTTPS sous Windows 10. Pour autant Microsoft n'est pas franchement le premier à s'intéresser aux DNS chiffrés intégrés à un OS, puisqu'Android supporte DoT depuis sa version 9 (Pie) sortie en 2018.
Depuis la précédente build 19628, qui avait ouvert la phase de test, l'activation était possible mais nécessitait une procédure complexe. Ce n'est plus le cas avec la build 20185 qui vient d'être publiée. Elle est disponible via le programme Insider ou à télécharger manuellement. Nous avons opté pour cette seconde solution.
Rendez-vous ensuite dans la section Réseau/Wi-Fi des Paramètres (Windows + i). Vous verrez vos différentes connexions, avec la possibilité d'ouvrir leurs propriétés. Dans celles-ci, une section est désormais consacrée aux DNS. Par défaut, ils seront réglés de manière automatique, via le protocole DHCP (c'est le routeur qui les fournit au système).
Optez pour manuel, en IPv4 et/ou IPv6. Si vous indiquez une adresse IP connue pour supporter DNS over HTTPS, l'option de chiffrement sera débloquée. Vous pourrez alors demander à l'utiliser obligatoirement, le désactiver ou indiquer qu'il doit être utilisé en priorité, mais qu'il est possible d'opter pour du trafic DNS non chiffré en cas de problème.
Une fois activé, les DNS manuels apparaîtront dans les propriétés de la connexion, ainsi que le choix de chiffrement effectué
Trois sont reconnus pour le moment :
Cloudflare :
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
- 8.8.8.8
- 8.8.4.4
- 2001:4860:4860::8888
- 2001:4860:4860::8844
Quad9
- 9.9.9.9
- 149.112.112.112
- 2620:fe::fe
- 2620:fe::fe:9
La façon de faire est maligne, mais on espère tout de même que l'on aura droit à une intégration plus ouverte dans la version définitive. Surtout que certains services DoH ne communiquent que leur URL et pas une adresse IP.
Ajoutez le serveur DoH de votre choix :
Il devrait être possible d'ajouter le résolveur de votre choix via cette commande PowerShell (Administrateur), mais selon nos essais, elle n'est pour le moment pas fonctionnelle.
netsh dns add encryption server=IP dohtemplate=URL
Vous pouvez vérifier l'URL du serveur DoH correspondant à l'IP de votre choix :
netsh dns show encryption server=IP
Vérifier que DoH est bien actif
Malheureusement, il n'est pas simple de vérifier que DoH est actif. Microsoft donne sa propre astuce, en utilisant l'analyseur de paquets intégré à Windows 10, accessible via PowerShell (ADministrateur). Il permet de visualiser les flux passant en clair via le port 53 (utilisé habituellement par les DNS). Si plus rien n'est visible, c'est que DoH est bien actif :
pktmon filter remove
pktmon filter add -p 53
pktmon start --etw -m real-time
Selon nos premiers essais, cela fonctionne à quelques exceptions près. Par exemple si vous effectuez des requêtes via nslookup
, cela continuera de passer par une requête DNS classique par exemple.
DNS over HTTPS (DoH) arrive dans les paramètres réseau de Windows 10 : comment ça marche ?
-
DoH va intégrer les paramètres réseau
-
Ajoutez le serveur DoH de votre choix :
-
Vérifier que DoH est bien actif
Commentaires (56)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 14/05/2020 à 14h11
Tuto éclair : Sous Android 9 et +, tu cherches “dns” dans les paramètres, tu y choisi la 3e option et tu files le domaine de ton résolveur DoT dans le champ en dessous :)
(Pub, voir capture ici :https://www.shaftinc.fr/chiffrement-dns-pratique.html )
Le 14/05/2020 à 14h49
Le 14/05/2020 à 14h55
Y’a même un lien déjà dans le papier " />
Le 14/05/2020 à 15h05
C’est ce que je fais sous OPNsense. J’ai DNSCrypt-Proxy qui fait le travail de façon très simple.
Le 14/05/2020 à 15h40
Le 14/05/2020 à 15h40
kgersen a écrit :
De toute y’a forcement un problème de ‘poule & œuf’ donc un client DoH soit utilise des IPs en dur (comme celui de Windows) soit utilise le DNS classique. Firefox utilise le DNS classique mais a une option pour spécifier en dur l’IP de l’uri ( network.trr.bootstrapAddress ) si on n’a pas confiance dans son résolveur DNS local.
Ou bien utiliser la base locale (/etc/hosts sur Unix).
Le 14/05/2020 à 15h41
Le 14/05/2020 à 15h43
Le 14/05/2020 à 16h22
Si je passe par un DNS local, qui lui même se base sur un dns externe tout ce qui n’est pas dans mon réseau local, comment faire pour utiliser doh ?
Je n’ai pas trouvé beaucoup de doc à ce sujet, mais ça à l’air assez lourd on dirait car ça nécessite d’avoir un serveur web et donc d’avoir un service qui tourne sur le 443. En soit ça parait logique car on doit passer par du htpps, mais entre avoir un dns en clair et un serveur exposé, bof.
Le 14/05/2020 à 16h58
Article intéressant. Pour info, Debian supporte DoH.
Le 14/05/2020 à 17h03
Tu utilises du DNS normal sur ton réseau local (comme maintenant), et tu configures ton résolveur récursif pour utiliser DoH pour les adresses non locales.
Le 14/05/2020 à 18h37
Je parlais du cas où la box irait faire ses requêtes externes via DoH ;)
Le 14/05/2020 à 18h44
Via dnscrypt-proxy (ou autre) tu veux dire ?
Le 14/05/2020 à 19h02
Oui, dnscrypt-proxy est dans Debian stable et peut (entre autres) utiliser DoH. Il est donc tout à fait possible d’avoir une machine qui utilise DoH.
Le 14/05/2020 à 19h23
Tout ceci va être sympa avec l’usage grandissant de NAT64 + DNS64 qui est utilisé notamment sur les réseaux mobiles (orange et bouygues)
Si le DoH m’envoie une IPv4 alors que je suis derrière un NAT64 ça ne marchera pas.
il va falloir que les navigateurs implémentent un mécanisme de détection, certains le font déjà pour corriger les certificats par IPv4 et les URL en IPv4 littérales comme safari sur IOS.
La même correction est à faire pour le contrôle de la signature DNSSEC mais ici également du retour DoH.
Un moyen est que le navigateur résolve un enregistrement DNS (hors DoH) qui n’existe qu’en IPv4, s’il voit une réponse en IPv6 alors il est derrière un NAT64 et va prendre le préfixe /96 IPv6 pour y ajouter ensuite les 32 bits IPv4 que donnerait la réponse DoH d’un site IPv4 only
Par exemple je veux accéder à impact hardware depuis Firefox Android ou IOS sur le réseau orange,
DoH me renvoie A IPv4 51.159.27.198le navigateur ne pourra pas joindre cette IP nativement, sous android le support de 464xlat va corriger le problème
sur IOS webkit le fait mais plus ou moins loin selon qu’on se trouve dans safari ou ailleurs.
Mais y’a pas que les web browsers dans la vie…
L’idéal étant que le navigateur ait pleine conscience de cela, par exemple en testant un truc du genre ipv4.mozilla.org, ha tiens, j’ai un retour 64:ff9b::IPv4enHexa plutot que mon IPv4, je prends donc ça en compte dans l’ensemble de mes mécanismes.
là le navigateur prendra donc la réponse DoH de impact hardware et ajoutera le préfixe, ce qui donne 64:ff9b::51.159.27.198 finalement 64:ff9b::339f:1bc6 en IPv6
pour ceux qui veulent voir s’ils sont derrière un NAT64 voir ici lafibre.info
Le 14/05/2020 à 19h42
Oui, comme pour tout système du coup ;) Ici on parle de support natif à l’os
Le 14/05/2020 à 08h20
Des infos sur une arrivée de DoH (ou DoT) sur les grandes distribution ou sur MacOS ou iOS.
Un petit dossier sur la configuration dans Android ??
Merci " />
Le 14/05/2020 à 09h00
Dans l’idéal il faudrait aussi que l’on puisse chosir si on veut utiliser
DoH ou non pour un même résolveur DNS, mais DoH par défaut est préférable à pas de DoH ;) …
c’est, AUSSI, mon avis, mais bon… !
Le 14/05/2020 à 09h14
Ben oui j’ai pas compris là ? Comment résoudre l’IP du DoH si on a qu’une adresse http ?
Le 14/05/2020 à 09h19
Y a-t-il des résolveurs français ou européens qui supportent ou ont annoncé un futur support de DOH ?
Le 14/05/2020 à 09h24
Une question que je me suis toujours posé : puisque DoH repose sur une URL, comment fait-il pour résoudre cette URL, s’il n’a pas de service DNS ? Il utilise le DNS classique ?
Le 14/05/2020 à 09h54
oui. en fait la norme DoH ne précise pas comment résoudre les URI (urls) des serveurs DoH. C’est considéré ‘en dehors de la norme’.
Apres vu que ces urls sont en général en HTTPS… utiliser une résolution DNS classique est ce qu’il y a de plus simple (la partie chiffré d’HTTPS vérifiant l’identité du serveur).
De toute y’a forcement un problème de ‘poule & œuf’ donc un client DoH soit utilise des IPs en dur (comme celui de Windows) soit utilise le DNS classique. Firefox utilise le DNS classique mais a une option pour spécifier en dur l’IP de l’uri ( network.trr.bootstrapAddress ) si on n’a pas confiance dans son résolveur DNS local.
Le 14/05/2020 à 10h39
Le 14/05/2020 à 10h51
Donc faut pas que ce soit actif par défaut, mais si ça l’est pas ce sera pas activé " /> J’espère qu’on trouvera quand même de meilleures idées ;)
Le 14/05/2020 à 11h32
Si le DoH n’est pas possible en utilisant un serveur chez notre FAI, est-ce parce qu’ils ont la flemme et ne l’ont pas activé ? Ou bien parce que coté OS (windows), il manque une brique pour pouvoir l’utiliser/activer simplement ?
Le 14/05/2020 à 11h49
Le 14/05/2020 à 11h52
Le 14/05/2020 à 14h01
C’est un problème déjà présent avec certaines méthode d’authentification de DoT.
Dans ces cas là, pas de solutions magiques : faire passer des méta-requêtes en clair via un résolveur classique
Ceci dit, même dans le cadre de DoH (comme pour DoT), il est envisageable d’avoir un client prenant un URL avec un nom de domaine comme autorité et donner en plus l’IP pour ne pas à avoir de méta-requêtes à faire. C’est le cas de Firefox en mode DoH strict (network.uri.mode à 3 avant la version 74, ça a changé depuis, mais il est tout de même possible de filer une IP en bootstrap via network.trr.bootstrapAddress)
Notons enfin qu’il est bien évidement possible de filer un URL avec une IP en lieu et place du nom de domaine mais le certificat en face devra contenir cette IP (j’ai cru comprendre que ce sera bientôt possible chez Let’s Encrypt d’avoir un certif’ pour une IP)
Le 14/05/2020 à 14h03
DoT par défaut est préférable à DoH par défaut :P
Le 14/05/2020 à 14h04
DoT, ça rime avec passé " />
Le 14/05/2020 à 14h07
Le turfu est sclérosé " />
Le 14/05/2020 à 14h08
network.trr.mode et pas network.uri.mode :)
Le 07/08/2020 à 09h49
Hmm ca m’a toujours fait bizarre cette histoire.
Les arguments avancés sont la protection de l’utilisateur (même pas du citoyen), je cite (Wiki) “des écoutes clandestines et la manipulation des données DNS par des attaques de type man-in-the-middle.”. Bon… En gros on fait des tuyaux plus solides.
Des critiques on été levées sur plusieurs thématiques: Le contrôle parental, les temps de réponse, “hop-to-hop” système et non “end-to-end”, etc.
Mais pour moi le problème n’est pas le tuyau mais ce qu’il y a au bout.
Il y a des questions a se poser:
La remarque de Comcast sur le sujet n’est pas dénué de sens. Le problème reste bien QUI est au bout du tuyau et qui pourra exploiter les données.
infos:
Le 14/05/2020 à 06h40
Merci pour cet article. Très bonne compilation concise et exhaustive en un seul article pour faire les tests.
Le 14/05/2020 à 06h50
Mon genre d’article préféré :) Merci !
Le 14/05/2020 à 07h41
Le 14/05/2020 à 07h54
J’espère que ca ne sera pas activé nativement quand même. Sinon on va tous se retrouver par défaut sur les DNS de Cloudflare, ou Google….
Même si changer de DNS est très simple et que l’on n’est pas forcément d’accord avec la loi, le filtrage fait par les DNS de nos FAI n’apporte pas que des blocages inutiles.
Le 14/05/2020 à 08h00
Oui, c’est top, un bon compromis news / explication / technique
Le 14/05/2020 à 08h00
Le 14/05/2020 à 08h03
La réaction typique du sujet : elle est épidermique et ne correspond à rien de concret. Mais on répète vaguement la même chose dès qu’on lit DoH sans chercher à comprendre ce qui est réellement reproché.
Pour résumer (mais bon on a déjà détaillé ça pas mal dans le dossier) : l’implémentation dans les navigateurs est un souci puisque ça bypasse le système et ses réglages. Le fait de ne supporter que quelques services US est un premier souci, celui d’en forcer un par défaut en serait un autre).
Mais ici c’est l’utilisateur qui décide de modifier ses DNS dans l’implémentation actuelle, DoH est juste privilégié au DNS classique quand disponible et activé. Dans l’idéal il faudrait aussi que l’on puisse chosir si on veut utiliser DoH ou non pour un même résolveur DNS, mais DoH par défaut est préférable à pas de DoH ;)
On peut ajouter les serveurs de son choix, il n’y a rien d’activé ou de sélectionné par défaut. Tant que cela reste comme ça, il n’y a rien à redire (si ce n’est que ça pourrait être plus simple).
Le 14/05/2020 à 21h11
Oui, si natif ça veut dire activé par défaut, c’est pas le cas sous Debian. Il faut installer un paquet et configurer la résolution de noms pour l’utiliser.
Mais du coup on peut imaginer que ça ne sera jamais “natif”, vu que faire par défaut la résolution localement casserait certains usages. Choisir comment fonctionne la résolution des noms de domaine est un fonctionnalité importante sur un OS polyvalent.
Le 15/05/2020 à 09h44
Merci pour l’info. Je vais voir pour mettre à jour dsncrypt-proxy et activer DoH sur le routeur.
Le 15/05/2020 à 09h55
Ce que j’entends par “natif”, c’est le fait de pouvoir modifier les résolveurs DNS utilisés par l’OS dans les paramètres sans avoir à ajouter de paquet (ou de serveur/proxy) sur ce dernier. Donc dans le cas des distributions Linux, de modifier les outils qui gèrent ces paramètres pour les adapter à DoH/DoT.
Le 15/05/2020 à 10h26
Le 15/05/2020 à 12h31
Deux choses m’interpellent :
Le 15/05/2020 à 13h33
Le 15/05/2020 à 13h37
Le 16/05/2020 à 08h45
Tu peux utiliser DoT si tu préfères ;)
Le 16/05/2020 à 14h12
> La façon de faire est maligne, mais on espère tout de même que l’on aura droit à une meilleure intégration dans la version définitive
Malin ? 😨
J’aurais préfère :
“La façon de faire est un vilain contournement de base et viole le standard mais elle représente juste la difficulté qu’a MS à gérer son propre OS.”
Le 16/05/2020 à 19h12
Je ne connais pas l’intention de David pour le choix de “malin”, mais, pour ma part, je l’ai compris dans le sens “qui montre de la malveillance” (ref: Larousse), ici rapporté au fait que Microsoft fait ce qui l’arrange au total détriment de l’utilisateur.
Certes, ce n’est pas le sens le plus commun (sauf probablement dans le champ lexical de la santé) mais je n’ai pas été plus choqué que ça à la lecture " />
Le 17/05/2020 à 05h36
En passant par un VPN payant … les appels vers les DNS ne sont-ils pas chiffrés (je me trompe ?)
Question : il me semble implicite dans vos échanges que les serveurs DNS ne supportent pas les connections chiffrées par défaut. Est-ce bien cela car je ne vois pas d’obstacle à ce qu’ils le supporte !
Remarque : pour sécuriser un échange il faut multiplier les intermédiaires car c’est un moyen de ne révéler qu’une partie des informations à chacun d’eux.
Le 17/05/2020 à 15h06
Le 06/08/2020 à 18h35
Le 06/08/2020 à 19h45
Il y a un draft IETF:
https://tools.ietf.org/html/draft-btw-add-home-07
Le 07/08/2020 à 00h24
Le 07/08/2020 à 07h34