Mon blog

On fait souvent remarquer que c'est pendant les pannes qu'on peut le mieux observer comment un système marche. Les perturbations qui affectent le serveur racine du DNS identifié par la lettre C sont donc l'occasion d'apprendre comment fonctionne ce système des serveurs racine.

À la racine du DNS, se trouvent treize serveurs (« serveur » au sens virtuel car cela fait évidemment bien plus que treize machines), chacun identifié par une lettre de A à M, et nommés dans le domaine root-servers.net. Un programme comme check-soa permet de les voir en action (l'option -i permet d'avoir le temps de réponse), ici le 22 mai à 08:47:24 UTC :

% check-soa -i .
a.root-servers.net.
	2001:503:ba3e::2:30: OK: 2024052200 (14 ms)
	198.41.0.4: OK: 2024052200 (15 ms)
b.root-servers.net.
	2801:1b8:10::b: OK: 2024052200 (14 ms)
	170.247.170.2: OK: 2024052200 (14 ms)
c.root-servers.net.
	2001:500:2::c: OK: 2024052101 (25 ms)
	192.33.4.12: OK: 2024052101 (25 ms)
d.root-servers.net.
	2001:500:2d::d: OK: 2024052200 (4 ms)
	199.7.91.13: OK: 2024052200 (5 ms)
e.root-servers.net.
	192.203.230.10: OK: 2024052200 (6 ms)
	2001:500:a8::e: OK: 2024052200 (6 ms)
f.root-servers.net.
	2001:500:2f::f: OK: 2024052200 (6 ms)
	192.5.5.241: OK: 2024052200 (6 ms)
g.root-servers.net.
	2001:500:12::d0d: OK: 2024052200 (52 ms)
	192.112.36.4: OK: 2024052200 (65 ms)
h.root-servers.net.
	2001:500:1::53: OK: 2024052200 (11 ms)
	198.97.190.53: OK: 2024052200 (14 ms)
i.root-servers.net.
	192.36.148.17: OK: 2024052200 (10 ms)
	2001:7fe::53: OK: 2024052200 (10 ms)
j.root-servers.net.
	2001:503:c27::2:30: OK: 2024052200 (15 ms)
	192.58.128.30: OK: 2024052200 (14 ms)
k.root-servers.net.
	2001:7fd::1: OK: 2024052200 (8 ms)
	193.0.14.129: OK: 2024052200 (14 ms)
l.root-servers.net.
	199.7.83.42: OK: 2024052200 (15 ms)
	2001:500:9f::42: OK: 2024052200 (14 ms)
m.root-servers.net.
	2001:dc3::35: OK: 2024052200 (4 ms)
	202.12.27.33: OK: 2024052200 (5 ms)
  

(Le point désigne la racine.)

Avez-vous remarqué le problème ? L'un des serveurs, C.root-servers.net, est en retard. Le numéro de série dans l'enregistrement SOA est 2024052101 alors que tous les autres sont à 2024052200. Dans le cas de la racine (c'est une convention courante mais pas du tout obligatoire), le numéro de série indique la date de modification, on voit donc qu'il est resté à hier, 21 mai.

C'était pire avant : du 18 au 21 mai, ce serveur est resté en 2024051801, ignorant donc tout changement qui aurait pu avoir lieu dans le contenu de la racine (heureusement, il n'y en a eu aucun pendant cette période) :

% date -u       
Tue 21 May 20:03:11 UTC 2024

% check-soa -i .
a.root-servers.net.
	198.41.0.4: OK: 2024052101 (23 ms)
	2001:503:ba3e::2:30: OK: 2024052101 (96 ms)
b.root-servers.net.
	170.247.170.2: OK: 2024052101 (23 ms)
	2801:1b8:10::b: OK: 2024052101 (84 ms)
c.root-servers.net.
	192.33.4.12: OK: 2024051801 (22 ms)
	2001:500:2::c: OK: 2024051801 (22 ms)
