Connexion
Abonnez-vous

DNS over HTTPS (DoH) : au-delà de Firefox, une « question de confiance »

Et d'implémentation

DNS over HTTPS (DoH) : au-delà de Firefox, une « question de confiance »

Notre dossier sur DNS over HTTPS :

Le 24 mars 2020 à 16h09

Apporter le chiffrement aux DNS est un besoin devenant essentiel. Si DNS over HTTPS participe à cet effort, il faut être attentif à la manière dont cette technologie est mise en œuvre. Un sujet complexe, surtout quand les éditeurs de navigateurs sont à la manœuvre. Même lorsqu'il s'agit de Mozilla.

Nous l'avons vu dans la première partie de ce dossier, le DNS est l'un des rares éléments techniques d'internet, que chacun d'entre nous utilise au quotidien, où la sécurité fait encore trop souvent défaut. Conçu il y a quarante ans, il n'a tout simplement pas été pensé pour bénéficier du chiffrement ou d'une signature de ses données.

Mais peu à peu les choses changent. Outre la mise en place (poussive) de DNSSEC, de nombreuses initiatives voient le jour et sont plus ou moins suivies par les différents acteurs. L'une d'elle est DNS over HTTPS (DoH) qui vise, comme son nom l'indique, à chiffrer les requêtes DNS en les encapsulant dans un flux HTTPS classique.

Une solution malaimée pour son aspect « HTTPisation du Net », mais qui a l'avantage d'être simple à appliquer, de se reposer sur des briques logicielles connues et maitrisées, ne pouvant être facilement bloquées en visant, par exemple, des ports spécifiques (contrairement à DNS over TLS, DoT). 

Utiliser un résolveur DoH : pas si simple

Dans notre précédent article, nous avons ainsi montré comment on pouvait effectuer une requête sur un résolveur DNS exploitant DoH à travers une simple ligne de commande. Mais voilà, l'utilisateur n'a que faire de telles solutions : il veut pouvoir profiter de la meilleure sécurité d'un tel résolveur par défaut, sans avoir à se casser la tête.

En l'état actuel des choses, ce n'est pas possible. Des travaux en ce sens sont en cours pour l'intégration aux interfaces des routeurs ou d'OS, notamment Windows 10, mais aucune date précise n'a encore été donnée. C'est pour cela qu'un autre type d'acteur s'est saisi du sujet ces dernières années : les navigateurs.

Car pour ce qui est de votre accès à internet, ils sont en première ligne. Une idée en apparence intéressante, séduisante, mais qui ajoute son lot de questions et de complexités.

Une question de confiance

Car nous l'avons vu : DoH n'est pas un totem d'immunité. Tout d'abord parce qu'il n'est pas utilisé par les serveurs racine, de premier et de second niveau (TLD/SLD). Ainsi, il est impossible de se connecter à ces derniers de manière chiffrée et d'obtenir une réponse l'étant également. Le lien entre un résolveur DoH et eux n'est donc toujours pas sécurisé.

Autre problème : même si l'on s'y connecte à travers une requête HTTPS, un résolveur tiers reste un acteur en qui l'on doit avoir toute confiance. DoH vise à chiffrer le lien entre lui et nous, sécurisant l'échange, rien de plus. Le résolveur a toute connaissance des requêtes qu'un utilisateur effectue et DoH ne l'empêche pas de « mentir » dans ses réponses.

Elles peuvent être chiffrées, mais fausses. Il ne faut donc pas choisir son résolveur à la légère. Si l'on trouve par ici ou par là des listes de services compatibles DoH, il faut donc faire un peu de tri. En voici certains, situés en Europe (donc soumis au RGPD) et gérés par des organismes à but non lucratif :

  • https://doh.powerdns.org/
  • https://odvr.nic.cz/doh
  • https://ldn-fai.net/dns-query
  • https://doh.42 l.fr/dns-query
  • https://dns.hostux.net/dns-query

DoH n'apporte pas de centralisation

Depuis quelques mois, lorsqu'il est question de DNS over HTTPS, les mêmes mots reviennent toujours, presque mécaniquement. Le reproche le plus courant est que cette technologie porte en elle le germe de la centralisation. 

C'est pourtant totalement faux : n'importe qui peut installer son propre résolveur DNS compatible DoH au sein de son réseau, l'utiliser pour lui-même, ses proches, le mettre à disposition des autres. C'est d'ailleurs ce qu'a fait Stéphane Bortzmeyer. Nombreux sont ceux qui existent déjà, à travers différents clients, démultipliant les possibilités. Ce, alors que le DNS est lui-même une solution technique qui a ses passages obligés : les serveurs racine, TLD/SLD.

