Quel résolveur DNS public choisir ?

Traditionnellement, le serveur DNS par défaut d’une connexion est donné par le fournisseur d’accès, Orange pour ses abonnements ADSL ou fibre et OVH pour ses serveurs hébergés par exemple (plus de détails sur la définition et le fonctionnement du DNS dans cet article).

Cette habitude a de bons côtés, notamment en termes de facilité d’accès, les équipements étant sur des réseaux forcément mutuellement reconnus. Mais elle a aussi ses inconvénients, que ce soit d’un point de vue technique (disponibilité, performance) ou moral (fiabilité des résultats, confidentialité). Il peut donc paraître souhaitable, voire nécessaire, d’utiliser un résolveur externe, indépendant de notre fournisseur d’accès.

La première solution est d’installer son propre serveur DNS. Cette solution exige d’avoir les connaissances et le matériel adéquats. Une alternative crédible et simple est donc d’utiliser l’un des serveurs DNS publics disponibles gratuitement sur Internet. Ils sont nombreux, aussi en avons-nous sélectionné sept parmi les plus populaires et allons tenter de les comparer afin de vous guider dans la recherche du serveur idéal. Ces serveurs ont été choisis pour leur renommée, parce qu’ils appartiennent à des structures importantes de l’Internet ou parce qu’ils présentent une alternative techniquement crédible à ces grands groupes. À noter que tous les serveurs choisis sont accessibles en IPv4 comme en IPv6.

Ces serveurs sont :

1.1.1.1 (ou 2606:4700:4700::1111) : Issu d’une coopération entre Cloudflare, une société de services Internet, notamment CDN (Content Delivery Network ou réseau de diffusion de contenu) et l’APNIC, l’organisme qui gère la délivrance des adresses IP pour la zone Asie-Pacifique. Détails : https://1.1.1.1/

8.8.8.8 (ou 4860:4860::8888) : Appartient à Google. Détails : https://developers.google.com/speed/public-dns/docs/intro.

9.9.9.9 (ou 2620:fe::fe): Appartient à Quad9, là aussi issue d’une alliance entre IBM, le PCH, une organisation sans but lucratif qui participe à l’architecture du DNS mondial et GCA, une organisation dédiée à la lutte contre la cybercriminalité. Détails : https://www.quad9.net/

80.67.169.12 (ou 2001:910:800::12) : Appartient à FDN, une association française (loi 1901) dont le but est « la promotion, l’utilisation et le développement des réseaux Internet et Usenet dans le respect de leur éthique, en favorisant en particulier les utilisations à des fins de recherche et d’éducation sans volonté commerciale ». Détails : https://www.fdn.fr/

208.67.222.222 (ou 2620:119:35::35) : Appartient à OpenDNS qui a été racheté en 2015 par Cisco. Détails : https://www.opendns.com/

172.104.136.243 (ou 2a01:7e01::f03c:91ff:febc:322) : Appartient à OpenNIC. C’est un réseau associatif à but non lucratif qui propose un serveur racine alternatif à celui d’ICANN. En plus de l’arbre DNS classique, ils proposent donc des noms des domaines de premier niveau (TLD) non disponibles par ailleurs. Détails : https://www.opennic.org/

64.6.64.6 (ou 2620:74:1b::1:1) : Appartient à Verisign, une société américaine qui fournit une partie de l’architecture DNS, notamment deux des treize serveurs racines et gère les TLD « .com » et « .net ». Détails : https://www.verisign.com/en_GB/security-services/public-dns/index.xhtml

Certains de ces services sont en fait en routage Anycast. Les serveurs associés à une IP sont en réalité localisés sur différents sites géographiques et différents réseaux. Les routes Internet empruntées pour accéder à une IP seront distinctes, c’est la machine la plus « proche » qui est utilisée. Cette technologie est très utile pour rendre une connexion vers un service performant, quelle que soit la localisation géographique de l’origine de la requête.

Performances

Le premier critère testé est la performance de ces serveurs. Le protocole est des plus simples : Depuis quatre serveurs hébergés sur les réseaux de grands opérateurs français, nous allons tester périodiquement les temps de réponse à des requêtes vers certains des sites les plus visités en France. En voici la liste : free.fr, mappy.com, cdiscount.com, leboncoin.fr, francetvinfo.fr, google.com, orange.fr, fr.wikipedia.org, lemonde.fr et laposte.net.

Le temps mesuré est celui fourni par la commande « dig » et représente le temps de traitement de la requête ainsi que le temps réseau de contacts entre les machines. Ces résultats sont pris sur une période de plusieurs jours et une moyenne globale est faite pour chacun des serveurs DNS testés. Le but est de déterminer un résultat aussi indépendant que possible de la source comme de la cible de la requête, seul compte le temps de réponse du serveur, il sera exprimé en millisecondes. Nous ajoutons la mesure de l’écart-type qui représente la stabilité des temps de réponse.

Tableau des délais de réponse (en ms) :

Tableau des écarts-types (en ms) :

