Première rédaction de cet article le 14 octobre 2009
Lundi 12 octobre, vers 20h00 UTC, le
domaine de tête
.se
a chargé la zone
DNS de
numéro de série 2009101210 qui comprenait une énorme erreur. Pendant
une heure, plus aucun nom de domaine se terminant par .se
ne
fonctionnait.
Très vite, Twitter a vu des tweets sur le sujet, puis des rapports et des discussions ont commencé sur les listes de diffusion d'opérateurs comme Nanog.
La cause immédiate était le manque d'un point
dans le fichier de zone, les enregistrement NS de la zone avaient tous
un .se
en trop à la fin, par exemple
h.ns.se.se
. En effet, dans le format standard
des fichiers de zone DNS, tel qu'il est défini
en section 5 du RFC 1035, un nom qui ne se
termine pas par un point est complété par la nom de la zone, ici
.se
. Pendant la panne, on a donc pu voir :
% dig +cd NS se. ... ;; ANSWER SECTION: se. 172540 IN NS h.ns.se.se. se. 172540 IN NS g.ns.se.se. ...
Vous avez remarqué ? (Moi, je ne l'avais pas vu.) Un
.se
de trop à la fin, les noms des serveurs de
noms étaient donc tous considérés comme
inexistants. .se
avait
donc disparu de l'Internet, plus de Web, plus
de courrier, plus
de XMPP, etc. Comme quasiment toutes les
interactions sur l'Internet commencent par une
requête DNS, plus
rien ne marchait.
Selon la façon dont les résolveurs remplaçaient la délégation venue de
la racine (qui était correcte) par celle faisant autorité (car publiée
par le domaine .se
lui-même), ils
arrivaient encore à résoudre les noms en .se
ou pas (BIND se
débrouillait mieux qu'Unbound, l'inverse aurait été vrai si l'erreur
avait été à la racine).
Le problème ne concernait pas que les enregistrement NS du TLD mais aussi ceux de toutes les zones déléguées :
ballou.se. 42617 NS ns1.ballou.se.se. 42617 NS ns2.ballou.se.se. 45098 NS ns3.aname.se.se.
Vers 21h00 UTC, .se
a chargé la zone 2009101211 qui corrigeait
l'erreur... et en introduisait d'autres, notamment des signatures
DNSSEC invalides pour le SOA. (Ce problème a
été reconnu
par le registre.)
Tout a finalement été réparé mais la mauvaise
information pouvait encore
se trouver dans des caches. Pendant un certain temps, les sites en
.se
restaient injoignables, sauf à obtenir de
votre FAI qu'il redémarre son résolveur (comme
conseillé
par le registre, command rndc flush
pour
BIND). Pendant quelle durée exactement ? Le TTL
est de deux jours, donc j'avais pensé que ce serait la durée de la
panne (et c'est aussi ce qu'annonce
le registre) mais Jay Daley me fait remarquer à juste titre
que, les noms n'existant pas, c'est le cache négatif (RFC 2308) qui compte et que
celui-ci est de seulement deux heures pour .se
.
Cette panne est une des plus graves qui aient jamais affecté un domaine de tête sérieux. Aurait-elle pu être évitée ? Il est évident qu'il faut faire tourner des tests de validité avant de publier la zone. Mais aucun test ne détecte tous les problèmes possibles. Par exemple, un outil de vérification livré avec BIND aurait pu détecter le problème :
% named-checkzone example example.zone zone example/IN: NS 'ns1.nic.example.example' has no address records (A or AAAA)
Mais named-checkzone
a aussi des limites. Il ne
positionne pas le code de retour dans le cas ci-dessus, par exemple
(et, non, -n fail
ne change rien). Et il ne
marche pas si la zone est mise à jour par dynamic
update (RFC 2136).
Quelques leçons à en tirer :
Quelques articles sur le sujet :
.se
a publié quelques mois
après une étude très
détaillée en anglais.Je dois aussi des remerciements à Jay Daley, David Blacka, Gilles Massen, Jakob Schlyter, Jelte Jansen et Olaf Kolkman pour leurs analyses et le partage d'information.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)