Rappelons au passage qu'utiliser un résolveur DoH présent sur votre réseau local, pour vous-même, n'a que peu d'intérêt. Chiffrer un échange local n'apporte pas un grand bénéfice en matière de sécurité. Par contre, ce résolveur devra contacter lui-même les serveurs racine et TLD/SLD, de manière non chiffrée. Ils sauront alors directement qui est à l'origine de ces requêtes, ces échanges pouvant être observés par des tiers. On en revient au problème évoqué précédemment.

Il peut donc être opportun d'utiliser également un résolveur DoH tiers, ayant de nombreux utilisateurs. Lorsque votre résolveur DNS local ne sera pas suffisant, elle se tournera vers ce serveur externe, de manière sécurisée. C'est lui seul qui apparaîtra pour les serveurs racine et TLD/SLD, vos requêtes étant noyées dans la masse.

Utiliser DoH est donc une bonne chose, cette technologie ayant de nombreux intérêts. 

Le cas Firefox

Mais alors, pourquoi parle-t-on de centralisation du fait de DoH ? Cela vient en réalité de son implémentation. Car à défaut de pouvoir être activée dans une majorité de routeurs et d'OS, cette technologie a trouvé refuge dans les navigateurs.

Et en premier lieu Firefox, Mozilla ayant décidé de l'activer par défaut, pour l’instant aux États-Unis. Ailleurs, l'option est présente mais doit être activée manuellement. Autre choix effectué par défaut : utiliser Cloudflare comme résolveur DNS compatible DoH. Ce, alors que l'entreprise est déjà fortement critiquée pour être un SPoF (point de défaillance unique) du web actuel, tant il est utilisé par nombre de sites pour assurer leur sécurité en tant que firewall applicatif (WAF).

Mozilla a expliqué à plusieurs reprises chercher ce type de partenariat. L’éditeur a d'ailleurs créé une charte rassemblant tout un lot de règles sur lesquelles les partenaires doivent s’engager pour avoir le droit de figurer dans Firefox. Notamment, effacer quotidiennement les données accumulées et ne jamais les transmettre à des tiers.

Cette liste de prestataires devrait grandir avec le temps, mais Mozilla n’a pas donné de calendrier. Autre regret : cette solution ne protège pas tous les usages effectués hors du navigateur, et ils sont nombreux.

Firefox DoH
Pour accéder aux paramètres DoH de Firefox, rendez-vous dans l'onglet Général des options, puis dans les Paramètres réseau

Les utilisateurs ne modifient que très rarement les paramètres par défaut, certains craignent de voir CloudFlare devenir le résolveur DNS du plus grand nombre, un peu comme Google est utilisé comme moteur de recherche par défaut, notamment pour sa place centrale dans de nombreux systèmes et navigateurs (dont Firefox dans la plupart des pays).

Mozilla propose pourtant NextDNS comme alternative pour le moment, proposant même un mode personnalisé où vous pouvez indiquer l'URL du résolveur DNS compatible DoH de votre choix. Ajoutons que pour être certain de pouvoir faire son travail, Firefox utilise son propre résolveur, ainsi qu'un domaine à l'adresse use-application-dns.net.

On pourrait néanmoins imaginer que le navigateur n'impose aucun choix par défaut, propose à l'utilisateur de choisir après l'installation ou modifie régulièrement ce paramètre tant qu'aucun choix n'est fait par exemple. Ce n'est pour l'instant pas le cas. Il faudra d'ailleurs être attentif à l'attitude des navigateurs dérivés de Chromium sur le sujet.

Pour le moment au stade expérimental, le support DoH n'impose rien. Mais Google plaçant déjà ses propres DNS par défaut dans les routeurs Wi-Fi qu'il commercialise, on imagine qu'il sera tenté de faire de même dans Chrome. À suivre.

Le 24 mars 2020 à 16h09

Commentaires (50)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Quelqu’un a déjà testé Adguard Home ?

https://github.com/AdguardTeam/AdGuardHome



Apparemment, c’est du clé en main. Il fait DoH et DoT en tant que serveur et demandeur de requêtes.



Et pour ceux qui veulent tester avec unbound, j’ai trouvé ce post :https://www.reddit.com/r/Adguard/comments/dkhxsq/how_do_i_setup_unbound_on_adgua…



