Guide de choix d’un résolveur DNS public

 (evilbit.de)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Un résolveur DNS public ne doit pas être évalué uniquement sur la vitesse : il faut aussi prendre en compte la protection de la vie privée, le filtrage, la juridiction, l’opérateur et le transport chiffré ; ce guide compare 30 services mondiaux selon différents besoins
  • L’outil de sélection utilise DoH, DoT, DoQ, DNSCrypt, la validation DNSSEC, IPv6, la juridiction, le type d’opérateur et EDNS Client Subnet comme filtres stricts, puis attribue des scores selon les priorités d’usage
  • Le test de latence DoH dans le navigateur montre la vitesse relative depuis l’emplacement actuel, mais inclut la surcharge TLS/HTTP et ne peut pas mesurer les résolveurs réservés au DNS en clair
  • Le DNS chiffré réduit l’écoute et l’altération par des intermédiaires, mais le fournisseur de résolveur choisi peut voir les domaines consultés ; il faut donc aussi considérer les politiques sans logs et les architectures oblivious
  • En pratique, il faut évaluer ensemble DNSSEC, le compromis vitesse-vie privée d’ECS, les performances de DoQ, les caractéristiques de DNSCrypt, les limites de l’analyse de trafic, les différences de conformité aux standards, ainsi que les risques liés à la juridiction et à la centralisation

Critères comparés par l’outil de sélection

  • Les résolveurs DNS publics sont comparés en fonction des critères jugés importants par l’utilisateur
  • Conditions utilisées comme filtres stricts
    • Transport chiffré : DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-QUIC (DoQ), DNSCrypt
    • Prise en charge de la validation DNSSEC
    • Fourniture d’adresses de résolveur IPv6
    • Juridiction de l’opérateur
    • Type d’opérateur : association, communauté, intérêt public, commercial, ou tous
    • EDNS Client Subnet (ECS) : désactivé, activé, sans importance
  • Éléments intégrés au score de priorité
    • Protection maximale de la vie privée et politique sans logs ou à logs minimaux
    • Blocage des malwares et du phishing
    • Blocage des publicités et des traqueurs
    • Contrôle parental et blocage des contenus pour adultes
    • Absence de filtrage, avec retour fidèle des réponses DNS publiées
    • Listes de blocage et règles personnalisées via un compte
    • Faible latence mondiale grâce à l’Anycast global
    • Opérateur non commercial

Test de vitesse DoH selon l’emplacement actuel

  • Le test intégré mesure dans le navigateur le temps d’aller-retour vers chaque résolveur compatible DoH
  • Les résolveurs ne prenant en charge que le DNS en clair ne peuvent pas être testés de cette manière
  • Les résultats sont des valeurs de référence relatives ; comme ils incluent la surcharge TLS et HTTP, il est supposé qu’ils soient exécutés plusieurs fois
  • Comme le navigateur interroge directement chaque résolveur, l’adresse IP de l’utilisateur est exposée à ce résolveur
  • L’implémentation du test s’inspire du projet open source DNS Speed Test de Silviu Stroe, mais il s’agit d’une implémentation indépendante, exécutée uniquement lorsque la page est servie en HTTPS

Différences entre performances et transport chiffré

  • Les transports chiffrés comme DoH et DoT ajoutent de la latence par requête, mais le temps total de chargement des pages reste souvent proche de celui du DNS en clair, et la surcharge de DoH apparaît faible dans les conditions réelles
  • Sur les liaisons avec pertes ou forte latence, le Do53 en clair conserve un avantage
  • Les performances varient selon le fournisseur et la région ; le résolveur le plus rapide dépend donc de l’emplacement de l’utilisateur
  • Les mesures de bout en bout à grande échelle sur le DNS chiffré montrent que les requêtes ont beaucoup moins de chances d’être interceptées ou modifiées en transit qu’avec le DNS en clair, pour une surcharge faible
  • Toutefois, dans cette étude, environ 25 % des fournisseurs DoT présentaient des certificats TLS invalides ; il est donc important de choisir un fournisseur de bonne qualité opérationnelle

