DNS over HTTPS (DoH) arrive dans les paramètres réseau de Windows 10 : comment ça marche ?

DNS over HTTPS (DoH) arrive dans les paramètres réseau de Windows 10 : comment ça marche ?

Avec des adresses IP

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

06/08/2020 4 minutes
56

DNS over HTTPS (DoH) arrive dans les paramètres réseau de Windows 10 : comment ça marche ?

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.

Notre dossier sur DNS over HTTPS :

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.

DNS over HTTPS DoH Windows 10DNS over HTTPS DoH Windows 10
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

Google

  • 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. 

56

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

DoH va intégrer les paramètres réseau

Ajoutez le serveur DoH de votre choix :

Vérifier que DoH est bien actif

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (56)


Merci pour cet article. Très bonne compilation concise et exhaustive en un seul article pour faire les tests.


Mon genre d’article préféré :) Merci !








Next Inpact a écrit :



Surtout que certains services DoH ne communiquent que leur URL et pas une adresse IP.



Ce qui est une drôle d’idée je trouve, ça veut dire qu’il faut en plus un DNS classique (ou un autre DoH désigné lui par son IP), pour résoudre l’IP du DoH dont on n’a qu’une URL sans IP.



Quel intérêt de faire ça ? Ne pas dédier une IP au serveur DoH ? C’est rat quand même, surtout en IPv6 où déborde d’IPs.



Bref ça me choque pas du tout que Microsoft demande de saisir une IP et pas une URL, il faudrait juste une case à cocher pour dire si c’est un DoH ou non. Ou même plutôt le détecter automatiquement.



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.


Oui, c’est top, un bon compromis news / explication / technique








dvr-x a écrit :



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….





“Il est possible d’ajouter le résolveur de votre choix via une simple commande PowerShell (Administrateur) ”



 



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).


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 <img data-src=" />


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… !


Ben oui j’ai pas compris là ? Comment résoudre l’IP du DoH si on a qu’une adresse http ?


Y a-t-il des résolveurs français ou européens qui supportent ou ont annoncé un futur support de DOH ?


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 ?


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.








David_L a écrit :



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 ;)&nbsp;



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).





Ca revient à ce que je disais, il ne faudrait pas que ce soit activé par défaut. Si ca reste au stade de “si on l’active, alors ca prend le dessus sur le DNS par défaut” c’est très bien, je suis d’accord :)

&nbsp;

Après, avoir le choix, c’est très bien et je serais pour qu’il y a une façon de l’activer simplement. Mais Madame Michou quand elle initialise sont PC sous Windows, elle ne va pas avoir un cours sur DOH vs DNS Classique, elle va rester en conf par défaut, d’ou mon idée qu’il ne faudrait pas que ce soit par défaut.



&nbsp;



Donc faut pas que ce soit actif par défaut, mais si ça l’est pas ce sera pas activé <img data-src=" /> J’espère qu’on trouvera quand même de meilleures idées ;)


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 ?








David_L a écrit :



Donc faut pas que ce soit actif par défaut, mais si ça l’est pas ce sera pas activé <img data-src=" /> J’espère qu’on trouvera quand même de meilleures idées ;)





Je pense qu’on ne se comprends pas :)

&nbsp;

Il ne faudrait pas que le DOH soit actif par défaut (surtout sans choix des serveurs)

Mais il serait bien que, par défaut, il y ait une option simple pour l’activer, pour ceux qui le veulent et savent ce qu’ils font.









DayWalker a écrit :



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 ?



Bah ça ne serait pas forcément utile, la majorité des gens qui activent cette option c’est dans le souci de ne pas divulguer à son FAI (par extension la justice / gouvernement) les adresses visualisées en VPN.

Avec DoH chez ton FAI les requêtes DNS seraient chiffrés entre toi et ton FAI mais ton FAI aura toujours accès à tout ton historique y compris celui via VPN, ça te protégerait uniquement sur un wifi public par ex où tout le monde peut voir passer tout le traffic (DNS, HTTP / mail non sécurisé…) en clair.



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)


DoT par défaut est préférable à DoH par défaut :P


DoT, ça rime avec passé <img data-src=" />


Le turfu est sclérosé <img data-src=" />


network.trr.mode et pas network.uri.mode :)


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 )








David_L a écrit :