Il faudra un jour que j’essaie quand j’aurai du temps <img data-src=" />

votre avatar

“Mais Google plaçant déjà ses propres DNS par défaut dans les routeurs Wi-Fi qu’il commercialise, on imagine qu’il sera tenté de faire de même dans Chrome.&nbsp;À suivre.”



&nbsp;Google force déjà ses propres DNS dans ses Chromecast. Il est impossible de les modifier sauf au travers de très complexes manipulations visant à rooter la Chromecast.

votre avatar

Oui après Chromecast est un outil plus spécifique, contrairement au routeur qui indique aux appareils du réseau quels résolveurs DNS utiliser, et donc à qui envoyer toutes les requêtes. Mais c’est également un problème qu’ils soient modifiés par défaut et non configurable, oui. Même si utiliser Chromecast sans vouloir que Google sache ce que l’on regarde, me paraît un brin étrange… <img data-src=" />

votre avatar

Perso à la maison c’est Pi-hole + unbound configurés pour faire du DoT, et installé sur un NAS qui est aussi mon serveur DHCP.

Pour le PC du boulot sous Windows j’ai DNSCrypt Client Proxy qui est pas mal et très configurable.

votre avatar

C’est surtout que je pense que forcer les DNS de Google permet de faire du blocage géographique de contenu.

votre avatar







dyox a écrit :



Apparemment, c’est du clé en main. Il fait DoH et DoT en tant que serveur et demandeur de requêtes.





Comme dit dans le papier, DoH sur un serveur local, j’ai du mal à saisir l’intérêt (pour un cas d’utilisateur personnel), vu que toutes les connexions externes vers les serveurs racine/TLD/SLD seront effectuées depuis la connexion de l’utilisateur, sans chiffrement.&nbsp;&nbsp;


votre avatar

Le chiffrement sur le réseau local, oui ça n’a pas grand intérêt, mais avoir un serveur dns sur son réseau local comme Pi-hole est tout de même utile. Le serveur DNS local peut utiliser DoH / DoT entre lui et les serveurs DNS upstream. Se pose donc la question de la confiance, mais toujours mieux que d’utiliser les DNS non chiffrés du FAI à mon avis.

votre avatar

Oui le DNS local en lui-même a un intérêt, mais pour DoH & co il vaut mieux se reposer sur un serveur tiers (et du coup le résolveur local est un peu moins utile, mais c’est toujours ça de pris). Dans le cas de Pihole & co, il est surtout utilisé pour ses fonctionnalités “annexes” disons (et là le côté menteur ne gêne plus :p)

votre avatar







David_L a écrit :



Mais justement, ces requêtes sont aussi chiffrées !

Encrypted DNS upstream servers (DNS-over-HTTPS, DNS-over-TLS, DNSCrypt)


votre avatar

Oui, si tu passes par des résolveurs tiers en complément de ton résolveur local, comme dit plus haut.&nbsp;

votre avatar

Attention, si tu utilises Unbound en tant que client DoT (qui forwarde donc les requêtes vers un résolveur via TLS), la gestion de TCP par Unbound est quelque peu olé-olé pour ne pas dire à chier (il coupe la connexion TCP après chaque requête, ça plombe les perfs et augmente la charge réseau - il faut refaire la triple poignée de mains TCP et toute la négo TLS à chaque requête, c’est un massacre).



En client, il faut mieux utiliser Stubby :)

votre avatar

Du DoT vers quel résolveur ?

votre avatar

Bonjour, il faudrait arrêter la publicité monsieur, merci <img data-src=" /> <img data-src=" />

votre avatar

Étant sous linux, je suis en train de regarder du côté de firejaildns que je viens juste de découvrir. C’est fait pas ceux qui font la sandbox firejail.

votre avatar

Ça me rappelle tellement les problématiques IMAP/LDAP/….



Petite question, c’est basé comment sur firefox, sur une IP ou sur une URL ?&nbsp; Parce que de ce que je comprends, on va tout de même devoir faire une requête DNS pour pouvoir faire du DOH.



Seconde question est-ce qu’a terme on va donc devoir gérer les DNS de l’OS et les DOH dans le navigateur ? Et du coup pourquoi pas un client DOH dans d’autre applications ?



Troisième question, est-ce qu’il y a une raison technique à ne pas avoir fait du STARTTLS pour DNS ? Ca réponds tout de même au deux problématiques, pas de changement de port et pas de HTTP inutile au milieux.



