Résumé

  • La RFC 3130 constata que les ateliers DNSSEC d’un ou deux jours produisaient moins d’enseignements, car les problèmes restants dépendaient de l’expiration, des validations répétées, du roulement des clés et des relais institutionnels.
  • Un seul logiciel complet ne suffisait pas à prouver l’interopérabilité : la progression du standard exigeait plusieurs implémentations et une expérience opérationnelle réussie.
  • DNSSEC était un ensemble de composants inégalement mûrs ; TSIG pouvait protéger utilement un transfert de zone sans rendre prête la validation publique dans son ensemble.

Le rapport publié sous le numéro RFC 3130 n’annonçait pas une victoire de DNSSEC. Il consignait un changement de méthode.

Depuis 1999, des ateliers avaient réuni spécifications et premières implémentations. On pouvait signer une zone, faire circuler des enregistrements et obtenir une validation. La RFC 2535 fournissait le noyau technique. BIND 8.2 en réalisait une partie et BIND 9 était présenté comme la première implémentation complète. Pourtant DNSSEC n’était pas d’usage courant.

Les premiers ateliers trouvaient rapidement des défauts. À mesure que les erreurs évidentes disparaissaient, répéter un événement d’un ou deux jours rapportait moins. La réunion associée à l’IETF 49 ne conclut pas que le système était prêt. Elle observa que les questions importantes avaient changé d’échelle temporelle.

Une signature peut rester valide pendant toute une démonstration. Un renouvellement peut ne pas avoir lieu. Une validation parent-enfant peut réussir une fois sans traverser le prochain changement. Les caches peuvent ne jamais atteindre l’expiration pertinente. Pour comprendre ces phénomènes, il fallait des configurations continues, capables de vivre assez longtemps pour rencontrer les horloges du protocole.

Cette durée révélait aussi les institutions. Un projet suédois distinguait registre, bureau d’enregistrement, titulaire et opérateur DNS. Ces quatre rôles pouvaient être réunis ou répartis entre plusieurs entités. Le roulement d’une clé devenait alors une succession d’actes techniques, administratifs et commerciaux. La bonne donnée devait arriver chez le bon acteur avant que l’ancienne autorité ne cesse d’être utilisable.

Les grands registres étudiaient la validation par le parent des clés de chaque zone déléguée. NLnet Labs jugeait certaines procédures de roulement trop lourdes pour les grands TLD. Les conseillers du système racine demandaient des bancs de longue durée. Les RIR examinaient la signature des arbres inverses. Les applications et les services informatiques ordinaires restaient moins documentés.

Le mot DNSSEC risquait lui-même de brouiller le diagnostic. RFC 3130 parlait d’une boîte à outils : signatures publiques selon RFC 2535, TSIG selon RFC 2845, mise à jour dynamique sécurisée selon RFC 3007 et enregistrements CERT. Le regroupement était qualifié d’artificiel. Ces éléments étaient liés, mais ils ne partageaient ni la même échelle ni la même maturité.

TSIG pour les transferts de zone était déjà considéré comme une très bonne pratique. Cela ne certifiait pas la chaîne publique de délégations signées. Un secret partagé entre interlocuteurs locaux ne rencontre pas les mêmes autorités qu’une validation Internet entière. La réussite d’un composant ne devait pas masquer les inconnues des autres.

L’interopérabilité posait une deuxième limite. D’après le processus décrit par RFC 2026, le passage au niveau suivant demandait au moins deux implémentations interopérables et une expérience opérationnelle suffisante. Or BIND était le seul logiciel sérieusement équipé pour l’ensemble de DNSSEC. Une implémentation unique pouvait être cohérente avec elle-même ; elle ne révélait pas les interprétations divergentes de deux équipes indépendantes.

La réunion identifia donc la nécessité d’une seconde implémentation dans un horizon d’environ dix-huit mois. Cette phrase décrit un besoin, non une livraison. Une intention de réunion ne vaut pas artefact, pas plus qu’une démonstration ne vaut déploiement.

Le dernier maillon était l’usage. Des projets tentaient de faire consommer des données DNSSEC à secure shell ou à d’autres logiciels. Mais les interfaces ordinaires du système d’exploitation n’avaient pas encore défini comment transmettre le résultat de validation. Une réponse signée qui n’influence aucune application reste une preuve sans effet. Une application qui transforme cette preuve en autorisation générale lui donne au contraire trop de pouvoir.

Des questions de protocole persistaient. NXT devait prouver l’inexistence d’une donnée, mais certains estimaient que la solution pouvait coûter plus qu’elle ne réparait. Les éléments de validation parentale se stabilisaient plus vite que les procédures opérationnelles. Les mesures suggéraient que CPU et mémoire ne bloquaient pas nécessairement la signature de grandes zones ; cela ne résolvait ni le roulement ni les relais entre organisations.

Voilà la frontière historique : faisable en calcul ne veut pas dire prêt en exploitation. Implémentable ne veut pas dire interopérable. Valide aujourd’hui ne veut pas dire cohérent après une expiration. Un élément mûr ne rend pas mûre toute la boîte.

Les RFC 4033, 4034 et 4035 remplacèrent ensuite l’architecture de RFC 2535. RFC 6781 rassembla des pratiques de clés, signatures et roulements. RFC 5011 décrivit une mise à jour automatique des ancres de confiance, fondée elle-même sur des états temporisés. Ces textes prouvent une évolution ultérieure, pas une causalité simple ni l’achèvement de tous les projets de 2001.

La leçon dépasse DNSSEC. La durée d’un test appartient à son périmètre. Lorsqu’une autorité expire, se renouvelle, traverse un cache ou dépend de plusieurs institutions, un essai plus court que ces processus ne peut pas les valider. Multiplier les démonstrations rapides ne fabrique pas le temps absent.

RFC 3130 saisit ainsi le moment où une communauté modifia sa définition de la preuve. Les ateliers courts n’avaient pas échoué ; ils avaient épuisé ce qu’ils pouvaient observer. Les problèmes restants vivaient au-delà de leur calendrier.

Sources