Coordination technique de l’internet : l’affaire du serveur L

Cette « affaire » est plutôt simple dans sa genèse, puisqu’elle a commencé avec l’utilisation d’une adresse IP qui avait servi à identifier le serveur racine L jusqu’en novembre dernier. Cette adresse IP (198.32.64.12) est légitimement détenue par EP.NET (1), qui l’a réactivée récemment, avec pour conséquence la captation d’un afflux de requêtes DNS provenant de serveurs qui n’avaient pas encore pris en compte la nouvelle adresse IP. La polémique est née quand l’IANA s’est aperçue que les requêtes DNS erronées recevaient des réponses (correctes) d’un serveur DNS fonctionnant parfaitement à l’ancienne adresse du serveur L officiel. Ce qui ouvrait une véritable boîte de Pandore : ce serveur « L’ », bien que « non officiel », rendait plutôt service puisqu’il répondait à des requêtes mal adressées ; pourquoi l’ICANN n’avait-elle pas anticipé le fait que la mise à jour de cette adresse IP dans l’ensemble des serveurs DNS de la planète prendrait des mois sinon des années , en prévoyant par exemple une période de recouvrement ? Quelle autorité l’ICANN avait-elle pour interdire à EP.net d’utiliser cette adresse IP du moment que les informations renvoyées étaient correctes ? Et plus fondamentalement, quelle est la légitimité de l’ICANN vis-à-vis de gestionnaires de serveurs racine, qui étaient en fonction avant sa création et qui se sont toujours bien gardés de signer quelque engagement que ce soit avec elle ? Même Verisign, l’opérateur du serveur racine A, n’a formellement d’instructions à recevoir que du DoC... Et si l’on considère que l’ICANN n’a aucune autorité de jure sur les entités qui gèrent l’internet, de quelle légitimité peut-elle se prévaloir hormis celle qui lui est conférée par la seule volonté du gouvernement américain ?
Stephane Bortzmeyer livre son analyse de la situation sur son blog (2), soulignant le flou qui règne autour du statut des gestionnaires des serveurs racines. Danny McPherson plaide pour sa part en faveur d’un renforcement du contrôle de l’ICANN sur cette question (3). En tout état de cause, c’est un nerf particulièrement sensible qui a été touché lors de cet incident.
(1) Search ARIN WHOIS for: 198.32.64.12
http://ws.arin.net/whois/?queryinput=198.32.64.12
(2) Qui contrôle les serveurs racine du DNS ?
http://www.bortzmeyer.org/qui-controle-les-serveurs-racine.html
(3) Uprooting of the DNS Root
http://www.circleid.com/posts/852211_uprooting_the_dns_root/