Limites réelles de la protection de la vie privée

  • Le DNS chiffré masque les requêtes sur le réseau, mais le fournisseur de résolveur choisi peut voir tous les domaines consultés
  • Si cela pose problème, il faut choisir un opérateur sans logs ou envisager une architecture oblivious comme ODoH, où un proxy sépare l’identité et la requête
  • Cloudflare et Apple ont déployé ODoH
  • Le DNS chiffré ne masque pas complètement les sites visités
    • Même avec DoH, l’analyse de trafic peut identifier les domaines visités avec une grande précision
    • Le padding EDNS standard ne suffit pas à l’empêcher complètement
    • Si ce modèle de menace vous concerne, il ne faut pas compter uniquement sur le padding, mais l’associer à Tor ou à une architecture oblivious

DNSSEC, ECS et juridiction

  • Seuls les résolveurs effectuant la validation DNSSEC protègent contre les enregistrements falsifiés
  • Google, Cloudflare et Quad9 valident DNSSEC et ont géré la première rotation de clé racine KSK sans panne côté utilisateur
  • Si l’intégrité est importante, la validation DNSSEC doit être considérée comme une exigence indispensable
  • EDNS Client Subnet (ECS) envoie une partie de l’IP au CDN pour améliorer le routage géographique
    • Google et OpenDNS envoient ECS pour obtenir un mappage CDN plus précis
    • Cloudflare et la version standard de Quad9 désactivent ECS pour préserver la vie privée
  • Le lieu d’implantation juridique de l’opérateur influe sur les mesures coercitives possibles et sur les logs
  • Un petit nombre de fournisseurs traite une grande part du trafic DNS récursif mondial
  • La NSA américaine a averti que les résolveurs externes contournent le filtrage et l’inspection DNS internes ; il faut donc arbitrer entre commodité et contrôle

DoQ et DNSCrypt

  • Dans des mesures de 2022, DNS-over-QUIC a surpassé DoT et DoH en temps de réponse
  • Toutefois, les limitations de validation d’adresse de QUIC ont ralenti environ 40 % des handshakes
  • Si le client et le résolveur le prennent tous deux en charge, DoQ est une option chiffrée à privilégier
    • Exemples de prise en charge : Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS et les grands services chinois
  • DNSCrypt est une option de chiffrement plus ancienne que DoH, DoT et DoQ ; la version 2 est sortie en 2013
  • DNSCrypt chiffre dès le premier paquet à l’aide de la clé publique partagée du résolveur, sans requête préalable en clair sur le nom d’hôte ni dépendance à une autorité de certification
  • Le mode Anonymized DNS de 2019 masque aussi l’IP du client
  • Parmi les services comparés, les fournisseurs DNSCrypt sont Quad9, OpenDNS, AdGuard, NextDNS, Control D et Yandex
  • Les chiffres d’usage fiables manquent, et les grandes mesures comme APNIC Labs suivent DoH et DoT mais pas DNSCrypt

Qualité d’implémentation des résolveurs et données opérationnelles

  • Une étude de 2023 sur Extended DNS Errors a montré que les grands résolveurs avaient des rapports d’erreur de diagnostic incohérents dans 94 % des cas de test
  • Cloudflare a présenté dans cette étude les rapports d’erreur les plus précis
  • Les différences de qualité d’implémentation et de conformité aux standards selon les résolveurs influencent la résolution des problèmes et la fiabilité
  • Données opérationnelles et communautaires utiles
    • ICANN Identifier Technology Health Indicators : suivi du taux de résolveurs validant DNSSEC et de la concentration des résolveurs
    • DNS-OARC workshop talks et past-event archive : présentations d’opérateurs et de chercheurs sur le DNS chiffré, les performances des résolveurs et les mesures
    • APNIC Labs measurements : données par pays sur le taux de validation DNSSEC, l’usage des résolveurs publics et l’adoption de DoH et DoT