FDN, Google et Cloudflare forment le peloton de tête, avec des temps de réponse et des écarts-types très réduits. Ils sont suivis de près par OpenDNS. OpenNIC et Verisign viennent ensuite avec des résultats plus lents, mais relativement stables. Enfin, Quad9 se révèle le moins rapide et le moins fiable de ce test.

Confidentialité et exploitation des données

Il est important de noter que tous ces services sont gratuits. On peut donc se demander l’intérêt qu’ont les acteurs à les proposer. Ils engendrent un effet un coût non négligeable (serveurs, bande passante, maintenance).

Pour certains fournisseurs, le résolveur DNS s’intègre dans une offre de services plus globale. C’est le cas d’OpenDNS (Cisco Umbrella), Verisign, Cloudflare et, en partie Google.

Certains fournisseurs exploitent les données, fussent-elles anonymisées, de navigation. Elles leur sont très précieuses afin d’alimenter les bases de données qui permettent de comprendre et de prévoir les usages ainsi que les domaines et sites fréquentés.

C’est le cas pour Verisign, Cloudflare, Google et Quad9 qui, dans leurs conditions d’utilisation, indiquent exploiter les données dans le cadre de l’amélioration de leur architecture, mais aussi à des fins de statistiques ou de marketing. On peut aussi constater que ces sociétés s’autorisent à partager les données, une fois anonymisées (pas d’adresse IP émettrice), avec leurs partenaires.

Deux autres entités ont des politiques plus floues. OpenDNS et FDN ne présentent aucun document explicitant le traitement des données, personnelles ou non, de leur DNS. Le choix ici est donc un problème de confiance. À noter que FDN et OpenNIC sont des associations sans but lucratif, gérées en grande partie par leurs propres utilisateurs. Elles ont donc naturellement moins d’enjeux à exploiter et/ou revendre ces informations. On peut tout de même regretter ce manque de clarté.

Enfin, notons que chacun de ces organismes agit sous le contrôle des lois de son pays.

Quad9 : Berkeley – Californie – USA
Cloudflare : San Francisco – Californie – USA
Google : Mountain View – Californie – USA
Cisco : San José – Californie – USA
Verisign : Reston – Virginie – USA
FDN : Saint-Avé – France – Europe

OpenNIC est un cas à part, ce n’est pas une entité en soi, mais un réseau associatif. La production de logs contenant les informations personnelles des utilisateurs dépend donc du serveur utilisé. La liste disponible sur le site permet de choisir un serveur suivant sa configuration, notamment sa gestion des données. Le serveur sélectionné pour ce comparatif (172.104.136.243) assure ne conserver aucun log, ni aucune information personnelle. Il est situé à Frankfurt, en Allemagne.

Filtrage DNS

Le filtrage DNS est la pratique consistant à modifier intentionnellement la réponse des serveurs DNS (pour bloquer l’accès à un site). Le serveur n’enverra donc pas la vraie adresse résolue, mais une autre information, soit une page d’avertissement, soit une adresse locale, soit un code d’erreur. Ceci permet des fonctions de contrôle parental, mais aussi de contrôle d’accès aux sites considérés comme dangereux, promoteurs de malwares ou de menaces. L’AFNIC, l’association française qui gère notamment les noms de domaine en « .fr » considère que le filtrage DNS est une mauvaise pratique (voir le rapport de 2013). Il n’en reste pas moins que c’est un service qui est parfois proposé par les fournisseurs de services. C’est le cas pour OpenDNS (208.67.222.222) qui permet d’accéder à différents niveaux de filtrages ainsi que la possibilité d’ajouter des domaines manuellement, c’est le seul service qui permet ce paramétrage, au prix de la création d’un compte utilisateur et d’un enregistrement du réseau/adresse IP concerné auprès de la plateforme.

Quad9 (9.9.9.9) de son côté bloque aussi les sites considérés comme frauduleux, la liste n’en est pas publique et il ne permet pas de la personnaliser. Google (8.8.8.8) suit la même politique, blocage imposé et non publié, dans des cas « exceptionnels ».

Les quatre autres (1.1.1.1, FDN, le serveur sélectionné d’OpenNIC et Verisign) affirment n’appliquer aucun blocage.

Sécurité

Un des problèmes du DNS est qu’il transite en clair, sans chiffrage, sur le réseau. Il est donc possible pour un attaquant d’intercepter ce trafic et ainsi de récupérer les informations de navigation d’un utilisateur. Pour contrer cette faiblesse, deux techniques existent : DNS-over-TLS et DNS-over-HTTPS. Elles permettent de chiffrer le trafic vers le serveur DNS, mais aussi de l’authentifier, assurant ainsi qu’on s’adresse bien à la machine souhaitée. Hélas, ces implémentations sont encore jeunes et ne sont pas utilisées massivement.

DNS-over-TLS (RFC 7858) est un simple empaquetage du flux DNS dans le protocole de chiffrement TLS, sur le port 853. Hélas ce port est souvent fermé sur les firewall et proxy d’entreprise.

