Depuis septembre 2011, le TLD du
Gabon,
.ga est en panne
quasi-complète. Quelle est la panne exacte ? Pourquoi cette panne ?
Que fait le gouvernement ? Quelles sont les conséquences pour le reste
du DNS ?
La panne a commencé le 13 septembre mais ses conséquences n'ont pas
été visibles tout de suite. Le serveur maître à
Libreville a commencé par refuser à ses
esclaves les transferts de zone (). Le
champ « expiration » dans l'enregistrement SOA
de .ga étant de 42 jours,
les esclaves ont fini par renoncer le 27 octobre, répondant
SERVFAIL (Server Failure) :
>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48352
...
]]>
Cela concerne les deux esclaves extérieurs, un à
l'AFNIC et un au
RIPE-NCC. Et les deux serveurs situés dans le
pays ? Leur comportement est plus bizarre. Souvent, ils ne répondent
pas (et ce n'est pas un problème réseau, puisqu'un
ping fonctionne) :
> DiG 9.7.3 <<>> @nyali.inet.ga. SOA ga.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
]]>
Plus rigolo, la réponse peut dépendre du type de données demandé :
> DiG 9.7.3 <<>> @nyali.inet.ga. ga. SOA
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
% dig @nyali.inet.ga. ga. NS
; <<>> DiG 9.7.3 <<>> @nyali.inet.ga. ga. NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16007
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 6
;; QUESTION SECTION:
;ga. IN NS
;; ANSWER SECTION:
ga. 15900 IN NS ns-ga.ripe.net.
ga. 15900 IN NS nyali.inet.ga.
ga. 15900 IN NS b.hosting.nic.fr.
ga. 15900 IN NS ogooue.inet.ga.
...
]]>
Lorsqu'ils répondent, le code de retour renvoyé par les serveurs est
FORMERR si on a essayé avec EDNS0 (), ce qui est pourtant le comportement normal
d'un résolveur DNS (rappelez-vous que dig, par
défaut, n'avait pas le même comportement qu'un vrai résolveur, il n'activait
pas EDNS0 ; ce comportement par défaut a changé récemment) :
> DiG 9.7.3 <<>> +bufsize=1400 @nyali.inet.ga. ga. ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 4032
;; flags: qr rd ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; Query time: 370 msec
;; SERVER: 217.77.71.33#53(217.77.71.33)
;; WHEN: Thu Jan 12 11:13:11 2012
;; MSG SIZE rcvd: 12
% dig @nyali.inet.ga. ga. ANY
; <<>> DiG 9.7.3 <<>> @nyali.inet.ga. ga. ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32644
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 6
;; QUESTION SECTION:
;ga. IN ANY
;; ANSWER SECTION:
ga. 7189 IN NS ogooue.inet.ga.
ga. 7189 IN NS ns-ga.ripe.net.
ga. 7189 IN NS nyali.inet.ga.
ga. 7189 IN NS b.hosting.nic.fr.
...
]]>
Comme il n'y a plus guère de logiciels serveurs
qui ne gèrent pas EDNS0, douze ans après sa normalisation, le plus
probable est qu'il y a devant le serveur DNS une
middlebox boguée (pléonasme, vu le niveau de
qualité du logiciel de la plupart de ces équipements). C'est sans
doute elle qui répond aux ping, et massacre les questions et/ou les
réponses DNS.
Si on ne met pas EDNS0, le serveur répond, mais sans le bit AA
(Authoritative Answer), ce qui est anormal pour un
serveur faisant autorité (vues les données renvoyées en réponse à une requête ANY, il est probable que ce serveur ne contienne plus les données de la zone .ga). Donc, on peut dans certains cas, certains jours, avoir une
réponse des serveurs de .ga mais uniquement si on
les interroge sans EDNS0. Certains résolveurs se rabattent
automatiquement sur le vieux DNS, sans EDNS0, lorsqu'ils ne reçoivent
pas de réponse. Pour le cas où ils
reçoivent FORMERR, le , section 5.3 dit qu'ils doivent en effet réessayer, ce que Christophe Deleuze a testé rapidement :
il semble que BIND9 répète la requête sans EDNS0, et cache l'info (n'utilise plus
EDNS0 avec ce serveur dans les requêtes suivantes). Unbound répète la requête sans EDNS0 mais semble ne pas cacher l'info,
car il retente avec EDNS0 à la prochaine requête.
Donc, dans beaucoup de cas,
.ga est quasiment inutilisable.
Que s'est-il passé ? Sans être sur place, et sans nouvelles des
gérants du TLD, on ne peut que faire des
hypothèses. Le plus probable est que le vrai serveur est en panne et
que la middlebox, placée devant (une mauvaise
architecture, mais passons), n'assure plus qu'une partie des
fonctions (je sais, cela n'explique pas tout). Le fait d'avoir plusieurs serveurs DNS faisant autorité
n'aide pas lorsque le maître est panne trop longtemps (les 42 jours de
grâce étant écoulés).
Pourquoi personne ne répare-t-il ? Le problème aurait dû être
détecté par les administrateurs de .ga,
Gabon Télécom. Sinon, il a été signalé par
courrier électronique en décembre 2011 (et pas
seulement à des adresses en .ga, évidemment), et
par fax, pour augmenter les
chances de réussite. Aucune réaction. Il faut bien se rappeler deux
choses : les bases de données des administrateurs de TLD (ici, la
base IANA sur
.GA) sont maintenues par les administrateurs eux-mêmes. S'ils
sont empêchés, ou bien irresponsables, la base va dériver petit à
petit et les informations (noms, numéros, etc) devenir dépassées. Et,
d'autre part, la réparation nécessite que quelqu'un agisse (les pannes
ne se réparent pas seules). Le Gabon n'est pas
un état de droit et une des conséquences de ce système politique est
que personne ne prend d'initiatives (c'est trop risqué). Donc, tous
les officiels restent les bras ballants. Le problème n'est pas
d'argent (le Gabon est un pays relativement riche, grâce au pétrole),
ni la compétence (des tas de gens compétents sur l'Internet sont prêts
à aider leurs collègues gabonais, si ceux-ci répondaient) mais de
responsabiité.
Et pour le reste de l'arbre du
DNS, quelles conséquences ? À peu près
aucune. La structure non-centralisée du DNS fait que la panne d'un TLD
n'affecte pas les autres. Contrairement à ce que prétend
l'ICANN (qui justifie ainsi les tarifs
colossaux de ses nouveaux TLD), un TLD n'a
rien de particulier. C'est un domaine comme un autre ; s'il est en
panne, cela ne gène que ses utilisateurs.
À noter qu'un problème du même genre était survenu au Tchad.
Merci à Ed Lewis pour son premier signalement du problème, grâce à
son script magique de suivi des TLD, et à Jean-Philippe Pick pour des
informations supplémentaires.