diff options
Diffstat (limited to '')
-rw-r--r-- | RFC_8023_Report_from_the_Workshop_and_Prize_on_Root_Causes_and_Mitigation_of_Name_Collisions.txt | 201 |
1 files changed, 201 insertions, 0 deletions
diff --git a/RFC_8023_Report_from_the_Workshop_and_Prize_on_Root_Causes_and_Mitigation_of_Name_Collisions.txt b/RFC_8023_Report_from_the_Workshop_and_Prize_on_Root_Causes_and_Mitigation_of_Name_Collisions.txt new file mode 100644 index 0000000..7e2e345 --- /dev/null +++ b/RFC_8023_Report_from_the_Workshop_and_Prize_on_Root_Causes_and_Mitigation_of_Name_Collisions.txt @@ -0,0 +1,201 @@ +Titre: RFC 8023: Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions +Auteur: +Date: Sun 27 Nov 2016 01:00:00 +0100 +Lien: https://www.bortzmeyer.org/8023.html + +Ce nouveau RFC est le compte-rendu d'un atelier qui s'était tenu du 8 au 10 +mars 2014 à Londres sur le thème des « collisions ». Ce terme exagéré et +sensationnaliste désigne le phénomène qui peut se produire quand un acteur de +l'Internet a bêtement choisi de se créer un TLD à lui dans le DNS, et que ce +TLD est ensuite créé par l'ICANN. + +Supposons que l'entreprise Bidon décide de nommer ses ressources internes (site +Web réservé aux employés, etc) sous le TLD inexistant .bidon. C'est une +mauvaise idée[1] mais elle est fréquente. L'entreprise Bidon compte sur le fait +que ses employés utiliseront les résolveurs DNS internes, qui ont été +configurés pour reconnaître .bidon. Par exemple, avec Unbound, et un serveur +faisant autorité en 2001:db8:666::1:541f, les résolveurs ont été configurés +ainsi : + + stub-zone: + name: "bidon" + stub-addr: 2001:db8:666::1:541f +Si un employé tente accidentellement d'accéder à une ressource en .bidon, alors +qu'il n'utilise pas les résolveurs de la boîte, la requête filera vers la +racine du DNS, qui répondra NXDOMAIN (No Such Domain). C'est ainsi que la +racine voit souvent des requêtes pour des noms se terminant en .local, .home ou +.belkin. Si, quelques années après, l'ICANN délègue effectivement ce TLD à une +autre organisation, ces requêtes à la racine donneront désormais un vrai +résultat. Au lieu d'un message d'erreur, le malheureux employé sera peut-être +redirigé vers un autre site Web que celui attendu. C'est ce phénomène que +Verisign avait baptisé « collision » (name collision), terme conçu pour faire +peur. + +C'est dans ce contexte qu'il y a plus de deux ans s'était tenu le « Workshop on +Root Causes and Mitigation of Name Collisions[2] », dont ce RFC est le +compte-rendu tardif. Le premier rapport de l'ICANN qui mentionnait ce phénomène +était le SAC 045[3] en 2010. Il pointait le risque que la délégation effective +d'un nouveau TLD change la réponse obtenue, pour les clients mal configurés +(qui interrogeaient à tort un résolveur extérieur, et donc la racine, au lieu +de leurs résolveurs internes). + +L'ICANN a même créé une page Web dédiée à cette question[4], dont la source +réelle est le recouvrement de deux espaces de noms, l'interne et l'externe. La +bonne pratique idéale serait de ne pas utiliser de noms qui n'existent pas ou, +pire, qui existent avec une autre signification dans l'arbre public des noms de +domaine (et, là, relire le RFC 2826 peut aider). Pour reprendre l'exemple de +l'entreprise Bidon, si elle est titulaire de bidon.fr, elle devrait nommer ses +ressources internes avec des noms se terminant en privé.bidon.fr ou +interne.bidon.fr. Si on ne veut pas faire les choses proprement, et qu'on +utilise quand même le TLD inexistant .bidon, alors il faut veiller très +soigneusement à séparer les deux espaces de nommage et à éviter qu'ils ne se +rencontrent un jour (ce qui est difficile à l'ère des mobiles, avec des +appareils qui rentrent et qui sortent du réseau de l'entreprise). Sinon, on +verra ces fameuses collisions. + +En pratique, pas mal d'administrateurs système surestiment leurs compétences et +croient qu'ils vont réussir à empêcher toute fuite vers le DNS public. C'est ce +qui explique une partie des requêtes pour des noms inexistants que reçoit la +racine (ces noms inexistants forment la majorité du trafic des serveurs racine +du DNS). Un des problèmes de fond de l'Internet est en effet que +l'administrateur de base ne se tient pas au courant et n'est pas informé des +problèmes du monde extérieur. « Après moi, le déluge » + +Autrefois, le problème était surtout théorique. Le nombre de TLD n'avait pas +bougé depuis de très nombreuses années, et personne ne pensait que des TLD +comme .pizza ou .green verraient le jour. Mais, en 2012, l'ICANN a lancé +officiellement son programme d'ajout d'un grand nombre de TLD, et le risque est +soudain devenu une question pratique. D'où l'atelier de 2014. + +La section 2 du RFC revient en détail sur l'arrière-plan de ce problème de +collision. Outre le rapport SAC 045 cité plus haut, il y avait eu une +déclaration de l'IAB[5], puis un autre rapport du SSAC (Security and Stability +Advisory Committee, un comité de l'ICANN), le SAC 046[6], une déclaration du +RSSAC[7] et plein d'autres textes sur les conséquences d'un agrandissement +important de la zone racine. Par exemple, le rapport SAC 057[8] faisait +remarquer que les AC attribuaient souvent des certificats pour des noms de +domaine dans des TLD purement locaux. Cela montrait le déploiement de ces TLD +privés et cela inquiétait. Si la société Bidon exploite .bidon et obtient d'une +AC un certificat pour www.compta.bidon, après la délégation de ce même TLD dans +la racine publique, ce certificat pourrait être utilisé pour usurper l'identité +d'un autre serveur. + +J'ai parlé plus haut des fuites vers le DNS public. Quelle est leur ampleur +exacte ? Ce n'est pas si évident que cela de le savoir. Contrairement à un +raccourci journalistique fréquent, l'ICANN ne gère pas la racine. Chaque +opérateur d'un serveur DNS racine se débrouille indépendamment, supervise son +serveur mais ne rend pas forcément compte à d'autres acteurs ou au public. En +pratique, les opérateurs des serveurs racine ont un niveau d'ouverture très +variable. (Cf. l'analyse de l'ICANN[9] à ce sujet.) Un des moments où plusieurs +opérateurs de serveurs racine collectent en même temps de l'information est le +Day in the Life of the Internet[10] et c'est sur la base de ces données qu'a +été fait le rapport d'Interisle « Name Collision in the DNS[11] ». Entre +autres, ce rapport classait les futurs TLD selon qu'ils présentaient un risque +de collision élevé ou faible (.home, .corp et .site se retrouvaient en tête du +classement). L'ICANN a alors publié un plan[12] pour gérer ce risque de +collisions, notant que .home et .corp étaient de loin les plus « risqués », car +ils sont fréquemment utilisés comme TLD locaux. Bien d'autres documents ont été +publiés par l'ICANN, qui a une productivité extraordinaire lorsqu'il s'agit de +faire de la paperasse. Le dernier[13] mettait en place le système dit de « +controlled interruption » qui, en gros, impose à tous les nouveaux TLD de +résoudre, pendant les premiers temps de leur délégation, tous les noms de +domaine vers l'adresse IP 127.0.53.53. Voici l'exemple de .box en novembre 2016 +(ce cas avait fait l'objet d'un article de Heise en allemand[14], car le +routeur Fritz!Box, très populaire en Allemagne, utilisait ce TLD) : + + + +% dig ANY box. + +; <><>>> DiG 9.10.3-P4-Debian <><>>> ANY box. +;; global options: +cmd +;; Got answer: +;; ->>HEADER<><>- opcode: QUERY, status: NOERROR, id: 14573 +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 24, AUTHORITY: 0, ADDITIONAL: 1 + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags: do; udp: 4096 +;; QUESTION SECTION: +;box. IN ANY + +;; ANSWER SECTION: +box. 3600 IN A 127.0.53.53 +box. 3600 IN SRV 10 10 0 your-dns-needs-immediate-attention.box. +box. 3600 IN TXT "Your DNS configuration needs immediate attention see https://icann.org/namecollision" +box. 3600 IN MX 10 your-dns-needs-immediate-attention.box. +box. 900 IN SOA a.nic.box. support.ariservices.com. ( + 1478481375 ; serial + 1800 ; refresh (30 minutes) + 300 ; retry (5 minutes) + 1814400 ; expire (3 weeks) + 1800 ; minimum (30 minutes) + ) +box. 172800 IN NS b.nic.box. +box. 172800 IN NS d.nic.box. +box. 172800 IN NS c.nic.box. +box. 172800 IN NS a.nic.box. +[...] +;; Query time: 89 msec +;; SERVER: 127.0.0.1#53(127.0.0.1) +;; WHEN: Mon Nov 21 17:23:17 CET 2016 +;; MSG SIZE rcvd: 2938 + + + +Ces enregistrements ont pour but d'attirer l'attention des utilisateurs sur le +risque de collision. Le TLD étant récent et pas encore peuplé, il ne devrait +pas y avoir de requêtes DNS. S'il y en a quand même, c'est peut-être le +résultat d'une collision avec un usage local. L'adresse IP 127.0.53.53 est une +adresse locale à la machine. Si M. Michu tente de se connecter à +http://quelquechose.box/ aujourd'hui, il sera redirigé vers la machine locale. +Il verra une erreur (pas de serveur HTTP qui écoute) ou bien la page Web par +défaut de sa machine (avec un message peu informatif comme « It works ») s'il y +a un serveur HTTP. Si l'utilisateur regarde les enregistrements SRV, MX ou TXT, +ou bien si un administrateur système regarde les requêtes DNS qui passent, ou +bien les journaux du serveur de messagerie, peut-être comprendra-t-il qu'il +doit agir. (Je trouve personnellement que la probabilité que cela arrive est +assez faible.) + +L'atelier lui-même, financé par Verisign (l'entreprise qui avait le plus crié +« au loup » sur les name collisions), s'est donc tenu du 8 au 10 mars à +Londres. Un site Web[2] avait été mis en place pour cet atelier, et il contient +les supports et les vidéos[15]. + +Je ne vais pas décrire tous les exposés de l'atelier, la liste complète figure +dans l'annexe C du RFC, et les supports sont en ligne[15]. Le RFC note qu'il y +a eu plusieurs interventions sur la qualité des données du DITL (Day in the +Life of the Internet) : il est trivial de les polluer (le DITL est annoncé +publiquement, et à l'avance) par des requêtes artificielles. Aucune preuve n'a +été trouvée d'une manipulation délibérée. De toute façon, les données montrent +surtout qu'il y a beaucoup de n'importe quoi dans le trafic que reçoivent les +serveurs racine (par exemple des requêtes avec le bit RD - Recursion Desired - +alors que les serveurs de la racine ne sont pas récursifs). Cela peut être le +résultat de bogues dans les résolveurs, de tests ou bien d'attaques délibérées. + +La question de l'éducation des utilisateurs est revenue plusieurs fois. Faut-il +s'inspirer du téléphone ou du système postal, qui ont tous les deux connu des +changements qui nécessitaient une adaptation de l'utilisateur, qui s'est faite +par le biais d'importantes campagnes de sensibilisation et d'éducation ? + +Le comité de programme avait conclu que le sujet était loin d'être épuisé. +Manque de données, manque de théories explicatives, manque d'intérêt pour la +question, en tout cas, celle-ci restait largement ouverte après l'atelier (et +je ne suis personnellement pas sûr que cela soit mieux aujourd'hui, plus de +deux ans après l'atelier de Londres). + +Liens: +[1]: http://www.bortzmeyer.org/pourquoi-le-tld-local-n-est-pas-une-bonne-idee.html (lien) +[2]: http://namecollisions.net/ (lien) +[3]: https://www.icann.org/en/system/files/files/sac-045-en.pdf (lien) +[4]: http://www.icann.org/en/help/name-collision (lien) +[5]: https://www.iab.org/documents/correspondence-reports-documents/docs2008/2008-03-07-icann-new-gtlds/ (lien) +[6]: https://www.icann.org/en/system/files/files/sac-046-en.pdf (lien) +[7]: http://www.icann.org/en/news/correspondence/murai-to-board-25nov10-en.pdf (lien) +[8]: https://www.icann.org/en/system/files/files/sac-057-en.pdf (lien) +[9]: https://www.icann.org/en/news/announcements/announcement-28may13-en.htm (lien) +[10]: http://www.caida.org/projects/ditl/ (lien) +[11]: https://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf (lien) +[12]: https://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigation-05aug13-en.pdf (lien) +[13]: https://www.icann.org/en/about/staff/security/ssr/name-collision-mitigation-26feb14-en.pdf (lien) +[14]: https://www.heise.de/newsticker/meldung/Neue-Top-Level-Domain-box-bringt-manche-Netze-durcheinander-3491185.html (lien) +[15]: http://namecollisions.net/program/index.html (lien) |