Y’a quatre choses qui m’embêtent clairement :




  • A force de faire du HTTP(S) partout (parce que c’est ce que connaissent les développeurs faut pas se mentir) on va se retrouver à insister sur le filtrage URL et plus sur le filtrage des ports…. Donc au final on revient au même problème.



  • Cette histoire de client DNS dans une application, en tant qu’ingé sys je vois tellement de chose qui vont être relou….



  • En terme de charge/consommation réseau ça va être clairement de la consommation en plus.

    &nbsp;

  • On a clairement un DOH décorrélé du DHCP. Ca se gère bien par GPO au moins ?

votre avatar

Tu peux avoir une IP dans une URL, je dis ça, je dis rien <img data-src=" />

votre avatar







David_L a écrit :



Tu peux avoir une IP dans une URL, je dis ça, je dis rien <img data-src=" />





https://1.1.1.1/dns-query :-)


votre avatar

aureus a écrit :

Seconde question est-ce qu’a terme on va donc devoir gérer les DNS de l’OS et les DOH dans le navigateur ? Et du coup pourquoi pas un client DOH dans d’autre applications ?



&nbsp;Aucune idée, DoH est juste un protocole, comme DoT, comme le DNS classique, il peut être mis dans le système d’exploitation ou bien dans les applications.&nbsp;

votre avatar







aureus a écrit :



Troisième question, est-ce qu’il y a une raison technique à ne pas avoir fait du STARTTLS pour DNS ?





Plus personne n’utilise STARTTLS, SMTP l’a abandonné dans le RFC 8314https://www.bortzmeyer.org/8314.html Et à juste titre, STARTTLS n’offre aucune sécurité, un attaquant actif peut trivialement empêcher le passage en TLS.

&nbsp;


votre avatar







aureus a écrit :





  • A force de faire du HTTP(S) partout (parce que c’est ce que connaissent les développeurs faut pas se mentir) &nbsp;





    Pas du tout. La raison pour laquelle DoH a été créé (cf. le RFC) était pour pouvoir fonctionner partout, y compris sur un hotspot pourri où seuls les ports 80 et 443 passent.


votre avatar







aureus a écrit :





  • En terme de charge/consommation réseau ça va être clairement de la consommation en plus.





    Euh, à l’ère de la vidéo haute-définition de films de chats, s’inquiéter des quelques octets supplémentaires du DNS, c’est assez étrange.


votre avatar

Des intérêt s du DNS local c’est:

*&nbsp; filtrage parental

* éviter les DNS menteurs des FAI

* filtrage de pub comme le propose aussihttps://dns.hostux.net/fr/ viahttps://dns.hostux.net/ads&nbsp;

votre avatar

J’imagine que les logiciels malveillants vont vite utiliser DoH pour éviter de se faire repérer.

votre avatar

Le chiffrement, c’est la plaie. Les gens honnêtes qui n’ont rien à cacher ne l’utilisent pas.

votre avatar

C’est un des rares cas où je fais la pub d’autre chose qu’Unbound ! <img data-src=" />

votre avatar

Le géoblocage de contenu se fait plus au niveau de l’IP du client que des DNS utilisés je pense.

votre avatar

J’utilise SimpleDNSCrypt sur Windows, ça permet le DoH en plus du DNSCrypt (mais c’est moins performant donc je l’ai désactivé), configuré au niveau de l’interface réseau et non du navigateur, c’est donc un résolveur local avec cache et gestion de liste noire d’IP ou domaines, de redirections et tout ce qu’on peut vouloir, et ça résout automatiquement désormais parmi les serveurs qu’on autorise. La confiance doit se faire envers cette liste de serveurs et le respect de leur promesse de “pas de log / pas de mensonge”.

votre avatar

Oui, d’où ma remarque ;) On avait eu la demande avec Quad9 dans la précédente actu et j’avais testé que ça fonctionnait par acquis de conscience <img data-src=" />

&nbsp;







John Shaft a écrit :



C’est un des rares cas où je fais la pub d’autre chose qu’Unbound ! <img data-src=" />





<img data-src=" />

&nbsp;



Soriatane a écrit :



Des intérêt s du DNS local c’est:

*&nbsp; filtrage parental

* éviter les DNS menteurs des FAI

* filtrage de pub comme le propose aussihttps://dns.hostux.net/fr/ viahttps://dns.hostux.net/ads&nbsp;