Donc faut pas que ce soit actif par défaut, mais si ça l’est pas ce sera pas activé <img data-src=" /> J’espère qu’on trouvera quand même de meilleures idées ;)



Une bonne idée pour ceux qui ont un routeur, c’est de faire gérer le DoH par le routeur. Le routeur fait serveur DNS classique pour le réseau local, et fait client DoH pour transmettre les requêtes à l’extérieur. Rien à configurer ni à supporter pour les clients, le DHCP fait son travail. Et on a toujours les résolutions locales qui fonctionnent, ce qui n’est pas le cas si chaque client choisit son DNS (DoH ou pas).



Ceux qui n’ont pas de routeur autre que la box du FAI seront de toute façon entravés le plus possible par le FAI qui ne fournira jamais le type de service que je viens de décrire. Et impossible d’activer un DoH par défaut dans un OS sans tomber dans le même travers soulevé par la façon dont procède certains navigateurs. On ne peut qu’informer ces gens-là sur la manière de faire, pas faire faire à leur place par une entité en espérant qu’elle soit honnête.



Y’a même un lien déjà dans le papier <img data-src=" />&nbsp;



&nbsp;





Inodemus a écrit :



Une bonne idée pour ceux qui ont un routeur, c’est de faire gérer le DoH par le routeur. Le routeur fait serveur DNS classique pour le réseau local, et fait client DoH pour transmettre les requêtes à l’extérieur.&nbsp;





Oui, ça devrait idéalement être intégré aux box. Mais quelque chose me dit que les FAI ne vont pas être pressés de sauter le pas… <img data-src=" />



C’est ce que je fais sous OPNsense. J’ai DNSCrypt-Proxy qui fait le travail de façon très simple.








Zebulon84 a écrit :



Y a-t-il des résolveurs français ou européens qui supportent ou ont annoncé un futur support de DOH ?





Le mien :-)https://www.bortzmeyer.org/doh-mon-resolveur.html Il est même en .fr.



Mais il y en a d’autres chez la FFDN ou les CHATONS, comme dans la liste à la fin du README enhttps://framagit.org/bortzmeyer/homer



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).








DayWalker a écrit :



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 ?





Ou bien parce que ça n’a aucun intérêt ? Si on a confiance dans son FAI, guère de raison d’utiliser DoH.









David_L a écrit :



Oui, ça devrait idéalement être intégré aux box. Mais quelque chose me dit que les FAI ne vont pas être pressés de sauter le pas… <img data-src=" />





Et quel intérêt ? Cela sécuriserait une communication qui est de toute façon uniquement sur le réseau local. Les dangers sont après.



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.


Article intéressant. Pour info, Debian supporte DoH.


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.


Je parlais du cas où la box irait faire ses requêtes externes via DoH ;)


Via dnscrypt-proxy (ou autre) tu veux dire ?


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.


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.



&nbsp;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

&nbsp;

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…

&nbsp;

&nbsp;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

&nbsp;

pour ceux qui veulent voir s’ils sont derrière un NAT64 voir ici lafibre.info&nbsp;


Oui, comme pour tout système du coup ;) Ici on parle de support natif à l’os


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.


Merci pour l’info. Je vais voir pour mettre à jour dsncrypt-proxy et activer DoH sur le routeur.


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.








Stéphane Bortzmeyer a écrit :



Le mien :-)https://www.bortzmeyer.org/doh-mon-resolveur.html Il est même en .fr.



Mais il y en a d’autres chez la FFDN ou les CHATONS, comme dans la liste à la fin du README enhttps://framagit.org/bortzmeyer/homer





Merci.



Deux choses m’interpellent :




  1. On veut tout faire passer en HTTPS,qui est sûr jusqu’à ce qu’on déclare que ça ne l’est pas, n’est-ce pas un risque de tout faire passer par le même système ?

  2. Mettre “DOH” dans Regedit me fait penser à Homer Simpson. Est-ce grave ? ☺








Stéphane Bortzmeyer a écrit :



Ou bien parce que ça n’a aucun intérêt ? Si on a confiance dans son FAI, guère de raison d’utiliser DoH.





Argument aussi “débile” que je n’ai rien à cacher, donc pas besoin de chiffrer mes données et communications. Libre à toi de vivre à poil.









Stéphane Bortzmeyer a écrit :



Ou bien parce que ça n’a aucun intérêt ? Si on a confiance dans son FAI, guère de raison d’utiliser DoH.





