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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
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)
|
