Avoir de bonnes résolutions, c’est important

Préambule

Cet article est né du constat que plein de gens, pour plein de bonnes raisons, ne savent pas vraiment comment fonctionne la résolution des noms et adresses IP sur les équipements. Du coup, l’annonce de Cloudflare sur 1.1.1.1 (et dans une certaine mesure celle plus ancienne de Quad9) fait se poser plein de questions sur les performances et la gestion de la vie privée sur ces aspects.

J’essaie donc — comme sur Twitter 1 début avril — d’expliquer du mieux possible tout ça. Comme d’habitude, le diable est dans les détails et si l’offre Cloudflare est intéressante, il ne faut pas faire les choses à moitié.

Rappel sur la résolution

Je ne parlerai pas du protocole DNS et de comment il fonctionne, certains comme Stéphane Bortzmeyer et les documents de référence s’y prennent mieux que moi.

Quand une application ou votre système d’exploitation essaie de résoudre un nom ou une adresse IP, il est fait appel à un bout de code appelé en anglais “stub resolver”. Chaque application intégre ce code d’une manière ou d’une autre.

Ce code, configuré d’une manière assez spécifique selon les systèmes (/etc/resolv.conf ou équivalent sur les systèmes UNIX/Linux 2 & macOS, un service ou une clé de registre sous Windows) pour savoir à qui s’adresser pour discuter. Ce programme / serveur / service va après suivre le processus classique de résolution en discutant avec les serveurs racines, puis les serveurs intermédiaires, etc. jusqu’à obtention du résultat final.

Points à retenir

  • par défaut, tous ces allez-retours entre services / démons / programmes / bibliothèques se fait « en clair ». Le trafic n’est pas chiffré du tout, au mieux, si on utilise un resolver validant, on aura l’authenticité des réponses via DNSSEC 3 ;
  • dans l’immense majorité des cas, les resolvers DNS sont configurés automatiquement au travers d’un protocole appelé DHCP, parfois il est même compliqué voire impossible de changer ceux utilisés par la box (Android non rooté, 9box, etc.) ;
  • ça peut paraître bizarre mais souvent, les resolvers de votre FAI ne sont ni les plus rapides ni les plus corrects. En outre, suite à un ensemble de lois que d’aucuns qualifieraient d’inacceptables, les « gros » FAI comme Orange et Free… mentent. Ils mentent parce que les autorités ont décidé de bloquer certains sites généralement sous le prétexte de terrorisme ou d’incitation à icelui. Le problème étant évidemment que la liste des domaines bloqués est confidentielle et il est donc impossible de vérifier si un blocage est légitime ou pas ;
  • au niveau vie privée on a fait mieux. Votre Fournisseur d’accès peut voir toutes les requètes que vous faites (a fortiori si vous utilisez ses resolvers). Certains FAI ne s’en privent pas (surtout à ma connaissance aux USA) voire, et c’est le cas sur réseau mobile, détournent les flux DNS vers leurs propres serveurs et répondent eux-mêmes à votre place 4 5.

Et 1.1.1.1 dans tout ça ?

Cloudflare a annoncé en fanfare son propre service de résolution le 1er avril — choix de date quelque peu bizarre mais passons :) 6. Cloudflare met l’accent sur les performances, s’appuyant sur son réseau mondial pour faire répondre le serveur le plus proche du requérant et sur les aspects de vie privée, promettant de ne pas garder de journaux, etc. Il vient via deux adresses, 1.1.1.1 et 1.0.0.1, le premier étant apparemment utilisé en loucédé par certains équipements ou fournisseurs ce qui peut obliger à utiliser le deuxième 7. Ily a bien évidemment deux adresses IPv6 correspondantes (2606:4700:4700::1111 et 2606:4700:4700::1001).

Il y a quelques mois, la société Quad9 avait elle-aussi annoncée un service équivalent, lui aussi se targant de mieux respecter la vie privée des internautes (pas de rétention de journaux de fonctionnement, possibilité de chiffrer le trafic au travers de DNS-over-TLS, filtrage de domaines avec du malware, etc.)

Le premier à avoir faire ça étant Google avec ses fameux 8.8.8.8 et 8.8.4.4, resolvers ouverts et validants accessibles partout dans le monde 8. C’est également avec Google qu’on a vu apparaître la « mode » des adresses IP facilement mémorisables 9. Reconnaissons néanmoins à Google d’avoir augmenté de manière significative le nombre de gens utilisant un resolver validant DNSSEC, 8.8.8.8 le faisant par défaut.

La différence principale que je vois dans l’offre Cloudflare est que comme c’est réalisé en partenariat avec le registre d’adresses IP APNIC (Asie-Pacifique), on peut supposer que ces aspects vie privée vont être plus respectés que ce que l’on pourrait attendre de Google (aucun) ou Quad9 (non vérifiés à ce jour que je sache).

Mais…

Le truc est que l’on délègue la tâche de resolution à un tiers que l’on ne contrôle pas, sans même parler des aspects détournement et trafic en clair.

La suggestion que plein de gens font — à raison — est de faire la résolution… soi-même. C’est assez facile à réaliser pour peu qu’on ait le minimum de connaissance technique et un peu de moyen. Ça consiste à faire tourner son propre service de résolution au travers d’utilitaires comme Unbound, Bind ou encore Knot Resolver.

On peut faire ça sur sa propre machine / routeur ou sur une machine distante (genre, hors de France).

