1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Titre: Utiliser un résolveur DNS public ?
Auteur:
Date: Sun 15 Jan 2017 01:00:00 +0100
Lien: https://www.bortzmeyer.org/dns-resolveurs-publics.html
Après la censure administrative en France via des DNS menteurs[1], puis une
panne spectaculaire des résolveurs DNS d'Orange[2], au moins trois pannes
analogues de ceux de Free[3], et enfin un détournement accidentel de Google et
Wikipédia vers le Ministère de l'Intérieur[4], pas mal d'utilisat·eur·rice·s de
l'Internet se demandent si on peut vraiment faire confiance au résolveur DNS de
son FAI. Et beaucoup se mettent alors à utiliser un résolveur DNS public, le
plus célèbre étant Google Public DNS[5]. Mais est-ce une bonne idée ?
D'abord, recadrons un peu la terminologie. Le protocole DNS a deux sortes de
serveurs, qui n'ont pas grand'chose à voir, les serveurs faisant autorité et
les résolveurs. Confondre les deux (par exemple en parlant du vague « serveur
DNS ») ne va pas aider l'utilisat·eur·rice à comprendre, et donc à faire des
choix corrects. Les serveurs faisant autorité sont ceux qui connaissent les
informations sur le contenu des domaines. Par exemple, ceux de l'AFNIC
connaissent le contenu de .fr et ceux de CloudFlare, hébergeur utilisé par Next
INpact, connaissent le contenu de nextinpact.com, par exemple l'adresse du site
Web[6] (104.25.248.21 et 104.25.249.21 aujourd'hui). Les résolveurs (on dit
aussi serveurs récursifs, ou bien serveurs caches), eux, ne connaissent rien, à
part l'adresse des serveurs de la racine, où ils commencent leurs
interrogations. Les serveurs faisant autorité sont gérés par des hébergeurs DNS
spécialisés (comme Dyn[7]), ou bien directement par le titulaire du nom de
domaine. Les résolveurs sont typiquement gérés par le service informatique du
réseau où vous vous connectez, ou bien par le FAI, pour les accès grand public.
Ces résolveurs sont une partie cruciale du service d'accès à l'Internet : sans
DNS, il n'y a quasiment rien qui marche. S'ils sont en panne, plus d'Internet.
S'ils mentent[8], on est détourné vers un mauvais site.
On voit depuis des années apparaître des résolveurs DNS publics, qui ne
dépendent ni du FAI, ni du réseau local d'accès. Ce sont Google Public DNS[5],
Cisco OpenDNS[9], FDN[10], OpenNIC[11], Verisign[12], Yandex[13], etc.
Attention à ne pas confondre ces résolveurs publics avec ce qu'on nomme les
résolveurs ouverts. Tous ont en commun qu'ils acceptent de répondre à des
requêtes DNS, quelle que soit leur source. Mais les résolveurs ouverts le sont
par accident, par erreur de configuration, et ne sont pas gérés. Les résolveurs
publics, eux, le sont déliberement, ils sont (normalement...) gérés par des
gens sérieux. La différence est importante car un résolveur ouvert est un outil
utile dans de nombreuses attaques comme les attaques par amplification[14] ou
comme certains empoisonnements[15]. C'est pour cette raison que le RFC 5358
demande que les résolveurs DNS ne soient pas ouverts.
Après ce long préambule, retour aux pannes de résolveurs DNS. Aujourd'hui, dès
qu'un problème Internet survient, et quelle que soit la cause réelle du
problème, la réponse fuse sur tous les rézosocios : « utilise Google DNS » (ou
bien, version libriste, « utilise FDN »). Un exemple, pris au hasard lors de la
dernière panne Free est ce tweet[16]. (Et voici une documentation plus élaborée[17]
.)
Ce genre de conseils ne tient pas compte de plusieurs inconvénients sérieux des
résolveurs publics. Je vais commencer par les inconvénients communs à tous les
résolveurs publics. Le principal est que le lien entre vous et le résolveur
public est long et non sécurisé. Même si vous avez une confiance aveugle dans
le résolveur public et ceux qui le gèrent, sur le trajet, des tas de choses
peuvent aller mal. D'abord, le trafic peut être écouté trivialement (les seuls
résolveurs publics qui proposent une solution à ce problème sont Cisco OpenDNS
et OpenNIC, avec DNSCrypt). Comme le rappelle le RFC 7626, le trafic DNS est
très bavard (trop), circule en clair, passe par des réseaux supplémentaires (en
plus du trafic « normal »), et peut donc poser des problèmes de vie privée.
Avec un résolveur DNS habituel, le problème est limité car le résolveur est
proche de vous, limitant le nombre de gens qui peuvent écouter. Avec un
résolveur public, le nombre d'écoutants potentiels augmente.
Mais il y a pire : la plupart des résolveurs publics n'offre aucune
authentification (là encore, la seule exception est Cisco OpenDNS et OpenNIC,
mais où cette authentification est facultative, et je ne sais pas combien
d'utilisateurs s'en servent réellement). Même les mesures les plus triviales
comme le NSID du RFC 5001 ne sont pas mises en œuvre (NSID ne fait pas une
réelle authentification, mais il permet de détecter certains problèmes). Si
vous utilisez des résolveurs publics pour contourner la censure, c'est un
sérieux problème. Des censeurs ont déjà effectué des détournements de
résolveurs DNS public (comme en Turquie[18], mais aussi dans d'autres pays[19]
). Donc, même si le résolveur public est géré par des gens biens, et que vous
connaissez, cela ne suffit pas, car vous n'avez aucun moyen de savoir si vous
parlez bien à ce résolveur, et pas à un usurpateur (le DNS utilise UDP, qui
n'offre aucune protection contre l'usurpation d'adresse[20]).
Il est amusant (et révélateur du manque de connaissances sur le fonctionnement
de l'Internet) que les débats sur les résolveurs ouverts se focalisent souvent
sur la confiance que l'on peut accorder (ou pas) au serveur, et jamais sur
celle qu'on peut accorder (ou pas) au réseau qui y mène !
Il y a aussi des inconvénients qui sont spécifiques à certains des résolveurs
publics souvent recommandés :
* Je soupçonne que certains ne sont pas si bien gérés que cela (normalement,
ils doivent faire de la limitation de trafic, être supervisés 24 heures sur
24, etc) et peuvent être utilisés pour des attaques par réflexion, avec
amplification[21],
* Google, Cisco et Verisign sont situés aux États-Unis, pays qui n'a aucune
protection des données personnelles, même théorique (argument bien
développé chez Shaft[22]),
* Yandex est en Russie, si vous voulez donner vos informations au FSB plutôt
qu'à la NSA,
* OpenNIC est une racine alternative[23], ce qui veut dire qu'ils ajoutent
des TLD « bidons[24] », qui ne marcheront que chez eux,
* Certains services sont peu fiables, souvent en panne, très lents, ou
disparaissant sans laisser de nouvelles.
Alors, si utiliser les résolveurs publics est une mauvaise idée, quelle est la
bonne ? Le mieux serait évidemment de pouvoir utiliser les résolveurs DNS de
son FAI. Un résolveur DNS correct fait partie (ou devrait faire partie) de
l'offre Internet de base. Les utilisateurs devraient réclamer un tel service,
fiable et rapide. Les pannes récentes, ou bien les horreurs des résolveurs DNS
des points d'accès Wi-Fi des hôtels et des aéroports, et enfin le problème de
la censure étatique (qu'un service de qualité chez le FAI ne résoudra pas) font
qu'il n'y a plus guère le choix, il faut utiliser d'autres résolveurs que ceux
du FAI. La solution la plus propre est d'avoir son propre résolveur DNS[25],
pas forcément sur chaque machine de son réseau local, mais plutôt dans une
machine unique, typiquement le routeur d'accès. Avant qu'on ne me dise « mais
ce n'est pas Michu-compatible, M. Michu ne vas quand même pas installer OpenBSD
sur un Raspberry Pi pour avoir un résolveur sur son réseau », je dis tout de
suite qu'évidemment, cela ne doit pas être fait directement par M. Michu mais
une fois pour toutes dans un paquet logiciel et/ou matériel qu'il n'y a plus
qu'à brancher. (Un truc du genre de la Brique Internet[26].)
Parfois, il est difficile ou peu pratique d'avoir son propre résolveur. En
outre, un résolveur à soi sur le réseau local protège bien contre la censure,
ou contre les pannes, mais peu contre la surveillance, puisqu'il va lui-même
émettre des requêtes en clair aux serveurs faisant autorité. Il est donc utile
d'avoir des résolveurs publics accessibles en DNS-sur-TLS (RFC 7858), ce qui
protège la confidentialité et permet l'authentification du résolveur. Ces
résolveurs publics (comme par exemple celui de LDN[27] ou bien celui de Yeti[28]
) peuvent être utilisés directement, ou bien servir de relais pour le résolveur
local. Attention, la plupart sont encore très expérimentaux. Vous trouverez une
liste sur le portail DNS Privacy[29]. (Pour la solution non normalisée
DNScrypt, on trouve, outre le site Web officiel, la doc de malekalmorte[30] ou
bien celle-ci[31].)
Pour se prémunir contre la censure (mais pas contre les pannes, ni contre la
surveillance), une autre technologie utile est DNSSEC. Le résolveur local doit
donc valider avec DNSSEC. Notez que, malheureusement, peu de domaines sont
signés.
La meilleure solution est donc un résolveur DNS validant avec DNSSEC et
tournant sur une machine du réseau local (la « box » est l'endroit idéal). Cela
assure un résolveur non-menteur et sécurisé. Si on veut en plus de la vie
privée, il faut lui faire suivre les requêtes non-résolues à un résolveur
public de confiance (donc pas Google ou Verisign) et accessible par un canal
chiffré (DNS sur TLS).
Si votre box est fermée et ne permet pas ce genre de manips, remplacez-la par
un engin ouvert, libre et tout ça, comme le Turris Omnia[32] qui a par défaut
un résolveur DNSSEC.
Liens:
[1]: http://www.bortzmeyer.org/censure-francaise.html (lien)
[2]: http://www.bortzmeyer.org/resolveur-dns-en-panne.html (lien)
[3]: https://www.nextinpact.com/news/102862-free-problemes-dns-a-repetition-rendent-difficile-navigation-web.htm (lien)
[4]: http://www.bortzmeyer.org/google-detourne-par-orange.html (lien)
[5]: http://www.bortzmeyer.org/google-dns.html (lien)
[6]: https://www.nextinpact.com/ (lien)
[7]: https://www.nextinpact.com/news/101871-dyn-on-fait-point-sur-attaque-ddos-qui-a-impactee-nombreux-sites.htm (lien)
[8]: http://www.bortzmeyer.org/dns-menteur.html (lien)
[9]: http://www.bortzmeyer.org/opendns-non-merci.html (lien)
[10]: https://www.fdn.fr/actions/dns/ (lien)
[11]: https://www.opennicproject.org/ (lien)
[12]: https://www.verisign.com/fr_FR/security-services/public-dns/index.xhtml (lien)
[13]: https://dns.yandex.com/ (lien)
[14]: http://www.bortzmeyer.org/jres-dos-2013.html (lien)
[15]: http://www.bortzmeyer.org/dns-attaques-shulman.html (lien)
[16]: https://twitter.com/Ybalrid/status/819547603633373184 (lien)
[17]: https://www.degroupnews.com/internet/tutoriel-panne-de-dns-comment-y-remedier (lien)
[18]: http://www.bortzmeyer.org/dns-routing-hijack-turkey.html (lien)
[19]: http://arstechnica.com/information-technology/2014/03/google-dns-briefly-hijacked-to-venezuela/ (lien)
[20]: http://www.bortzmeyer.org/usurpation-adresse-ip.html (lien)
[21]: http://www.bortzmeyer.org/attaques-reflexion.html (lien)
[22]: https://www.shaftinc.fr/arretez-google-dns.html (lien)
[23]: http://www.bortzmeyer.org/racines-alternatives.html (lien)
[24]: http://wiki.opennicproject.org/OpenNICNamespaces (lien)
[25]: http://www.bortzmeyer.org/son-propre-resolveur-dns.html (lien)
[26]: https://labriqueinter.net/ (lien)
[27]: https://ldn-fai.net/serveur-dns-recursif-ouvert/ (lien)
[28]: https://www.afnic.fr/fr/ressources/blog/resolveur-public-de-dns-sur-tls-yeti.html (lien)
[29]: https://portal.sinodun.com/wiki/display/TDNS/DNS-over-TLS+test+servers (lien)
[30]: http://www.malekal.com/simple-dnscrypt-dns-securises/ (lien)
[31]: https://computersecuritypgp.blogspot.fr/2016/03/what-is-dnscrypt.html (lien)
[32]: http://www.bortzmeyer.org/turris.html (lien)
|