Chiffrer davantage nos données, c’est tout. Parce que ce qu’on fait sur internet, c’est privé. Evidément, ca n’empêcherait pas d’avoir des DNS menteurs chez son FAI, si c’est lui gère le DoH. Mais en attendant, pour madame Michu, dont le DNS est déjà celui de son FAI, que celui ci soit désormais DoH, ce serait totalement transparent pour elle (et localement, cela permet aussi au législatif de bloquer des accès illégaux à des sites… même s’il suffit de changer de serveur de noms pour contourner, mais là, ca sort de ce que madame Michu sait faire)



Tu peux utiliser DoT si tu préfères ;)


&gt; 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.”


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.

&nbsp;

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 <img data-src=" />


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.








dbodin a écrit :



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.







Ca dépend, en multipliant les intermédiaires tu multiplies aussi le risque que l’un d’entre eux soit faillible et compromette toute la chaîne.



Cf les fournisseurs de VPN qui ont été piratés par exemple.









David_L a écrit :



Y’a même un lien déjà dans le papier <img data-src=" />&nbsp;



&nbsp;

Oui, ça devrait idéalement être intégré aux box. Mais quelque chose me dit que les FAI ne vont pas être pressés de sauter le pas… <img data-src=" />





D’ailleurs, question bête monsieur le spécialiste du DoH. Est-il prévu qu’un serveur DHCP puisse transmettre à ses clients l’adresse d’un serveur DNS DoH (en plus des DNS classiques) au moment où il envoie sa configuration au client ?









Stéphane Bortzmeyer a écrit :



Le mien :-)https://www.bortzmeyer.org/doh-mon-resolveur.html Il est même en .fr.



Mais il y en a d’autres chez la FFDN ou les CHATONS, comme dans la liste à la fin du README enhttps://framagit.org/bortzmeyer/homer







Quel est ta politique sur les données ? Au lancement de ton service de DNS tu disais que tu te réservais le droit de tout faire sur ces données.









SebGF a écrit :



Ca dépend, en multipliant les intermédiaires tu multiplies aussi le risque que l’un d’entre eux soit faillible et compromette toute la chaîne.



Cf les fournisseurs de VPN qui ont été piratés par exemple.







Ouais enfin un (1) intermédiaire, je n’appelle pas ça “multiplier” non plus <img data-src=" />







dbodin a écrit :



En passant par un VPN payant … les appels vers les DNS ne sont-ils pas chiffrés (je me trompe ?)







Ca dépend du client vpn en fait. S’il redirige les appels vers les DNS ou non.







dbodin a écrit :



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 !







Par défaut, et surtout historiquement, les connexions aux DNS ne sont pas chiffrés. Mais il est tout à fait possible de chiffrer la connexion sans passer par DOH : DOT (DNS over TLS). L’avantage d’exploiter l’HTTPS (DOH) c’est qu’il a moins de chance d’être bloqué que le DNS (et donc le DOT) dans certains pays par exemple.







dbodin a écrit :



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.







C’est une des solutions exploitées par Freenet. Quand tu récupères une information sur le réseau Freenet, tu la reçoit à travers plusieurs intermédiaires qui eux mêmes l’ont recu de plusieurs intermédiaires…



Mais là ce n’est pas uniquement une question de sécurité du coup mais aussi d’anonymat/vie privée.



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:





  • Ou sont les root DNS actuels et qui possède le contrôle dessus ? Regardes les logos en haut à gauche dehttps://root-servers.org/ (tada). Donc: Qui ne voudra pas le perdre?…

  • Dans un cas d’adoption massive du DoH aura-t-on une course technologique qui in fine rendra service uniquement aux gros poissons ? Dans cet article je vois : Cloudfare, Google, Quad9. On est certain que l’un d’entre eux est un géant. Si la mise en service (déploiement) prend du temps; les utilisateurs iront par défaut chez le plus gros (paske ca marche). Et ça restera car “les habitudes ont la vie dures”.





    &nbsp;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:



  • https://fr.wikipedia.org/wiki/Serveur_racine_du_DNS

  • https://en.wikipedia.org/wiki/DNS_over_HTTPS

  • https://www.efficientip.com/what-is-dnssec/

  • https://root-servers.org/



    &nbsp;









    &nbsp;

    &nbsp;