L'association
Un peu de contexte pour commencer. Le résolveur
Pour contourner cette censure, il existe plusieurs méthodes, une
des plus simples étant de changer de résolveur DNS. Beaucoup de gens
utilisent donc des résolveurs DNS
>HEADER<<- opcode: QUERY, status: NOERROR, id: 1575
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
sci-hub.se. 3600 IN A 127.0.0.1
;; Query time: 4 msec
;; SERVER: 212.27.40.240#53(212.27.40.240) (UDP)
;; WHEN: Tue Apr 25 18:43:07 CEST 2023
;; MSG SIZE rcvd: 55
]]>
Il prétend que
>HEADER<<- opcode: QUERY, status: NOERROR, id: 63292
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
sci-hub.se. 60 IN A 186.2.163.219
;; Query time: 156 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Tue Apr 25 18:44:39 CEST 2023
;; MSG SIZE rcvd: 55
]]>
Google dit la vérité,
% blaeu-resolve --requested 100 --country FR --type A sci-hub.se
[186.2.163.219] : 44 occurrences
[127.0.0.1] : 40 occurrences
[ERROR: NXDOMAIN] : 6 occurrences
Test #52634681 done at 2023-04-25T16:33:30Z
On voit que la plupart des sondes en France voient la vraie adresse,
les autres étant derrière un résolveur menteur, qui donne la fausse
adresse
Évidemment, si Google Public DNS ne ment pas, il pose d'autres
problèmes, par exemple en matière de
>HEADER<<- opcode: QUERY, status: NOERROR, id: 59004
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
sci-hub.se. 60 IN A 186.2.163.219
;; Query time: 40 msec
;; SERVER: 2001:910:800::12#53(2001:910:800::12) (UDP)
;; WHEN: Tue Apr 25 18:47:09 CEST 2023
;; MSG SIZE rcvd: 55
]]>
Jusqu'à présent, j'ai utilisé le transport par défaut du
La première solution serait d'utiliser
>HEADER<<- opcode: QUERY; status: NOERROR; id: 30070
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; QUESTION SECTION:
;; sci-hub.se. IN A
;; ANSWER SECTION:
sci-hub.se. 60 IN A 186.2.163.219
;; Received 55 B
;; Time 2023-04-25 20:04:34 CEST
;; From 2001:910:800::12@853(TCP) in 84.4 ms
]]>
C'est parfait, tout marche. Comme vous le voyez au début, la session
>HEADER<<- opcode: QUERY; status: NOERROR; id: 0
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; QUESTION SECTION:
;; sci-hub.se. IN A
;; ANSWER SECTION:
sci-hub.se. 60 IN A 186.2.163.219
;; Received 55 B
;; Time 2023-04-25 20:07:21 CEST
;; From 2001:910:800::12@443(TCP) in 105.4 ms
]]>
On voit qu'une requête
J'ai un peu triché, car, en fait, kdig n'avait pas
authentifié. Puisque DoT et DoH reposent tous les deux sur TLS,
utilisons un client TLS pour regarder le certificat, ici celui de
% gnutls-cli -p 853 2001:910:800::12
...
Connecting to '2001:910:800::12:853'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `CN=resolver0.fdn.fr', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x049a52af0442ad4f67002cf0364cf0aa91b4, EC/ECDSA key 384 bits, signed using RSA-SHA256, activated `2023-04-18 01:00:20 UTC', expires `2023-07-17 01:00:19 UTC', pin-sha256="v8ossDNfX0Qzzo0LfmRdOotuOJJU7lfESpLIetzFseM="
...
Le certificat a été émis par
Notez également qu'il n'est pas du tout indispensable d'utiliser
un résolveur public, vous pouvez avoir votre propre résolveur. Vous
maximisez ainsi le contrôle sur la résolution de noms. Mais
attention : si avoir votre propre résolveur résout le problème de la
censure, il ne protège pas votre vie privée, les requêtes sortant en
clair (tout au plus peut-on dire que, pour le FAI, regarder le
trafic de son résolveur est plus facile que d'analyser le trafic
réseau). Si on veut en plus protéger sa vie privée, une solution
intéressante est de combiner les deux méthodes : avoir son propre
résolveur
policy.add(policy.all(policy.TLS_FORWARD({{'2001:910:800::12', hostname='ns0.fdn.fr'}})))
Et avec
forward-zone:
name: "."
forward-addr: 2001:910:800::12@853
forward-tls-upstream: yes
Normalement, Unbound authentifie le serveur DoT distant si on ajoute
son nom (
On peut aussi tester les résolveurs de FDN avec les sondes RIPE Atlas, puisqu'elle
savent faire du DoT (mais pas du DoH) :
% blaeu-resolve --tls --nameserver=2001:910:800::40 --requested 100 --country FR --type A sci-hub.se
Nameserver 2001:910:800::40
[186.2.163.219] : 92 occurrences
Test #52639363 done at 2023-04-25T18:41:38Z
C'est parfait, tout a marché.
Outre la solution d'avoir un résolveur local qui fait suivre à un
résolveur public comme celui de FDN, vous pouvez aussi utiliser
directement celui de FDN sur les terminaux comme expliqué dans
la documentation d'ARN. Voici par exemple une copie d'écran
sur
Une fois qu'il a été configuré ainsi,
l'
20:15:28.914148 IP6 2a01:e34:dada:e1d0:7f67:9eba:979e:eb57.37376 > 2001:910:800::16.853: Flags [S], seq 2407640807, win 65535, options [mss 1220,sackOK,TS val 8904059 ecr 0,nop,wscale 9,tfo cookiereq,nop,nop], length 0
20:15:28.917330 IP6 2001:910:800::16.853 > 2a01:e34:dada:e1d0:7f67:9eba:979e:eb57.37376: Flags [S.], seq 3248346207, ack 2407640808, win 64260, options [mss 1420,sackOK,TS val 4084487123 ecr 8904059,nop,wscale 9], length 0
20:15:28.918686 IP6 2a01:e34:dada:e1d0:7f67:9eba:979e:eb57.37376 > 2001:910:800::16.853: Flags [.], ack 1, win 143, options [nop,nop,TS val 8904059 ecr 4084487123], length 0
20:15:28.919074 IP6 2a01:e34:dada:e1d0:7f67:9eba:979e:eb57.37376 > 2001:910:800::16.853: Flags [P.], seq 1:518, ack 1, win 143, options [nop,nop,TS val 8904059 ecr 4084487123], length 517
20:15:28.921301 IP6 2001:910:800::16.853 > 2a01:e34:dada:e1d0:7f67:9eba:979e:eb57.37376: Flags [.], ack 518, win 126, options [nop,nop,TS val 4084487127 ecr 8904059], length 0
20:15:28.921923 IP6 2001:910:800::16.853 > 2a01:e34:dada:e1d0:7f67:9eba:979e:eb57.37376: Flags [P.], seq 1:230, ack 518, win 126, options [nop,nop,TS val 4084487128 ecr 8904059], length 229
20:15:28.922704 IP6 2a01:e34:dada:e1d0:7f67:9eba:979e:eb57.37376 > 2001:910:800::16.853: Flags [.], ack 230, win 143, options [nop,nop,TS val 8904060 ecr 4084487128], length 0
tcpdump voit qu'il y a une connexion, pourrait découvrir que c'est
du TLS, mais évidemment pas savoir quel(s) était(ent) le(s) nom(s)
de domaine demandé(s).