diff options
Diffstat (limited to '')
-rw-r--r-- | Utiliser_un_rsolveur_DNS_public.txt | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/Utiliser_un_rsolveur_DNS_public.txt b/Utiliser_un_rsolveur_DNS_public.txt new file mode 100644 index 0000000..d703a45 --- /dev/null +++ b/Utiliser_un_rsolveur_DNS_public.txt @@ -0,0 +1,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) |