DNS-over-HTTPS (RFC 8484) est la transformation de la requête DNS en flux HTTP qui est ensuite transmise à travers TLS, sur le port 443 comme n’importe quelle requête HTTPS.

Les deux techniques ont le même problème : Sur un système donné, les requêtes DNS ne sont pas toutes faites par un applicatif unique. Certaines applications, notamment Firefox ou Curl, génèrent directement leurs propres requêtes DNS. Il n’est donc pas possible de fournir un client qui pourra modifier globalement la gestion DNS d’un système.

La solution est d’utiliser un serveur local qui sera destinataire de toutes les requêtes des différentes applications. Soit sous la forme d’un proxy qui ne va faire que relayer les requêtes chiffrées vers un « vrai » serveur DNS (par exemple Stubby qui est disponible pour GNU/Linux, MacOS et Windows), soit en utilisant directement un résolveur DNS local léger, type Unbound, celui-ci apportant en plus les fonctions de cache propre au protocole.

À noter que Firefox permet nativement d’utiliser DNS-over-HTTPS, mais cette configuration, ne concerne que le navigateur (les requêtes DNS issues des autres applications, comme la messagerie par exemple, ne seront pas chiffrées). Par défaut, cette implémentation s’adresse aux serveurs de Cloudflare (1.1.1.1) avec un paramétrage annoncé comme plus strict du point de vue confidentialité.

Dans tous les cas, pour DNS-over-TLS comme pour DNS-over-HTTPS, il est nécessaire de fournir à l’application utilisée une URL décrivant les paramètres utilisés par le serveur destinataire : adresse DOH (pour DNS-over-HTTPS) ou DOT (pour DNS-over-TLS).

Comme vous pouvez le constater, la mise en place d’un canal chiffré pour le flux DNS n’est pas aisée. La solution de Firefox est la plus simple (Préférences / Général / Paramètres réseau / Activer le DNS via HTTPS), mais elle ne prendra en compte que le trafic du navigateur. De plus, ce paramétrage est opportuniste, c’est-à-dire que le navigateur tente d’utiliser DNS-over-TLS, mais utilise le DNS non chiffré si la requête échoue. Pour forcer le DNS-over-HTTPS, il faudra modifier la clé « network.trr.mode » en indiquant la valeur « 3 », via l’interface « about:config ». Chrome pour sa part ne permet pas d’exploiter DNS-over-HTTPS pour l’instant, mais un de ses dérivés, Bromite le prend en charge en donnant directement le choix entre les solutions de Cloudflare, Google ou Quad9.

Les seuls services à gérer ces dispositifs sont :

1.1.1.1 – Cloudflare qui propose DNS-over-TLS (cloudflare-dns.com) et DNS-over-HTTPS (https://cloudflare-dns.com/dns-query)

8.8.8.8 – Google qui propose DNS-over-TLS (dns.google) et DNS-over-HTTPS (https://dns.google.com/experimental)

9.9.9.9 – Quad9 propose le DNS-over-TLS (dns.quad9.net) et DNS-over-HTTPS (https://dns.quad9.net/dns-query).

De plus, Cloudflare propose l’utilisation de Encrypted SNI. Le SNI (Server Name Indication) est une extension au protocole TLS qui permet au client de préciser le domaine concerné par sa requête, il est utilisé massivement par l’ensemble des opérateurs. Le défaut de cette technique est que cette indication passe en clair, avant le chiffrement de la connexion. Encrypted SNI permet donc de totalement masquer cette étape, mais est actuellement complexe à mettre en œuvre, seulement disponible dans les dernières versions de Firefox (en modifiant la clé « network.security.esni.enabled » dans « about:config ») et avec Cloudflare. On ne peut qu’espérer que cette solution ne soit plus largement supportée à l’avenir.

Précisons enfin que OpenDNS et OpenNIC proposent l’utilisation de DNSCrypt, un protocole qui fonctionne sur le même principe que DNS-over-TLS, mais il n’est pas formalisé et ne fait pas partie des outils issus de l’IETF (l’organisme qui gère et promeut les standards d’Internet).

Au final, aucune de ces solutions n’est totalement satisfaisante, elles sont soit complexes à mettre en place, soit partielles. On ne peut qu’espérer que des solutions émergent pour permettre un déploiement plus large.

Synthèse et conclusion

Tableau de synthèse technique des solutions présentées :

Tableau de synthèse des fonctionnalités et informations des différents services présentés :

Il est difficile de désigner un vainqueur concernant le choix d’un résolveur DNS. Il va dépendre des critères propres à chacun. Si vous souhaitez un filtrage paramétrable, OpenDNS est la solution, si vous cherchez la performance, FDN, Cloudflare ou Google sont en tête. Sur le plan de la confidentialité, le choix va dépendre de la confiance que vous accordez aux différentes sociétés et associations.

On peut néanmoins noter que FDN tire son épingle du jeu et fait parfaitement le poids techniquement face aux mastodontes du secteur. Il ne lui manque que la gestion du chiffrement (en cours d’après leurs projets) et de clairement publier sa politique en matière de confidentialité des données pour être la solution idéale.