Résumé

  • RFC 9718 sépare le matériau de la clé racine DNSSEC des mécanismes qui authentifient son fichier de diffusion ; l’AC d’ICANN et la PKI Web ne sont pas l’ancre DNSSEC.
  • Une ancre exploitable suppose cinq jugements distincts : fichier authentique, période admissible, représentations cohérentes, analyse prise en charge et acceptation explicite par l’opérateur.

Une chaîne de confiance se raconte aisément du haut vers le bas. Le validateur part d’une clé réputée fiable, vérifie la racine, puis suit les délégations signées. La question difficile regarde dans l’autre sens : qui a vérifié la première clé ?

RFC 4033 ne dissimule pas cette limite. Une ancre est une DNSKEY faisant autorité, ou l’empreinte DS correspondante, configurée dans un validateur. Sa valeur initiale vient d’un moyen sûr ou digne de confiance extérieur au DNS. DNSSEC authentifie ce qui suit l’ancre, pas la décision qui l’a rendue fiable.

C’est l’apport durable de RFC 9718, cosigné par Joe Abley et publié comme RFC IETF de catégorie Informational en janvier 2025. Le texte remplace RFC 7958 et décrit la publication par l’IANA des informations d’ancrage de la zone racine. Il ne supprime pas la confiance hors bande ; il nomme ses raccords.

Le premier raccord sépare l’objet de son enveloppe. L’IANA diffuse un document XML contenant des éléments KeyDigest. Une signature CMS détachée peut remonter à une autorité de certification contrôlée par l’ICANN ; HTTPS peut authentifier le transport au moyen de la PKI Web. Ces mécanismes aident à établir l’origine attendue du document et son intégrité.

Mais l’AC d’ICANN n’est pas une ancre DNSSEC, précise RFC 9718. La chaîne de certificats authentifie l’objet publié. L’empreinte ou la clé publique contenue dans cet objet ne devient une ancre DNSSEC qu’après traitement et acceptation. Employer « racine de confiance » pour les deux efface deux systèmes différents et le moment où l’opérateur change effectivement l’état du validateur.

La rupture avec RFC 7958 accentue cette clarté. L’ancien dispositif comportait des certificats PKIX et des demandes de signature par clé, ainsi qu’un mécanisme OpenPGP détaché. RFC 9718 les retire parce qu’ils mélangeaient la confiance hors bande dans les clés d’authentification et celle accordée aux clés racines DNSSEC. Davantage d’emballage cryptographique ne supprimait pas le choix initial.

Le XML contient lui-même plusieurs états. validFrom et validUntil bornent la période pendant laquelle un KeyDigest peut être retenu. Elles ne prouvent pas son installation générale et ne l’ordonnent pas. Un fichier correctement signé mais ancien n’est donc pas automatiquement une configuration actuelle recevable.

Le champ facultatif publickeyinfo peut joindre une clé publique DNSKEY et ses flags au condensat. Il permet de reconstruire directement une DNSKEY, mais impose une vérification : si la clé et le condensat divergent, le KeyDigest ne doit pas être utilisé. Une signature CMS valide ne répare pas une contradiction interne.

Le caractère facultatif crée aussi une différence de capacité locale. Deux logiciels conformes peuvent tirer des ensembles distincts du même XML authentique si l’un comprend publickeyinfo et l’autre non. Une provenance commune ne garantit pas une interprétation uniforme ; version du parseur, transformation et sortie appartiennent au reçu opérationnel.

Même l’attribut XML source n’est qu’indicatif. Une URL localise un document ; sa présence dans celui-ci ne lui confère aucun pouvoir. Une adresse n’est pas un mandat.

Vient enfin l’acceptation. RFC 9718 laisse à l’opérateur du validateur le choix d’accepter ou non les ancres selon sa propre politique. L’IANA publie, les systèmes de certificats contribuent à vérifier l’origine, les développeurs analysent, les fournisseurs empaquettent et l’opérateur décide ce qui entre dans l’état de confiance du résolveur.

RFC 5011 n’abolit pas ce premier choix. Il permet à un validateur qui possède déjà une ancre de reconnaître un successeur dans le protocole après une période d’observation. La confiance existante authentifie la transition ; elle ne peut pas remonter dans le temps et justifier l’installation initiale.

La page actuelle de l’IANA matérialise ces surfaces : root-anchors.xml contient les données, root-anchors.p7s la signature détachée et icannbundle.pem les certificats servant à la vérifier. Elle note que les fournisseurs ne distribuent pas tous leurs mises à jour de la même manière ni au même moment.

Dans son avis de novembre 2024, l’IANA demandait une récupération régulière du XML et des essais du format révisé. Une publication réussie n’est donc pas un déploiement réussi : le fichier peut être authentique et actuel tandis qu’un parseur le refuse, qu’un paquet reste ancien ou qu’un opérateur ne l’adopte pas.

Le fichier actif root-anchors.xml est l’objet lisible par la machine, non une déclaration d’acceptation par un résolveur donné.

La biographie de NSRC rappelle qu’Abley a dirigé les opérations DNS de l’ICANN et participé au déploiement DNSSEC de la racine. Cela ne fait pas de lui le souverain de la racine. Cela explique plutôt la discipline d’exploitation du RFC : deux preuves voisines ne doivent pas se faire passer l’une pour l’autre.

Un reçu défendable doit conserver cinq réponses : comment l’origine et le contenu ont-ils été vérifiés ? L’entrée était-elle dans sa période valide ? Les représentations concordaient-elles ? Quel parseur a produit l’ancre candidate ? Qui l’a acceptée, dans quel validateur et selon quelle règle ? « Signature valide » ne répond qu’à la première question.