Comme quoi on trouve parfois des intérêts aux DNS menteurs <img data-src=" /> Pour le reste, je ne pense pas que le DNS soit la solution pour le filtrage parental (ou même pour les pubs), mais ça peut être une première base de filtrage. Il faut juste avoir confiance dans ceux qui fournissent les listes ;)


votre avatar

Sur un Syno RT1900AC, on peut activer DoH au niveau du DNS du routeur. Par contre on a le choix uniquement entre Cloudflare et Google

Sur des FortiGate, au boulot, on peut faire du DoT.

votre avatar

Je me doute mais vu que je vais vu que des URL dans ton article <img data-src=" />

votre avatar

Ah oui c’était pas spécifique à DoH, mais à la décision de firefox de mettre un client DNS dans son navigateur.

votre avatar

<img data-src=" /> Pour le starttls



&nbsp;







Stéphane Bortzmeyer a écrit :



Pas du tout. La raison pour laquelle DoH a été créé (cf. le RFC) était pour pouvoir fonctionner partout, y compris sur un hotspot pourri où seuls les ports 80 et 443 passent.





Et pourquoi pas faire du DOT sur le port&nbsp; 53 ? j’ai été regardé sur la RFC et j’ai pas compris la réponse.

Ou même pourquoi pas le mettre sur le port 443 vu que toute façon l’alternative c’est de l’encapsuler donc y’a plus vraiment de différenciation du trafic.

&nbsp;





Stéphane Bortzmeyer a écrit :



Euh, à l’ère de la vidéo haute-définition de films de chats, s’inquiéter des quelques octets supplémentaires du DNS, c’est assez étrange.





C’est pas tim berners-lee qui a regretté d’avoir ajouter www au début de chaque URL parce que ca pompait quelques octets pour rien à chaque requête ? Mais oui c’est pas un vrai argument à l’heure de la 4K <img data-src=" />


votre avatar

Merci pour cet article que j’attendais avec impatience. Vous êtes les meilleurs!

votre avatar



Mais Google plaçant déjà ses propres DNS par défaut dans les routeurs

Wi-Fi qu’il commercialise, on imagine qu’il sera tenté de faire de même

dans Chrome.





Ah oui on en est là !! <img data-src=" />

votre avatar







aureus a écrit :



Et pourquoi pas faire du DOT sur le port&nbsp; 53 ?





On peut toujours faire ce que l’on veut, mais ça va perturber les innombrables middleboxes, IDS et transparent proxies.&nbsp;



Et avec le port 443, on perturberait l’écosystème Web (il y a déjà un serveur HTTP sur ce port).


votre avatar

J’utilise pihole à la maison pour bloquer la pub, les réseaux sociaux, la télémétrie de Windows et autres joyeusetés sites malveillants. Je l’ai configuré pour aller piocher ses entrées DNS chez les meilleurs (FDN évidement). La lecture de cet article m’évoque 2 questions :





  • Il y a-t-il moyen de configurer pihole pour utiliser DoH ? Il y a un “tuto” dans la doc de pihole mais c’est lié à cloudflare, et je ne souhaite pas utiliser les services de cloudflare. D’autre part je ne suis pas expert réseau et je ne comprends pas forcément tout ce qui y est expliqué.

  • J’ai confiance dans la FDN, peut-on faire confiance aux autres fournisseurs DoH, notamment ceux cités dans l’article ? Est-ce judicieux de “quitter” les DNS de la FDN pour aller sur du DoH chez un autre ?





    Edit: mise en forme

votre avatar