Sauf que ça ne va pas assez loin en soi si on veut vraiment que rien ne soit visible. Le trafic restera en clair, restera interceptable et détournable pour le FAI et les performances risquent de ne pas être au rendez-vous. Ça restera une faille unique (à moins d’avoir plusieurs serveurs) également.

Parlons maintenant des deux aspects :

Performances

Aussi bien Cloudflare que Quad9 et Google résolvent l’aspect performances comme le montre le site DNSPerf, Cloudflare est devant, suivi de près par Quad9 et Google. OpenDNS a aussi son propre service mais je ne suis pas personnellement sûr de la qualité de leur réponse, leur business model étant justement plus sur l’aspect safe et filtré.

Confidentialité

Il existe plusieurs manières de rendre le trafic DNS confidentiel :

  • DNS-over-TLS au travers du RFC-7858 ;
  • DNS-over-HTTPS, toujours au stade de draft cf. Stéphane à l’IETF 101 ;
  • DNSCrypt 10 ;
  • utiliser de manière plus générale le réseau Tor pour protéger l’ensemble de ses navigations.

Notons tout de suite que si la 4ème possibilité (Tor) assure la confidentialité des échanges (pas seulement du DNS), l’impact sur la performance de la navigation est assez important et, pour l’immense majorité des usages, ne concernent que ce qui passe par un navigateur, à moins de tout faire passer par Tor.

Cloudflare permet aussi bien le premier que le deuxième (que je n’ai pas exploré encore), pour l’instant Quad9 ne permet que DNS-over-TLS (mais leur site manque à la fois d’explication et d’information, notamment comment vérifier l’identité du serveur resolver sur son port 853).

Pour un système UNIX/Linux que l’on contrôle, il est possible de configurer DNS-over-TLS mais ça reste un peu compliqué.

La plupart des resolvers actuels ne permettent pas directement de faire du DNS-over-TLS, il faut passer par un étape intermédiaire, le démon stubby. Celui-ci, soit au travers du paquet getdns soit tout seul, est capable de se connecter à de multiples sources extérieures et de répondre à un resolver. Par contre, comme il ne fait pas cache du tout, il faut lui coller un unbound/knot-resolver/bind devant.

Ça donne le schéma suivant :

client -> unbound|knot-resolver|bind -> stubby -> {1.1.1.1,9.9.9.9}

L’intérêt à utiliser plusieurs sources va paraître assez évident, essayer de noyer un peu le trafic entre celles-ci et rendre plus difficile la corrélation entre les requètes 11.

On me signale (merci Yann) un tutoriel pour utiliser unbound en mode DNS-over-TLS sans stubby :

Unbound + DNS-over-TLS

Conclusion

Aucun mécanisme n’est parfait ni aucune solution à tous les problèmes. On a plutôt un ensemble de morceaux qui, mis bout à bout, offre un éventail de mécanismes qui aident, dans leur ensemble à préserver et les performances et le respect de la vie privée. Les avocats du « rien chez un prestataire extérieur » ont des objections tout à fait valables mais pour ce que je peux voir, pas de solution(s) globale(s) à part faire tout soi-même, ce dont on vient de voir les limites.

Ne pas oublier non plus qu’ils s’agit de sociétés de droit américain ce qui, compte tenu de certains événements et de l’avénement de Trump, est clairement un souci 12.

Personnellement, pour à la fois améliorer les performances de résolution (mon FAI a trop de problèmes), je passe par DNS-over-TLS via stubby+unbound connectés à 1.0.0.1/9.9.9.9 et je vais surveiller comment ça fonctionne.

À vous de décider ce qui vous est approprié.

Le site DNSPrivacy donne plein d’informations sur tous les aspects (en anglais).

(merci Stéphane et Nolwenn pour la relecture)

Références

Resolvers

Notes

  1. https://twitter.com/Keltounet/status/980927623529402369 et suivants.

  2. Avec l’avènement de l’horreur appelée systemd qui réécrit (mal) le monde, je finis par ne plus vraiment savoir comment ça fonctionne (ou pas).

  3. DNSSEC est un ensemble d’extensions au DNS classique destiné à générer des signatures électroniques des données présentes dans les zones DNS ce qui permet de s’assurer 1. que la réponse vient bien de la bonne origine et 2. que la réponse n’a pas été altérée en route.

  4. Souvent en renvoyant des réponses tronquées ou sans les signatures DNSSEC.

  5. Je soupçonne d’ailleurs SFR de faire quelque chose d’analogue sur son réseau en « fausse fibre » car j’ai souvent des soucis DNS le week-end et ce même en utilisant mon propre resolver

  6. Ceci étant, il y a un précédent célèbre, Google Mail aka GMail a aussi été annoncé un 1er avril…

  7. Notamment par SFR et RED-by-SFR en France . Devinez quel est mon FAI ?

  8. …modulo les diverses censures de certains pays bien évidemment.

  9. Ça beaucoup été utilisé en Turquie lors des troubles en 2016-2017 où, suite à la censure Internet des autorités, 8.8.8.8 était apparu sur des murs pour rappeler aux gens comment la contourner.

  10. Je connais DNSCrypt de nom mais je n’ai pas encore exploré ses possibilités, surtout comparé aux deux autres.

  11. Il reste encore quelques doutes sur le fait qu’on puisse déduire tout ou partie du trafic même chiffré et le groupe de travail sur DNS-over-TLS réfléchit à améliorer les choses par du padding, etc.

  12. Cloudflare, de par sa position dominante dans les réseaux de distribution de contenus (CDN en anglais), fait un peu trop ce qu’il veut, notamment bloquer/dégrader fortement Tor cf. The Cloudwall.