Petits résolveurs, résolveurs communautaires et régionaux

  • En dehors du tableau comparatif, il existe aussi des résolveurs spécialisés par hobby, communauté ou pays ; il faut vérifier leur état actuel et leurs politiques avant usage
  • Les options européennes sont recensées sur European Alternatives
  • Les résolveurs situés dans des régions fortement soumises à la censure ou aux sanctions peuvent appliquer des règles locales sur les contenus ou être exploités pour contourner le blocage géographique ; ils demandent donc une vigilance particulière
  • Exemples de services
    • DNS4all : résolveur européen non filtré axé sur la neutralité et les performances
    • BlahDNS : projet open source amateur de blocage publicitaire, exploité sur de petits serveurs régionaux, avec prise en charge de DoH, DoT et DoQ
    • LibreDNS : résolveur communautaire de LibreOps, avec blocage publicitaire et politique sans logs, compatible DoH et DoT
    • Dismail.de : résolveur communautaire allemand centré sur la vie privée, sans logs, compatible DoH et DoT
    • IIJ Public DNS : résolveur public DoH et DoT d’Internet Initiative Japan, bloquant les domaines liés aux contenus pédopornographiques
    • DNS for Family : DoH de filtrage familial incluant contenus pour adultes, jeux d’argent, malwares, publicités, traqueurs et recherche sécurisée
  • Parmi les services legacy à éviter ou interrompus figurent Oracle Dyn, Level3 (4.2.2.x), Freenom World, dns0.eu et Norton ConnectSafe

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News

  • À chaque fois que je vois ce genre de liste ou l’annonce d’un nouveau service, ça ne me fait pas grand effet, et il semble y avoir étonnamment beaucoup de réactions similaires sur Hacker News.
    Cela fait près de 25 ans que j’exploite moi-même un service DNS proxy, et j’ai utilisé trois ensembles logiciels sur six systèmes d’exploitation ; tout ce qui figure dans l’onglet des filtres peut être fait soi-même, et c’est effectivement ce que je fais.
    Dans cette liste, ce ne sont pas tant les choix qui sont intéressants que ce qu’elle révèle. Par exemple, tous les éléments indiqués comme « Chine » sont marqués comme « exploités sous réglementation chinoise », mais en 2026, ce n’est pas seulement un facteur préoccupant pour les services chinois : ça l’est aussi pour les utilisateurs de mon continent.
    La mention « exploité par une seule personne au Danemark » est une information intéressante parce qu’elle met en évidence le bus factor, mais on ne peut pas supposer que les autres options sont meilleures simplement parce qu’elles n’en parlent pas. On en sait bien moins sur les personnes derrière DNS.Watch que sur Thomas Steen Rasmussen, et le service semble être tombé au moins une fois ces dernières années, donc l’inquiétude est légitime.
    Quad101 semble avoir des restrictions de disponibilité géographique, et il existe beaucoup d’autres facteurs absents de cette liste mais potentiellement importants pour les utilisateurs, comme le fait que Gcore soit une entreprise d’IA.

    • Le fait que ce soit « exploité par une seule personne au Danemark » est plus intéressant du point de vue de la surveillance organisationnelle que du bus factor.
      Quand plusieurs personnes participent à l’exploitation, elles peuvent se surveiller mutuellement et soulever le problème si elles constatent quelque chose d’anormal, comme une journalisation sélective par le résolveur DNS ou une intervention sur les résultats. Si une seule personne gère tout, personne n’est là pour la retenir.
      On peut se dire que « cette personne a des principes et ne ferait jamais ça », mais la pression des forces de l’ordre peut être très forte.
    • J’ai configuré mon propre résolveur il y a environ deux ans, et ça fonctionne tout simplement. Je n’ai jamais eu de problème.

  • Utiliser le DNS officiel de son FAI permet d’obtenir le chemin le plus court possible depuis le point de remise du FAI jusqu’au CDN ou aux trunks internationaux. En clair, n’utilisez pas un DNS généraliste qui ne connaît pas l’architecture de votre FAI.
    FAI : 1 ms jusqu’à Cloudflare
    Cloudflare : 10 ms jusqu’à Cloudflare
    Cela dit, ce conseil vaut pour les pays où les lois sur la vie privée sont bonnes et où il n’y a pas de surveillance étatique. Donc pas les États-Unis.

    • Si vous avez besoin d’un DNS sans censure, ce n’est pas une bonne méthode.
    • En pratique, utiliser un DNS qui bloque les serveurs publicitaires a de bonnes chances d’offrir de meilleures performances globales.
    • Je ne sais pas si de tels pays existent encore réellement aujourd’hui. Et ce n’est pas seulement une question de vie privée : presque tous les États cherchent à empêcher les utilisateurs d’accéder à des endroits auxquels ils ne veulent pas qu’ils accèdent, le plus souvent au moyen d’un bricolage où le DNS par défaut du FAI vous envoie vers une page d’avertissement au lieu du site que vous vouliez ouvrir.
      C’est pourquoi passer à un DNS comme 8.8.8.8, même si cela n’améliore pas forcément la vie privée, devient une première grande étape pour améliorer l’expérience de navigation.
    • Cloudflare utilise, comme chacun sait, Anycast, donc la réponse DNS est la même quelle que soit votre origine. Les chiffres donnés semblent difficilement imputables au DNS.
      Au contraire, Cloudflare peut raccourcir les requêtes récursives pour ses propres services, ce qui peut accélérer l’étape de résolution de noms, et utiliser au besoin l’eDNS Client Subnet pour le routage géolocalisé.
    • Changer de DNS n’a presque aucun effet sur la vie privée. On peut toujours lire les requêtes DNS et le SNI.

  • J’aurais besoin de conseils sur l’utilisation conjointe d’un résolveur DNS sur les réseaux Wi-Fi publics.
    Beaucoup de Wi-Fi publics exigent d’utiliser leur propre DNS afin de pouvoir rediriger vers l’écran d’acceptation des conditions, et demandent parfois une nouvelle validation toutes les 30 à 60 minutes.
    Quand un problème survient, on finit par remarquer que l’Internet s’est arrêté, lancer un ping vers google.com, attendre le timeout, se demander si c’est un problème du FAI, puis comprendre que la session Wi-Fi a probablement expiré, changer de DNS, vider le cache, accéder à un domaine non TLS, valider le portail, puis remettre le DNS précédent.
    Il devrait forcément exister quelque chose pour gérer ça.

    • Sur macOS, /etc/resolver pourrait peut-être résoudre le problème.
      sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
      J’ai utilisé cette méthode quand un site interne d’université ne se résolvait qu’avec le serveur de noms du réseau. Je me suis dit que cela pourrait aussi s’appliquer à l’URL utilisée par macOS pour détecter les portails captifs, et il faudra que je vérifie la prochaine fois que j’irai dans un café.
    • Sur macOS et iOS, on peut créer un profil qui spécifie le serveur DNS à toujours utiliser. Il s’applique aussi aux autres réseaux Wi-Fi et aux données mobiles.
      https://doh.lvv.me/
      Je l’utilise depuis plusieurs années et je n’ai jamais eu de problème sur les hotspots publics.
    • Il suffit de saisir directement l’adresse IP dans la barre d’adresse. En général, ils interceptent tout le trafic sur le port 80.
    • Ce genre de chose devrait être géré par le système d’exploitation dans le cadre de la prise en charge des portails captifs. Il vaudrait mieux contacter l’éditeur de l’OS et ouvrir un bug.

  • J’utilise Unbound en local comme serveur DoH. Le paquet Unbound d’Alpine Linux est compilé avec libnghttp2, nécessaire au listener DoH intégré, et cela suffit pour activer ECH
    Toutes les heures, via cron, je mets en cache à l’avance tous les domaines que j’utilise fréquemment. Mon FAI ne va probablement pas toucher à mes requêtes DNS, et ses employés sont encore plus bizarres que moi. Si je me mets à consulter le Web sur téléphone, je créerai mon propre serveur DoH public. Cela prend quelques minutes, et j’aurai aussi mes journaux de requêtes quand il faudra déboguer des problèmes étranges
    [1] - https://tls-ech.dev/

    • Cela fait environ 3 ans que j’exploite moi-même des instances publiques powerdns, dnsdist, récursives et faisant autorité, avec DoH, DoT, DoQ, TCP et UDP
      Avant, j’utilisais bind, unbound et dnsmasq, donc la configuration m’a pris un peu de temps. C’est très stable, utilisable aussi sur mobile ou sur de vieux appareils, et aussi comme résolveur pour unbound, adguard/dnsproxy ou le resolve.conf local
    • Je me demande pourquoi mettre en cache à l’avance. Si c’est pour la vitesse, on parle au maximum de 30 à 50 ms, non ? Je me demande aussi si, lorsque le TTL du serveur faisant autorité est inférieur à 60 minutes, tu le forces à 3600
      Je me demande si tu audites les connexions de tous les sites que tu visites pour récupérer jusqu’aux domaines qui hébergent leurs assets et tout prémettre en cache, ou si seuls les domaines principaux des sites, qui ont le plus d’impact sur la latence ressentie, comptent vraiment
    • Unbound dispose de prefetch, qui renouvelle les enregistrements en cache proches de l’expiration, ainsi que de plusieurs options d’ajustement liées au cache et au TTL. serve-expired semblait aussi bien fonctionner
    • Je me demande à quoi ressemble concrètement « je mets en cache à l’avance, toutes les heures via cron, tous les domaines que j’utilise fréquemment ». Est-ce un script shell qui interroge une liste de noms d’hôte, et quel est le critère pour définir les « domaines utilisés » ?
    • Ici aussi, je fais tourner Unbound. J’aime le fait de pouvoir utiliser des wildcards pour bloquer des domaines. J’utilise une grande liste de blocage, avec une liste d’exceptions par-dessus
      J’ai aussi un petit outil qui simplifie des entrées comme ayt7.ads.acme.com, afi6.ads.acme.com, foi5.ads.acme.com en ads.acme.com
      J’ai également un script qui génère des variantes des domaines que j’utilise. Par exemple, si le domaine légitime est mybank.com, il bloque myb4nk.com, mibank.com, mybank.{tous les autres TLD}, etc.
      Je génère ainsi des centaines de milliers de variantes et je les bloque toutes dans Unbound. J’ai mis cela en place après que ma banque m’a envoyé un exemple de site de phishing très convaincant
      J’utilise cette configuration depuis des années, et même un million de domaines bloqués tournent bien sur un vieux Pi 3. Avec une machine plus puissante, Unbound pourrait probablement gérer des listes de blocage de plusieurs millions, voire peut-être de dizaines de millions de domaines. Je ne suis pas encore passé à une approche uniquement fondée sur une liste d’autorisation
      Je bloque aussi tous les domaines Unicode. Les domaines dont le nom contient des caractères Unicode ne sont pas accessibles, et cela ne me dérange pas

  • J’utilise NextDNS avec satisfaction. Il y a beaucoup de possibilités de configuration : quelles listes de filtres activer, comment gérer les logs, etc.
    C’est fiable et rapide presque partout. C’est plus difficile à obtenir en exploitant soi-même un résolveur dans le cloud, et de toute façon je n’ai pas envie d’en assurer la maintenance

    • Moi aussi, j’utilise NextDNS avec satisfaction. Surtout après avoir bricolé Pi-hole pendant des années et m’être lassé de la maintenance. Il s’utilise aussi facilement avec Mullvad VPN quand j’en ai besoin
    • Pour moi aussi, c’était plutôt pas mal

  • Je ne comprends pas pourquoi il n’y en a que 29
    L’auteur veut-il dire que c’est à peu près le nombre réel de résolveurs ouverts sur Internet aujourd’hui ?
    Je me demande comment on peut envisager la « confidentialité » ou la « sécurité » du DNS sans prendre aussi en compte le SNI
    Le SNI permet à un tiers de voir à quel nom de domaine un utilisateur essaie de se connecter, à une adresse publique, et permet aussi d’entraver cette connexion
    Le DNS permet seulement à un tiers de voir pour quel nom de domaine un utilisateur recherche une adresse publique. Pour relier du trafic non DNS à cette requête, il faut faire des hypothèses sur le fonctionnement du logiciel concerné
    Il n’est donc pas surprenant que les sociétés publicitaires qui dominent les navigateurs Web populaires veuillent que les utilisateurs choisissent DoH dans leur navigateur, ou dans des systèmes d’exploitation d’entreprise. En appelant cela de façon trompeuse « DNS privé », un tiers peut corréler plus efficacement les requêtes avec le trafic non DNS des logiciels exécutés dans le navigateur ou sur le système d’exploitation d’entreprise
    De telles affirmations trompeuses pourraient donner lieu à des procès. Par exemple, des utilisateurs ont déjà gagné en justice au sujet d’affirmations trompeuses autour de la « navigation privée »

    • Ces 29 services sont ceux auxquels beaucoup de gens accordent une certaine confiance pour leur confier leurs requêtes DNS. De plus, ces 29 services publient des informations sur les caractéristiques du service
      Si vous lisez toute la page, d’autres résolveurs DNS publics dignes d’être mentionnés sont également listés séparément
      Pour la longue traîne des résolveurs DNS ouverts peu connus, vous pouvez utiliser Shodan. Cela dit, je ne recommanderais pas de faire confiance à ce qu’on trouve sur Shodan au point de lui confier son accès à Internet
      Le SNI est bien un problème général de confidentialité sur Internet, mais ce n’est pas une propriété du DNS. Du côté positif, ECH a été validé par l’IETF et sera progressivement proposé aux utilisateurs ordinaires
      — l’auteur
    • En dehors de quelques sites de « test », ECH n’est pas largement disponible pour les internautes ordinaires
      Il n’est pas clair non plus à qui renvoie le « vous » dans la réponse de l’auteur
      Dans mon cas, je n’utilise le DNS distant que lorsque je récupère périodiquement des données DNS en masse. Quand j’accède à un serveur HTTP, je n’effectue pas de requête DNS distante. Je dispose déjà des informations d’adresses IP nécessaires, et cette méthode est plus rapide et plus fiable
      Je charge en mémoire, dans un proxy forward TLS local, des données DNS en masse provenant de plusieurs sources
      Tous les utilisateurs sont différents, et chacun doit réfléchir par lui-même

  • Pour les utilisateurs au Canada, la CIRA exploite un résolveur public via IPv4, IPv6, DoH et DoT
    https://www.cira.ca/en/canadian-shield/configure/summary-cir...

    • Je ne vois pas pourquoi les Canadiens devraient faire davantage confiance à la CIRA qu’à d’autres alternatives. Cela dit, c’est très probablement mieux que d’utiliser le DNS par défaut de son FAI

  • DNScryptProxy maintient une vaste liste de serveurs DNS publics. Elle indique aussi s’ils prennent en charge DNSSEC, le filtrage et la journalisation
    https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

  • Ce serait bien que ce genre de site fournisse un test de comparaison de vitesse de base depuis le réseau local
    Ce serait utile de pouvoir comparer le temps de réponse P90 et le temps de réponse médian pour des requêtes aléatoires

    • Je suis l’auteur, et je viens de l’ajouter : https://evilbit.de/dns-resolver-guide2.html#speedtest
      En revanche, cela ne fonctionne qu’avec DoH
    • En clonant ce dépôt, puis en modifiant les noms de domaine et les résolveurs comme vous le souhaitez, vous pouvez obtenir un résultat assez proche de ce que vous cherchez
      [1] - https://github.com/cleanbrowsing/dnsperftest
    • J’exécute localement une instance de smokeping pour cet usage. Elle ping plusieurs serveurs DNS, les DNS du FAI et quelques grands sites web, puis met périodiquement à jour les upstreams du serveur DNS local en fonction des résultats
      Dans mon environnement, les grands serveurs DNS sont tous dans la plage de 5 à 6 ms, mais cela n’a pas toujours été le cas. Les DNS du FAI ont une moyenne similaire, mais une forte dispersion et des pics qui montent jusqu’à 50 ms. Et ce, alors qu’ils devraient être les mieux placés pour être les plus rapides

  • Le DNS est un sujet très important pour la confidentialité et la sécurité. Plutôt que de choisir un DNS public, je pense qu’il vaut mieux héberger sa propre infrastructure
    Pas besoin d’instance publique. Il suffit de faire tourner ADGUARD, unbound, dnsmasq ou dnsdist en mode récursif sur son routeur ou une machine
    On peut aussi configurer des restrictions et des listes de blocage selon ses besoins

    • Malgré tout, le FAI peut enregistrer toutes les requêtes