tag:linuxfr.org,2005:/tags/quad9/publicLinuxFr.org : les contenus étiquetés avec « quad9 »2023-03-08T15:23:08+01:00/favicon.pngtag:linuxfr.org,2005:Bookmark/60562023-03-08T15:23:08+01:002023-03-08T15:23:08+01:00Quad9 VS Sony : le résolveur fait appel<a href="https://www.quad9.net/news/press/quad9-s-opinion-of-the-recent-court-ruling-in-leipzig/">https://www.quad9.net/news/press/quad9-s-opinion-of-the-recent-court-ruling-in-leipzig/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/130536/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/e3ms6vyx/liens/quad9-vs-sony-le-resolveur-fait-appel#comments">ouvrir dans le navigateur</a>
</p>
E3Ms6vyXhttps://linuxfr.org/nodes/130536/comments.atomtag:linuxfr.org,2005:News/382992017-11-17T23:49:56+01:002017-11-19T10:27:47+01:00Quad9, résolveur DNS public, et sécurisé par TLSLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>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 <a href="http://www.bortzmeyer.org/7858.html">RFC 7858</a>).</p>
<p>Alors, le lectorat de <em>LinuxFr.org</em>, é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.</p></div><ul><li>lien nᵒ 1 : <a title="https://linuxfr.org/users/bortzmeyer/journaux/quad9-resolveur-dns-public-et-securise-par-tls" hreflang="fr" href="https://linuxfr.org/redirect/100993">Journal à l’origine de la dépêche</a></li><li>lien nᵒ 2 : <a title="https://www.quad9.net/" hreflang="en" href="https://linuxfr.org/redirect/100994">Le site de référence Quad9</a></li><li>lien nᵒ 3 : <a title="https://www.quad9.net/#/privacy" hreflang="en" href="https://linuxfr.org/redirect/100995">Politique de vie privée de Quad9</a></li><li>lien nᵒ 4 : <a title="https://www.quad9.net/#/faq" hreflang="en" href="https://linuxfr.org/redirect/100996">La FAQ de Quad9</a></li><li>lien nᵒ 5 : <a title="https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby" hreflang="en" href="https://linuxfr.org/redirect/100997">Subby</a></li><li>lien nᵒ 6 : <a title="https://dnsprivacy.org/" hreflang="en" href="https://linuxfr.org/redirect/100998">Le projet DNS privacy</a></li></ul><div><p>Et Quad9, c’est mieux, alors ? D’abord, c’est géré par l’organisme sans but lucratif bien connu <a href="https://www.pch.net/">PCH</a>, qui gère une bonne partie de l’infrastructure du DNS (et qui sont des copains, oui, je suis subjectif).</p>
<p>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).</p>
<p>Question politique, des points à noter :</p>
<ul>
<li>Quad9 s’engage à ne pas stocker votre adresse IP ;</li>
<li>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.</li>
</ul><p>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 distribution GNU/Linux favorite :</p>
<pre><code>% 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
</code></pre>
<p>On y voit que Quad9 valide avec DNSSEC (la réponse a bien le bit AD — <em>Authentic Data</em>).</p>
<p>Maintenant, testons la nouveauté importante de ce service : DNS sur TLS. C’est du TLS, donc on peut y aller avec <code>openssl</code> :</p>
<pre><code>% openssl s_client -connect \[2620:fe::fe\]:853 -showcerts
</code></pre>
<p>On voit que Quad9 répond bien en TLS et a un certificat <em>Let’s Encrypt</em>.</p>
<p>Testons ensuite avec un client DNS, le programme <code>getdns_query</code> distribué avec getdns (l’option <code>-l L</code> lui dit d’utiliser DNS sur TLS) :</p>
<pre><code>% getdns_query @9.9.9.9 -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">
}
...
</code></pre>
<p>On peut utiliser <code>tshark</code> pour vérifier qu’on est bien en TLS :</p>
<pre><code>% tshark -n -i eth0 -d tcp.port==853,ssl host 9.9.9.9
</code></pre>
<p>Le <code>-d tcp.port==853,ssl</code> é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é.</p>
<p>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 :</p>
<pre><code>listen_addresses:
- 0::1@8053
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"
</code></pre>
<p>On indique à stubby d’écouter sur l’adresse locale <code>::1</code>, port 8053, et de faire suivre les requêtes en DNS sur TLS à <code>9.9.9.9</code> ou <code>2620:fe::fe</code>. On lance stubby :</p>
<pre><code>% stubby
</code></pre>
<p>Et on peut le tester, en utilisant <code>dig</code> pour interroger à l’adresse et au port indiqué :</p>
<pre><code>% 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 216.157.88.24
;; Query time: 974 msec
;; SERVER: ::1#8053(::1)
;; WHEN: Thu Nov 16 20:29:26 +08 2017
;; MSG SIZE rcvd: 77
</code></pre>
<p>Et on peut vérifier avec tshark que Stubby parle bien avec Quad9, et en utilisant TLS.</p>
<p>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 :</p>
<pre><code>server:
interface: 127.0.0.1
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: ::1@8053
</code></pre>
<p>Avec cette configuration, Unbound va écouter sur l’adresse de bouclage <code>127.0.0.1</code> (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 (<code>::1</code>, port 8053). Interrogeons Unbound :</p>
<pre><code>% 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 185.167.17.10
;; 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
</code></pre>
<p>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é.</p></div><div><a href="https://linuxfr.org/news/quad9-resolveur-dns-public-et-securise-par-tls.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/113123/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/quad9-resolveur-dns-public-et-securise-par-tls#comments">ouvrir dans le navigateur</a>
</p>
Stephane BortzmeyerDavy DefaudZeroHeureFlorent ZaraNils RatusznikBenoît Sibaudhttps://linuxfr.org/nodes/113123/comments.atomtag:linuxfr.org,2005:Diary/375892017-11-16T15:04:13+01:002017-11-16T15:04:13+01:00Quad9, résolveur DNS public, et sécurisé par TLSLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>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 <a href="http://www.bortzmeyer.org/7858.html">RFC 7858</a>).</p>
<p>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.</p>
<p>Et Quad9, c'est mieux, alors ? D'abord, c'est géré par l'organisme sans but lucratif bien connu <a href="https://www.pch.net/">PCH</a>, qui gère une bonne partie de l'infrastructure du DNS (et qui sont des copains, oui, je suis subjectif), </p>
<p>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).</p>
<p>Question politique, des points à noter :</p>
<ul>
<li>Quad9 s'engage à ne pas stocker votre adresse IP,</li>
<li>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.</li>
</ul><p>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 :</p>
<pre><code>% 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
</code></pre>
<p>On y voit que Quad9 valide avec DNSSEC (la réponse a bien le bit AD - Authentic Data).</p>
<p>Maintenant, testons la nouveauté importante de ce service, DNS sur TLS. C'est du TLS donc on peut y aller avec openssl :</p>
<pre><code>% openssl s_client -connect \[2620:fe::fe\]:853 -showcerts
</code></pre>
<p>On voit que Quad9 répond bien en TLS, et a un certificat Let's Encrypt.</p>
<p>Testons ensuite avec un client DNS, le programme getdns_query distribué avec getdns (l'option -l L lui dit d'utiliser DNS sur TLS) :</p>
<pre><code>% getdns_query @9.9.9.9 -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">
}
...
</code></pre>
<p>On peut utiliser tshark pour vérifier qu'on est bien en TLS :</p>
<pre><code>% tshark -n -i eth0 -d tcp.port==853,ssl host 9.9.9.9
</code></pre>
<p>Le <code>-d tcp.port==853,ssl</code> é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é.</p>
<p>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:</p>
<p>[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.]</p>
<p>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 :</p>
<pre><code>% stubby
</code></pre>
<p>Et on peut le tester, en utilisant dig pour interroger à l'adresse et au port indiqué :</p>
<p>[Idem, quelque chose dans le résultat de dig ne plait pas à LinuxFr]</p>
<p>Et on peut vérifier avec tshark que Stubby parle bien avec Quad9, et en utilisant TLS.</p>
<p>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 :</p>
<p>[Configuration Unbound supprimée pour les mêmes raisons.]</p>
<p>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 :</p>
<p>[Et encore un dig supprimé]</p>
<p>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é.</p>
<p>Pour en savoir plus :<br>
- le <a href="https://www.quad9.net/">site de référence</a><br>
- leur <a href="https://www.quad9.net/#/privacy">politique de vie privée</a><br>
- la <a href="https://www.quad9.net/#/faq">FAQ</a><br>
- l'excellente bibliothèque <a href="https://getdnsapi.net/">getdns</a>, le must pour faire du DNS en C<br>
- <a href="https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby">stubby</a><br>
- et toujours dans la série « les copains et les copines », le <a href="https://dnsprivacy.org/">projet DNS privacy</a>.</p><div><a href="https://linuxfr.org/users/bortzmeyer/journaux/quad9-resolveur-dns-public-et-securise-par-tls.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/113112/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/bortzmeyer/journaux/quad9-resolveur-dns-public-et-securise-par-tls#comments">ouvrir dans le navigateur</a>
</p>
Stéphane Bortzmeyerhttps://linuxfr.org/nodes/113112/comments.atom