Je suis dans le même cas que toi mais j’ai en plus unbound pour avoir un cache de 48h et DNSSEC avec Quad9 (tutohttps://docs.pi-hole.net/guides/unbound/)




  • Si tu veux du DoH, il y a dnscrypt il me semble.

  • La confiance, cela n’engage que ceux qui y croient. Il y a plein d’exemples où ils disent no-log alors qu’ils existe des log.



    Ne pas oublier sur les firmwares alternatifs des routers (openwrt, Asuswrt-Merlin, freshtomato…) qui proposent du dnscrypt et stubby ou autres.

votre avatar

C’est vraiment une très mauvaise idée.

D’abord, DNS sur HTTP, carton rouge, c’est pas fait pour ça. Pourquoi pas du DHCP ou du BGP sur HTTP tant qu’on y marche sur la tête…



Ensuite, contourner le DNS du système par le navigateur va créer énormément de problèmes vu que les résultats entre le navigateur et les autres logiciels seront potentiellement différents. D’autant plus vrais en entreprise ou la majorité des sites utilisés sont des applis locale accessible grâce au DNS local. Avec un DNS dans le navigateur, toutes les applis locales (ou sur le VPN de la boite) seront inaccessibles.



Il y a pourtant une solution : DNSSEC c’est spécialement conçu pour ça et ça marche bien. Ils sont en train d’inventer une usine à gaz dangereuse juste parce que les opérateurs sont fainéant et n’implémentent pas DNSSEC…

votre avatar

Sauf erreur de ma part, DNSSEC garantie l’intégrité du message DSN (impossibilite de rajouter des lignes ou d’enlever sans casser la signature) alors que DoT ou DoH garantissent la confidentialité de l’échange DNS (personne ne peut lire).



Bref, les deux sont complementaires et ne cherchent pas à résoudre les mêmes problèmes.

votre avatar

Ah tu réponds à une autre de mes questions à savoir comment faire en sorte que le cache DNS reste plus longtemps dans pihole. C’est pas natif à pihole, il faut que j’ajoute unbound donc ? J’irais faire un tour. Après tout les @IP des divers serveurs ne changent pas si souvent que ça.

votre avatar

Oui et c’est l’option cache-max-ttl dans le fichier conf d’unbound (il est au début)

Effectivement 1j c’est suffisant (j’ai de mémoire 1500 url journalier) mais j’avais fait un test avec WSCC qui interroge au moins 200 url et là c’est flagrant comme différence.



Na pas oublier aussi que pi-hole est nullement réservé aux minimachines, il existe une config docker-compose sous les différents OS :https://github.com/pi-hole/docker-pi-hole

votre avatar

Je suis allé lire la page du tuto unbound pour pihole. Pour le moment je ne suis pas sûr d’être intéressé par le fonctionnement d’unbound (je ne saisis pas l’intérêt, comparé à DoH).. Existe-t-il directement dans pihole un moyen d’augmenter le temps de vie des entrées du cache DNS ?

votre avatar







Alfred1664 a écrit :



Ensuite, contourner le DNS du système par le navigateur va créer énormément de problèmes vu que les résultats entre le navigateur et les autres logiciels seront potentiellement différents. D’autant plus vrais en entreprise ou la majorité des sites utilisés sont des applis locale accessible grâce au DNS local. Avec un DNS dans le navigateur, toutes les applis locales (ou sur le VPN de la boite) seront inaccessibles.





Dans Firefox, je pense que les requêtes concernant le réseau local reste résolu par le DNS indiqué dans les paramètres réseau.

J’avais activé DoH sur mon FFX au boulot et nos applis web locales ont toujours répondu via le DNS AD Windows. Je n’ai jamais eu d’erreur de résolution.


votre avatar

Je viens de tester avec wireshark et firefox et c’est effectivement le cas.

votre avatar

Malgré cette page https://docs.pi-hole.net/ftldns/dns-cache), je n’ai pas trop compris le fonctionnement mais il y a bien un truc.

En tout cas, le DNS cache insertions est raz au boot, il est passé de 3800 (j’avais un uptime de 31 jours) à 0.

votre avatar

Article intéressant et tout mais à quand la suite ?

ce qu’on veux c’est pouvoir l’utiliser, de savoir le comment ça fonctionne c’est bien mais ne permet pas de l’utiliser. Il y a l’extension easydoh pour firefox qui permet de tout configurer facilement.

votre avatar

Ah, merci du tuyau :-) Je vais voir si je peux mettre Stubby au lieu de Unbound.

votre avatar

Vers Quad9

votre avatar

Il y a quoi de compliqué dans la configuration de FF ?

votre avatar

Ici je parlais pour activer DoH sur FF et non configurer FF en général

Pour des advanced user comme l’audience de NXI je pense qu’il n’y rien de compliqué mais pour Mr et Mme

Michu je ne pense pas que cela soit si simple de configurer des fonctions avancées comme DoH ou gestion de la vie privée en personalisée. Surtout que maintenant FF à un blocage des traqueurs intégrés et donc des sites ne fonctionnent plus maintenant car adblocker détecté.

DNS over HTTPS (DoH) : au-delà de Firefox, une « question de confiance »

  • Utiliser un résolveur DoH : pas si simple

  • Une question de confiance

  • DoH n'apporte pas de centralisation

  • Le cas Firefox

Fermer