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).
Alors, le lectorat de LinuxFr.org, étant très au fait du sujet, 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, 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érément) pour les noms de domaines qu’il estime liés à des activités néfastes comme la distribution de logiciels malveillants.
L’adresse IPv4 de Quad9, comme son nom l’indique, est 126.96.36.199. Son adresse IPv6 est 2620:fe::fe. D’abord, un accès classique en UDP en clair, sur votre distribution GNU/Linux favorite :
% dig +nodnssec @188.8.131.52 AAAA irtf.org
; <<>> DiG 9.10.3-P4-Ubuntu <<>> +nodnssec @184.108.40.206 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: 220.127.116.11#53(18.104.22.168)
;; 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 @22.214.171.124 -s -l L www.afnic.fr AAAA
{
"answer_type": GETDNS_NAMETYPE_DNS,
"canonical_name": <bindata for lb01-1.nic.fr.>,
"just_address_answers":
[
{
"address_data": <bindata for 2001:67c:2218:30::24>,
"address_type": <bindata of "IPv6">
}
...
On peut utiliser tshark
pour vérifier qu’on est bien en TLS :
% tshark -n -i eth0 -d tcp.port==853,ssl host 126.96.36.199
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 puisque 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 :
listen_addresses:
- 0::1@8053
dns_transport_list:
- GETDNS_TRANSPORT_TLS
upstream_recursive_servers:
# Quad9
- address_data: 188.8.131.52
tls_auth_name: "dns.quad9.net"
- address_data: 2620:fe::fe
tls_auth_name: "dns.quad9.net"
On indique à stubby d’écouter sur l’adresse locale ::1
, port 8053, et de faire suivre les requêtes en DNS sur TLS à 184.108.40.206
ou 2620:fe::fe
. On lance stubby :
% stubby
Et on peut le tester, en utilisant dig
pour interroger à l’adresse et au port indiqué :
% dig @::1 -p 8053 A www.catstuff.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @::1 -p 8053 A www.catstuff.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20910
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65535
;; QUESTION SECTION:
;www.catstuff.com. IN A
;; ANSWER SECTION:
www.catstuff.com. 600 IN A 220.127.116.11
;; Query time: 974 msec
;; SERVER: ::1#8053(::1)
;; WHEN: Thu Nov 16 20:29:26 +08 2017
;; MSG SIZE rcvd: 77
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 :
server:
interface: 127.0.0.1
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: ::1@8053
Avec cette configuration, Unbound va écouter sur l’adresse de bouclage 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 :
% dig @127.0.0.1 A mastodon.gougere.fr
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 A mastodon.gougere.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40668
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;mastodon.gougere.fr. IN A
;; ANSWER SECTION:
mastodon.gougere.fr. 600 IN A 18.104.22.168
;; Query time: 2662 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 16 20:36:09 +08 2017
;; MSG SIZE rcvd: 64
Unbound a une mémoire (le cache). Donc, si l’on recommence la requête aussitôt, la réponse arrivera bien plus vite et on verra le TTL diminué.