d.root-servers.net.
	199.7.91.13: OK: 2024052101 (16 ms)
	2001:500:2d::d: OK: 2024052101 (16 ms)
e.root-servers.net.
	192.203.230.10: OK: 2024052101 (16 ms)
	2001:500:a8::e: OK: 2024052101 (16 ms)
f.root-servers.net.
	192.5.5.241: OK: 2024052101 (22 ms)
	2001:500:2f::f: OK: 2024052101 (96 ms)
g.root-servers.net.
	2001:500:12::d0d: OK: 2024052101 (54 ms)
	192.112.36.4: OK: 2024052101 (66 ms)
h.root-servers.net.
	198.97.190.53: OK: 2024052101 (23 ms)
	2001:500:1::53: OK: 2024052101 (96 ms)
i.root-servers.net.
	192.36.148.17: OK: 2024052101 (23 ms)
	2001:7fe::53: OK: 2024052101 (23 ms)
j.root-servers.net.
	192.58.128.30: OK: 2024052101 (23 ms)
	2001:503:c27::2:30: OK: 2024052101 (96 ms)
k.root-servers.net.
	2001:7fd::1: OK: 2024052101 (23 ms)
	193.0.14.129: OK: 2024052101 (22 ms)
l.root-servers.net.
	199.7.83.42: OK: 2024052101 (16 ms)
	2001:500:9f::42: OK: 2024052101 (22 ms)
m.root-servers.net.
	2001:dc3::35: OK: 2024052101 (16 ms)
	202.12.27.33: OK: 2024052101 (16 ms)
  

Le serveur C est anycasté donc le test ci-dessus laisse ouverte la possibilité d'un problème spécifique à l'instance à laquelle je parle. Mais une mesure faite avec les sondes RIPE Atlas montre que non, le problème touche presque toutes les instances :

