URL: https://linuxfr.org/users/bortzmeyer/journaux/quad9-resolveur-dns-public-et-securise-par-tls Title: Quad9, résolveur DNS public, et sécurisé par TLS Authors: Stéphane Bortzmeyer Date: 2017年11月16日T15:04:13+01:00 License: CC By-SA Tags: dns, tls, dnssec, vie_privée et quad9 Score: 42 Le résolveur DNS Quad9 (prononcer « quoi de neuf » en français) a été annoncé aujourd'hui. C'est un résolveur DNS public, mais dont l'originalité est d'être accessible de manière sécurisée, avec TLS (DNS sur TLS est décrit dans le [RFC 7858](http://www.bortzmeyer.org/7858.html)). Alors, l·e·a lect·eur·rice de LinuxFr.org, étant super au courant, va dire « mais des résolveurs DNS publics, il y en a plein ! Pourquoi un de plus ? ». Le plus connu est Google Public DNS mais il en existe beaucoup d'autres, avec des politiques et des caractéristiques techniques diverses. Notamment, tous (à l'exception de Cisco OpenDNS) sont non sécurisés : le lien entre vous et le résolveur est en clair, tout le monde peut écouter, et il n'est pas authentifié, donc vous croyez parler à Google Public DNS mais en fait vous parlez au tricheur que votre FAI a annoncé dans ses réseaux locaux. Et Quad9, c'est mieux, alors ? D'abord, c'est géré par l'organisme sans but lucratif bien connu [PCH](https://www.pch.net/), qui gère une bonne partie de l'infrastructure du DNS (et qui sont des copains, oui, je suis subjectif), Quad9, lui, sécurise par TLS (RFC 7858). Cela permet d'éviter l'écoute par un tiers, et cela permet d'authentifier le résolveur (mais attention je n'ai pas encore testé ce point, Quad9 ne semble pas distribuer de manière authentifiée ses clés publiques). Question politique, des points à noter : - Quad9 s'engage à ne pas stocker votre adresse IP, - leur résolveur est un résolveur menteur : il ne répond pas (délibérement) pour les noms de domaines considérant comme lié à des activités néfastes comme la distribution de logiciel malveillant. L'adresse IPv4 de Quad9, comme son nom l'indique, est 9.9.9.9. Son adresse IPv6 est 2620:fe::fe. D'abord, un accès classique en UDP en clair, sur votre Linux favorite : % dig +nodnssec @9.9.9.9 AAAA irtf.org ; <> DiG 9.10.3-P4-Ubuntu <> +nodnssec @9.9.9.9 AAAA irtf.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11544 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;irtf.org. IN AAAA ;; ANSWER SECTION: irtf.org. 1325 IN AAAA 2001:1900:3001:11::2c ;; Query time: 4 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) ;; WHEN: Thu Nov 16 09:49:41 +08 2017 ;; MSG SIZE rcvd: 65 On y voit que Quad9 valide avec DNSSEC (la réponse a bien le bit AD - Authentic Data). Maintenant, testons la nouveauté importante de ce service, DNS sur TLS. C'est du TLS donc on peut y aller avec openssl : % openssl s_client -connect \[2620:fe::fe\]:853 -showcerts On voit que Quad9 répond bien en TLS, et a un certificat Let's Encrypt. Testons ensuite avec un client DNS, le programme getdns_query distribué avec getdns (l'option -l L lui dit d'utiliser DNS sur TLS) : % getdns_query @9.9.9.9 -s -l L www.afnic.fr AAAA { "answer_type": GETDNS_NAMETYPE_DNS, "canonical_name": , "just_address_answers": [ { "address_data": , "address_type": } ... On peut utiliser tshark pour vérifier qu'on est bien en TLS : % tshark -n -i eth0 -d tcp.port==853,ssl host 9.9.9.9 Le `-d tcp.port==853,ssl` était là pour dire à tshark d'interpréter ce qui passe sur le port 853 (celui de DNS-sur-TLS) comme étant du TLS. On voit bien le dialogue TLS mais évidemment pas les questions et réponses DNS puique tout est chiffré. Bien, maintenant que les tests se passent bien, comment utiliser Quad9 pour la vraie résolution de noms ? On va utiliser stubby pour parler à Quad9. Le fichier de configuration Stubby sera du genre: [En fait, je ne peux pas le mettre, LinuxFr interprète son contenu et f...e en l'air tout le maraquage. Il va falloir que vous me croyiez sur parole.] On indique à stubby d'écouter sur l'adresse locale ::1, port 8053, et de faire suivre les requêtes en DNS sur TLS à 9.9.9.9 ou 2620:fe::fe. On lance stubby : % stubby Et on peut le tester, en utilisant dig pour interroger à l'adresse et au port indiqué : [Idem, quelque chose dans le résultat de dig ne plait pas à LinuxFr] Et on peut vérifier avec tshark que Stubby parle bien avec Quad9, et en utilisant TLS. Stubby a l'avantage de bien gérer TCP, notamment en réutilisant les connexions (il serait très coûteux d'établir une connexion TCP pour chaque requête DNS, surtout avec TLS par dessus). Mais il n'a pas de cache des réponses, ce qui peut être ennuyeux si on est loin de Quad9. Pour cela, le plus simple est d'ajouter un vrai résolveur, ici Unbound. On le configure ainsi : [Configuration Unbound supprimée pour les mêmes raisons.] Avec cette configuration, Unbound va écouter sur l'adresse 127.0.0.1 (sur le port par défaut, 53, le port du DNS) et relayer les requêtes pour lesquelles il n'a pas déjà une réponse dans son cache vers Stubby (::1, port 8053). Interrogeons Unbound : [Et encore un dig supprimé] Unbound a une mémoire (le cache) donc si on recommance la requête aussitôt, la réponse arrivera bien plus vite et on verra le TTL diminué. Pour en savoir plus : - le [site de référence](https://www.quad9.net/) - leur [politique de vie privée](https://www.quad9.net/#/privacy) - la [FAQ](https://www.quad9.net/#/faq) - l'excellente bibliothèque [getdns](https://getdnsapi.net/), le must pour faire du DNS en C - [stubby](https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby) - et toujours dans la série « les copains et les copines », le [projet DNS privacy](https://dnsprivacy.org/).

AltStyle によって変換されたページ (->オリジナル) /