Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

Début du processus de diffusion des signatures de la racine DNS

Première rédaction de cet article le 28 janvier 2010


Pendant que les moutons fidèles de Steve Jobs se pressaient pour le voir présenter un nouvel engin ultra-fermé et contrôlé par Apple, un autre évenement suscitait de nombreux articles (moins nombreux, quand même), le début de diffusion des signatures par les serveurs racines du DNS. Ce processus avait été annoncé en octobre dernier et, jusqu'à présent, suit à peu près son cours.

Hier soir (heure française), un serveur racine a commencé à diffuser des informations signées avec DNSSEC. C'est L.root-servers.net, géré par l'ICANN qui s'y est collé pour être le premier. Le déploiement progressif (jusqu'en juillet), permet aux administrateurs réseaux de vérifier leur configuration, même si eux-mêmes ne font pas de DNSSEC. Ils doivent en effet s'assurer que leur réseau laisse passer les réponses DNS de grande taille.

Les autres serveurs racines suivront petit-à-petit, selon le plan publié sur le site officiel (le serveur A a suivi le 10 février.) En mai, certains des réseaux qui ont une configuration boguée (bloquant les résponses supérieures à 512 octets ou bien ne gérant pas la fragmentation) n'auront plus d'accès au DNS.

Quelques observations amusantes ou intéressantes. La réponse envoyée par L.root-servers.net atteint désormais dans les 600 octets pour une question typique (celle qui mène à une référence vers un TLD, par exemple dig AAAA www.bortzmeyer.fr), mais 1900 octets si on demande toutes les informations (dig ANY .). À cause de la taille des enregistrements NSEC, les demandes pour les TLD inexistants sont un peu plus grosses que les références (dans les 650 octets). Et la requête initiale des résolveurs (priming), dig NS ., atteint maintenant 800 octets.

Comme annoncé, la clé publiée n'est pas celle de signature et on ne peut donc pas encore valider la racine :


% dig +dnssec +multi @L.root-servers.net DNSKEY .

; <<>> DiG 9.5.1-P3 <<>> +dnssec +multi @L.root-servers.net DNSKEY .
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47275
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.			IN DNSKEY

;; ANSWER SECTION:
.			86400 IN DNSKEY	256 3 8 (
				AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/
				KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/
				AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++++++
				+++++++++++++++++++++++++++++++++++++++++++8
				) ; key id = 23763
.			86400 IN DNSKEY	257 3 8 (
				AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/
				KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/
				AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++++++
				++++++++++++++++++++++++++++++++++++++++++++
				++++++++++++++++++++++++++++++++++++++++++++
				++++++++++++++++++++++++++++++++++++++++++++
				++++++++++++++++++++++++++++++++++++++++++++
				++++++++++++++++++++++++++++++++++++++8=
				) ; key id = 19324
.			86400 IN RRSIG DNSKEY 8 0 86400 20100204235959 (
				20100121000000 19324 .
				NO9bHgWYB3wQlVZXQKwDGUjTgIyfz1i8aWH8nBlT5isn
				Ybr6PTfR4fWlSx8+avFfR0fVekauaQelKOyiUav4H9Y1
				AZ2OBguu7RjozQu1qErKboWd1NglIIOGar0Ol4Ur9+4b
				o2LSxjp/X4ESypW0lX04z5uB6DZZei1zafzRGUnLIMdV
				9xdKEOJrm9UCKvYK5g8bjRq8KA8vT+pidexZMrBQ3ie8
				R9daf/s6VK7zUJK0jF1vqhPbZFSQmBpJUlxh4VnOv7nn
				hcq4Moj49wqmNxKRqfvSwHAJBG6dEgShnlu/rfVsdxfF
				UCjIGX8YnSC7lYqODwgUGh+i/arAAK+bzg== )

;; Query time: 135 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Thu Jan 28 09:31:22 2010
;; MSG SIZE  rcvd: 736

Plusieurs organisations ou personnes ont déjà publiées d'intéressantes statistiques. Par exemple, l'OARC a publié « L-Root now serving "DURZ" signed responses » avec des jolis graphiques qui montrent notamment :

  • L'augmentation de taille des réponses au priming, de 630 (en moyenne) à 760 (en moyenne, c'est moins que ce que je mesure car certains résolveurs demandent sans EDNS, cf. RFC 2671),
  • Un bond considérable des requêtes en TCP, venant des résolveurs qui, bêtement, n'utilisent pas EDNS et récupèrent donc des réponses tronquées. Mais le pourcentage reste négligeable)

L'ICANN rend aussi publiques les statistiques de son serveur racine et on peut voir en http://stats.l.root-servers.org/ (attention, il y a trois sites physiques, prg, mia et lax3) que rien n'a cassé.

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)