Afficher/cacher Sommaire
quad9 résolveur DNS public + TLS + outils (dnsutils getdns-utils tshark)
Quad9 (prononcer « quoi de neuf » en français) 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).
Comment fonctionne Quad9
Quad9 achemine vos requêtes DNS à travers un réseau sécurisé de serveurs dans le monde entier. Le système utilise les renseignements sur les menaces provenant de plus d’une douzaine de sociétés de cybersécurité parmi les plus importantes de l’industrie pour donner une perspective en temps réel sur les sites Web sécuritaires et sur les sites connus pour contenir des logiciels malveillants ou d’autres menaces. Si le système détecte que le site que vous voulez atteindre est connu pour être infecté, vous serez automatiquement bloqué d’entrée - gardant vos données et votre ordinateur en sécurité.
Outils
sudo apt install dnsutils getdns-utils tshark
L’adresse IPv4 de Quad9 est 9.9.9.9 ,son adresse IPv6 est 2620:fe::fe
Accès classique en UDP en clair
dig +nodnssec @9.9.9.9 AAAA cinay.xyz
; <<>> DiG 9.10.3-P4-Debian <<>> +nodnssec @9.9.9.9 AAAA cinay.xyz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38337
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cinay.xyz. IN AAAA
;; ANSWER SECTION:
cinay.xyz. 3600 IN AAAA 2001:41d0:305:2100::4dc0
;; Query time: 286 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sun Jan 06 14:12:38 CET 2019
;; MSG SIZE rcvd: 66
Quad9 valide DNSSEC (la réponse a bien le bit AD - Authentic Data).
Si le domaine est sur la liste noire de Quad9 il répond NXDOMAIN (No Such Domain, ce domaine n’existe pas)
dig @9.9.9.9 www.hjaoopoa.top
; <<>> DiG 9.10.3-P4-Debian <<>> @9.9.9.9 www.hjaoopoa.top
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37000
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.hjaoopoa.top. IN A
;; Query time: 6 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sun Jan 06 14:21:23 CET 2019
;; MSG SIZE rcvd: 45
Avec un résolveur non-menteur, on aurait eu le code de retour NOERROR et l’adresse IP 54.213.138.248.
DNS sur TLS (RFC 7858) avec openssl
openssl s_client -connect \[2620:fe::fe\]:853 -showcerts
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = California, L = Berkeley, O = Quad9, CN = *.quad9.net
verify return:1
---
Certificate chain
0 s:C = US, ST = California, L = Berkeley, O = Quad9, CN = *.quad9.net
i:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
1 s:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Berkeley, O = Quad9, CN = *.quad9.net
issuer=C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: ECDSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2965 bytes and written 439 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES256-GCM-SHA384
Session-ID: 8AD8B23C
[...]
Quad9 répond en TLS, et a un certificat DigiCert Inc
Testons ensuite avec un client DNS, le programme getdns_query (getdns-utils)
getdns_query @9.9.9.9 -s -l L cinay.xyz AAAA
SYNC response:
{
"answer_type": GETDNS_NAMETYPE_DNS,
"canonical_name": <bindata for cinay.xyz.>,
"just_address_answers":
[
{
"address_data": <bindata for 2001:41d0:305:2100::4dc0>,
"address_type": <bindata of "IPv6">
}
],
utiliser tshark pour vérifier qu’on est bien en TLS :
tshark -n -i ens3 -d tcp.port==853,ssl host 9.9.9.9 # commande terminal 1
getdns_query @9.9.9.9 -s -l L cinay.xyz AAAA # commande sur terminal 2
Capture sur terminal 1
Capturing on 'ens3'
1 0.000000000 51.77.192.45 → 9.9.9.9 TCP 74 42272 → 853 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=718718 TSecr=0 WS=128
2 0.006214217 9.9.9.9 → 51.77.192.45 TCP 74 853 → 42272 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3687251171 TSecr=718718 WS=256
3 0.006244018 51.77.192.45 → 9.9.9.9 TCP 66 42272 → 853 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=718720 TSecr=3687251171
4 0.006580887 51.77.192.45 → 9.9.9.9 TLSv1 355 Client Hello
5 0.013091120 9.9.9.9 → 51.77.192.45 TLSv1.2 1514 Server Hello
6 0.013122870 51.77.192.45 → 9.9.9.9 TCP 66 42272 → 853 [ACK] Seq=290 Ack=1449 Win=32128 Len=0 TSval=718722 TSecr=3687251178
7 0.013166549 9.9.9.9 → 51.77.192.45 TLSv1.2 1521 Certificate, Server Key Exchange, Server Hello Done
8 0.013177943 51.77.192.45 → 9.9.9.9 TCP 66 42272 → 853 [ACK] Seq=290 Ack=2904 Win=35072 Len=0 TSval=718722 TSecr=3687251178
9 0.019036739 51.77.192.45 → 9.9.9.9 TLSv1.2 192 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
10 0.025374353 9.9.9.9 → 51.77.192.45 TLSv1.2 117 Change Cipher Spec, Encrypted Handshake Message
11 0.025637276 51.77.192.45 → 9.9.9.9 TLSv1.2 135 Application Data
12 0.071010394 9.9.9.9 → 51.77.192.45 TCP 66 853 → 42272 [ACK] Seq=2955 Ack=485 Win=30208 Len=0 TSval=3687251236 TSecr=718725
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é.
Pour la vraie résolution de noms ,on utilise stubby pour parler à Quad9.
Stubby
Stubby est une application qui agit en tant que résolveur local de stub DNS Privacy (en utilisant DNS-over-TLS). Stubby crypte les requêtes DNS envoyées depuis une machine cliente (ordinateur de bureau ou portable) vers un résolveur de confidentialité DNS, augmentant ainsi la confidentialité de l’utilisateur final.
- Quad9, un résolveur DNS public, et avec sécurité
- Compiler stubby
- DNS Privacy With Stubby (Part 1 GNU/Linux)
Debian 9 “strech” stable actuelle, Stubby dans les getdns-utils de Debian est une version ancienne.
Il faut construire stubby à partir du code source. Installer les paquets requis pour compiler stubby.
sudo apt install build-essential git libtool autoconf libssl-dev libyaml-dev
Installer stubby
git clone https://github.com/getdnsapi/getdns.git # dépôt git getdns
cd getdns
# Verify the lastest release tag
git tag
v1.1.3-rc1
v1.2.0
v1.2.1
v1.2.1-rc1
v1.2.2-rc1
v1.3.0
v1.4.0
v1.4.0-rc1
v1.4.1
v1.4.1-rc1
v1.4.2
v1.4.2-rc1
v1.5.0
v1.5.0-rc1
# la dernière version stable..
git checkout v1.5.0 # ou git checkout master seulement (git tag non utilisé)
git submodule update --init
libtoolize -ci
autoreconf -fi
mkdir -p build
cd build
#../configure --prefix=/usr/local --without-libidn --without-libidn2 --enable-stub-only --with-ssl=/usr/src/nginx-custom/openssl --with-stubby # avec openssl 1.1.1 compilé avec nginx
../configure --prefix=/usr/local --without-libidn --without-libidn2 --enable-stub-only --with-stubby # avec openssl installé par défaut sur debian stretch
make
sudo make install
***
! !! IMPORTANT !!!!!!!
***
Depuis la version 1.2.0, getdns est livré avec DNSSEC intégré.
la gestion des ancres de confiance. Gestion externe de l'ancrage de la confiance,
par exemple avec une ancre non liée, n'est plus nécessaire
et n'est plus recommandé.
***
Ancres de confiance déjà installées, à l'emplacement par défaut -
***
/usr/local/etc/unbound/getdns-root.key
***
- seront préférés et utilisés pour la validation DNSSEC, cependant
getdns se repliera sur les ancres de confiance obtenues par l'intermédiaire de l'interface intégrée.
gestion des ancres de confiance lorsque les ancres de la valeur par défaut
ne parvient pas à valider la réinitialisation DNSKEY racine.
***
Pour éviter que les ancrages de confiance DNSSEC expirés ne soient utilisés pour
validation, nous vous recommandons fortement de retirer les ancres de confiance
sur l'emplacement par défaut lorsqu'il n'y a pas d'adresse externe active
la gestion de l'ancre de confiance en la gardant à jour.
***
Copier le fichier service systemd stubby.service
cd ..
cd stubby/systemd/
sudo cp stubby.service /lib/systemd/system/
Modifier le chemin (path) /usr/local
sudo nano /lib/systemd/system/stubby.service
[Unit]
Description=stubby DNS resolver
Wants=network-online.target
After=network-online.target
[Service]
User=stubby
DynamicUser=yes
CacheDirectory=stubby
WorkingDirectory=/var/cache/stubby
ExecStart=/usr/local/bin/stubby
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
Créer le répertoire de travail de stubby
sudo mkdir /var/cache/stubby
ldconfig ,update cache library
sudo ldconfig -v
Editer le fichier de configuration /usr/local/etc/stubby/stubby.yml
sudo nano /usr/local/etc/stubby/stubby.yml
Mettez à jour le port où stubby écoutera et sélectionnez le service dns amont que vous voulez utiliser.
listen_addresses:
- 127.0.0.1@8053
- 0::1@8053
# https://github.com/getdnsapi/getdns/issues/358
dns_transport_list:
- GETDNS_TRANSPORT_TLS
upstream_recursive_servers:
# Quad9
- address_data: 9.9.9.9
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 à 9.9.9.9 ou 2620:fe::fe. On lance stubby :
Démarrage et test stubby
sudo systemctl list-unit-files | grep -i stubby
stubby.service disabled
sudo systemctl enable stubby
sudo systemctl start stubby
On peut le tester, en utilisant dig pour interroger à l’adresse et au port indiqué :
dig @::1 -p 8053 A cinay.xyz
; <<>> DiG 9.10.3-P4-Debian <<>> @::1 -p 8053 A cinay.xyz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41867
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65535
;; QUESTION SECTION:
;cinay.xyz. IN A
;; ANSWER SECTION:
cinay.xyz. 3600 IN A 51.75.120.106
;; Query time: 307 msec
;; SERVER: ::1#8053(::1)
;; WHEN: Sun Jan 06 20:58:09 CET 2019
;; MSG SIZE rcvd: 63
On peut vérifier avec tshark ou tcpdump que Stubby parle bien avec Quad9, et en utilisant TLS.
utiliser tshark pour vérifier qu’on est bien en TLS :
tshark -n -i ens3 -d tcp.port==8053,ssl host 9.9.9.9 # commande terminal 1
dig @::1 -p 8053 A cinay.xyz # commande terminal 2
; <<>> DiG 9.10.3-P4-Debian <<>> @::1 -p 8053 A cinay.xyz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55630
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65535
;; QUESTION SECTION:
;cinay.xyz. IN A
;; ANSWER SECTION:
cinay.xyz. 3600 IN A 51.75.120.106
;; Query time: 443 msec
;; SERVER: ::1#8053(::1)
;; WHEN: Mon Jan 07 10:59:39 CET 2019
;; MSG SIZE rcvd: 63
Capture sur terminal 1
Capturing on 'ens3'
1 0.000000000 51.77.192.45 → 9.9.9.9 TCP 74 43898 → 853 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=19058767 TSecr=0 WS=128
2 0.006318419 9.9.9.9 → 51.77.192.45 TCP 74 853 → 43898 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3771070357 TSecr=19058767 WS=256
3 0.006356732 51.77.192.45 → 9.9.9.9 TCP 66 43898 → 853 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=19058769 TSecr=3771070357
4 0.006409942 51.77.192.45 → 9.9.9.9 TLSv1 377 Client Hello
5 0.012980052 9.9.9.9 → 51.77.192.45 TLSv1.3 1514 Server Hello, Change Cipher Spec, Application Data
6 0.013007762 51.77.192.45 → 9.9.9.9 TCP 66 43898 → 853 [ACK] Seq=312 Ack=1449 Win=32128 Len=0 TSval=19058770 TSecr=3771070364
7 0.013079164 9.9.9.9 → 51.77.192.45 TLSv1.3 1627 Application Data, Application Data, Application Data
8 0.013088793 51.77.192.45 → 9.9.9.9 TCP 66 43898 → 853 [ACK] Seq=312 Ack=3010 Win=35328 Len=0 TSval=19058771 TSecr=3771070364
9 0.017569594 51.77.192.45 → 9.9.9.9 TLSv1.3 146 Change Cipher Spec, Application Data
10 0.023801313 9.9.9.9 → 51.77.192.45 TLSv1.3 145 Application Data
Si, à ce stade, vous obtenez une réponse DNS FORMERR (FORmat ERRor) au lieu du NOERROR qu’on voit ci-dessus, en cause le bogue et il faut mettre à jour la bibliothèque getdns utilisée par Stubby.
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
Sauvegarde du fichier de configuration unbound existant
mkdir -p $HOME/archives
sudo cp /etc/unbound/unbound.conf.d/dns-yan.conf $HOME/archives/
Modifier la configuration Unbound
sudo nano /etc/unbound/unbound.conf.d/dns-yan.conf
server:
interface: 127.0.0.1
access-control: 127.0.0.0/8 allow
do-not-query-localhost: no
root-hints: "/var/lib/unbound/root.hints"
verbosity: 0 # 0 messages (erreurs uniquement)
num-threads: 2
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
rrset-cache-size: 100m
msg-cache-size: 50m
outgoing-range: 465
so-rcvbuf: 4m
so-sndbuf: 4m
port: 53
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
hide-identity: yes
hide-version: yes
harden-glue: yes
harden-dnssec-stripped: yes
harden-referral-path: yes
use-caps-for-id: yes
prefetch: yes
include: /etc/unbound/unbound.conf.d/adslist.txt
forward-zone:
name: "."
forward-addr: ::1@8053
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 :
Pour vérifier si le fichier de configuration est valide
unbound-checkconf /etc/unbound/unbound.conf.d/dns-yan.conf
Redémarrer le service dnsunbound
systemctl restart unbound
Test
dig @127.0.0.1 A mastodon.gougere.fr
; <<>> DiG 9.10.3-P4-Debian <<>> @127.0.0.1 A mastodon.gougere.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62548
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mastodon.gougere.fr. IN A
;; ANSWER SECTION:
mastodon.gougere.fr. 600 IN A 185.167.17.10
;; Query time: 117 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 07 11:28:50 CET 2019
;; MSG SIZE rcvd: 64
Capture tshark
Capturing on 'ens3'
1 0.000000000 51.77.192.45 → 9.9.9.9 TCP 74 43982 → 853 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=19496655 TSecr=0 WS=128
2 0.006321073 9.9.9.9 → 51.77.192.45 TCP 74 853 → 43982 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3772821907 TSecr=19496655 WS=256
3 0.006372148 51.77.192.45 → 9.9.9.9 TCP 66 43982 → 853 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=19496656 TSecr=3772821907
4 0.006687426 51.77.192.45 → 9.9.9.9 TLSv1 377 Client Hello
5 0.013427733 9.9.9.9 → 51.77.192.45 TLSv1.3 3075 Server Hello, Change Cipher Spec, Application Data, Application Data, Application Data, Application Data
6 0.013496919 51.77.192.45 → 9.9.9.9 TCP 66 43982 → 853 [ACK] Seq=312 Ack=3010 Win=35328 Len=0 TSval=19496658 TSecr=3772821914
7 0.020122279 51.77.192.45 → 9.9.9.9 TLSv1.3 146 Change Cipher Spec, Application Data
8 0.026679979 9.9.9.9 → 51.77.192.45 TLSv1.3 145 Application Data
9 0.026741383 51.77.192.45 → 9.9.9.9 TLSv1.3 346 Application Data
10 0.026780118 9.9.9.9 → 51.77.192.45 TLSv1.3 145 Application Data
11 0.033567105 9.9.9.9 → 51.77.192.45 TLSv1.3 1510 Application Data
12 0.033629574 51.77.192.45 → 9.9.9.9 TCP 66 43982 → 853 [ACK] Seq=672 Ack=4612 Win=38144 Len=0 TSval=19496663 TSecr=3772821928
13 0.047498553 51.77.192.45 → 9.9.9.9 TLSv1.3 346 Application Data
14 0.054209537 9.9.9.9 → 51.77.192.45 TLSv1.3 983 Application Data
15 0.094613125 51.77.192.45 → 9.9.9.9 TCP 66 43982 → 853 [ACK] Seq=952 Ack=5529 Win=41088 Len=0 TSval=19496679 TSecr=3772821955
16 2.055607990 9.9.9.9 → 51.77.192.45 TLSv1.3 90 Application Data
17 2.055645935 51.77.192.45 → 9.9.9.9 TCP 66 43982 → 853 [ACK] Seq=952 Ack=5553 Win=41088 Len=0 TSval=19497169 TSecr=3772823957
18 2.055659650 9.9.9.9 → 51.77.192.45 TCP 66 853 → 43982 [FIN, ACK] Seq=5553 Ack=952 Win=32256 Len=0 TSval=3772823957 TSecr=19496679
19 2.055799482 51.77.192.45 → 9.9.9.9 TLSv1.3 90 Application Data
20 2.055854428 51.77.192.45 → 9.9.9.9 TCP 66 43982 → 853 [FIN, ACK] Seq=976 Ack=5554 Win=41088 Len=0 TSval=19497169 TSecr=3772823957
21 2.062116124 9.9.9.9 → 51.77.192.45 TCP 66 853 → 43982 [ACK] Seq=5554 Ack=977 Win=32000 Len=0 TSval=3772823963 TSecr=19497169