% blaeu-resolve --requested 200 --nsid --type SOA --nameserver c.root-servers.net .
Nameserver c.root-servers.net
[NSID: lax1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 10 occurrences 
[NSID: fra1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 37 occurrences 
[NSID: mad1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 5 occurrences 
[NSID: rio1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 2 occurrences 
[NSID: fra1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 37 occurrences 
[NSID: iad1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 10 occurrences 
[NSID: lax1b.c.root-servers.org; … 2024052101 1800 900 604800 86400] : 8 occurrences 
[NSID: sin1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 3 occurrences 
[NSID: par1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 20 occurrences 
[NSID: par1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 20 occurrences 
[TIMEOUT] : 9 occurrences 
[NSID: mad1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 1 occurrences 
[NSID: iad1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 7 occurrences 
[NSID: sin1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 1 occurrences 
[NSID: bts1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 4 occurrences 
[NSID: ord1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 9 occurrences 
[NSID: jfk1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 1 occurrences 
[NSID: bts1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 6 occurrences 
[NSID: ord1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 3 occurrences 
[NSID: jfk1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 2 occurrences 
[… 2024052100 1800 900 604800 86400] : 1 occurrences 
Test #72103734 done at 2024-05-21T20:15:03Z
  

Quelles sont les conséquences pratiques pour les utilisateurices ? Si leur résolveur interroge C (ce qui dépend d'un certain nombre de facteurs, dont le temps de réponse des différents serveurs faisant autorité), ledit résolveur aura des informations peut-être dépassées. Ainsi, ce matin du 22 mai, on voit que le TLD .int a publié hier un nouvel enregistrement DS (dans le cadre de sa migration vers la cryptographie en courbes elliptiques) mais le serveur C ne le voit toujours pas :

% dig +short  @a.root-servers.net int DS
59895 13 2 10C789F286599316D3A74C2C513434C3F8A33B9238976D5DE2A178E5 4DA353F3
27433 7 2 5864812D4DF2A4A455D905AF311389F479AFCD96FD369060941C7E17 0B40CA4F

% dig +short  @c.root-servers.net int DS
27433 7 2 5864812D4DF2A4A455D905AF311389F479AFCD96FD369060941C7E17 0B40CA4F
  

Un problème identique se pose pour .gov qui planifiait la même transition vers ECDSA et a dû la retarder. Cela sera encore pire si un TLD était redélégué ou si les signatures DNSSEC servies par C finissaient par expirer.

Que peut-on faire ? Pas grand'chose. Le gestionnaire du serveur C, Cogent va peut-être réparer mais on ne sait pas quand et on n'a pas d'informations. Techniquement, il serait possible de retirer C de la liste des serveurs racine ou bien de confier C à un autre opérateur, mais personne n'a le droit et/ou l'autorité de supprimer ou de réaffecter un serveur racine. Contrairement à ce qu'écrivent les journalistes, l'ICANN n'est pas régulateur du DNS, encore moins de l'Internet et ne peut donc pas agir. (La liste des serveurs et de leurs opérateurs est disponible en ligne.)

Le problème a finalement été réparé vers le 23 mai, d'abord sans explications et sans communication de la part de Cogent, puis finalement par un court texte sur leur site Web : « 2024‑05‑23 - On May 21 at 15:30 UTC the c-root team at Cogent Communications was informed that the root zone as served by c-root had ceased to track changes from the root zone publication server after May 18. Analysis showed this to have been caused by an unrelated routing policy change whose side effect was to silence the relevant monitoring systems. No production DNS queries went unanswered by c-root as a result of this outage, and the only impact was on root zone freshness. Root zone freshness as served by c-root was fully restored on May 22 at 16:00 UTC. ».

À noter qu'à peu près au même moment (mais nous ne savons pas s'il s'agit d'une coïncidence ou bien si les deux problèmes sont liés), le site Web d'information sur le serveur C, https://c.root-servers.org/ (notez le .org alors que le serveur DNS est en .net) avait cessé de fonctionner vers le 17 mai. Il utilisait l'adresse IP 38.230.3.4, allouée à Orange Côte d'Ivoire et, depuis le 17 mai, annoncée par eux dans BGP.

% whois 38.230.3.4
...
Found a referral to rwhois.cogentco.com:4321.

%rwhois V-1.5:0010b0:00 rwhois.cogentco.com (CGNT rwhoisd 1.2.0)
network:ID:NET4-26E6000011
network:Network-Name:NET4-26E6000011
network:IP-Network:38.230.0.0/17
network:Org-Name:Orange Cote d'Ivoire
network:Street-Address:CABLE SAT3 CLS, RUA AMÉLIA FRADE
  network:City:SESIMBRA
network:Country:PT
network:Postal-Code:2970 – 712
network:Tech-Contact:ZC108-ARIN
network:Updated:2024-05-10 16:33:20
  

Orange Côte d'Ivoire est un client de Cogent et, manifestement, Cogent avait délégué ce préfixe à son client sans remarquer qu'ils l'utilisaient pour C.root-servers.org. Ou bien ils ne s'étaient pas aperçus du problème car, en interne, cela marchait, en raison d'une route plus spécifique. (Quand j'ai signalé le problème à Cogent, l'employé avait répondu que ça marchait pour lui. De manière très peu professionnelle, il testait le service depuis sa machine, sur le réseau interne de son employeur.)

Il n'y avait donc aucun détournement BGP, contrairement à ce qui a parfois été écrit, l'annonce d'Orange Côte d'Ivoire est parfaitement légitime. Le service Web a désormais une autre adresse IP et qui fonctionne, ce qui permet de voir le site et de constater qu'il n'y avait aucune information publiée avant le 23 mai :

(Merci à Bert Hubert pour avoir détecté le problème de synchronisation du serveur DNS racine C, à Jan-Piet Mens pour avoir détecté le problème avec le serveur Web C.root-servers.org et à Alarig Le Lay pour ses explications sur le routage dans Cogent.)