Résumé
- Le RFC 5074, rédigé par Sam Weiler, décrit une troisième voie de validation DNSSEC pour les zones signées dont le parent ne fournit pas le DS habituel.
- DLV ne supprimait pas le besoin de confiance : le résolveur devait d’abord accepter une ancre pour un domaine DLV distinct, dont les enregistrements validés pouvaient tenir lieu de DS.
- ISC a retiré les entrées de son registre DLV en 2017 tout en conservant une zone signée vide pour les anciens résolveurs ; le RFC 8749 a retiré le mécanisme en 2020, à mesure que la délégation ordinaire se généralisait.
Une chaîne interrompue chez le parent
Une zone peut publier des signatures DNSSEC sans que le résolveur puisse les valider jusqu’à une racine de confiance. Dans le parcours normal, la zone parente publie un enregistrement Delegation Signer (DS) qui relie la clé DNSKEY de l’enfant aux données signées du parent. Si un ancêtre n’est pas signé, ou si le bureau d’enregistrement n’accepte pas le DS de la zone, la chaîne cryptographique ne peut pas remonter. Ce blocage comptait davantage au début du déploiement de DNSSEC, lorsque la racine et de nombreux domaines de premier niveau n’étaient pas encore signés.
DNSSEC Lookaside Validation a ajouté un autre chemin. Le RFC 5074 décrit des enregistrements DLV publiés dans un domaine DLV signé séparément. Ce domaine pouvait publier une entrée authentifiée pour une zone située sous une zone cible, même si elle n’était pas sa propre enfant. Le résolveur pouvait alors traiter un enregistrement DLV validé comme un DS et poursuivre la vérification des signatures de la zone. Le RFC 4431 spécifie le type d’enregistrement DLV, le numéro 32769 ; Mark Andrews et Sam Weiler en sont coauteurs. Weiler a signé seul le RFC 5074, qui documente le mécanisme et le comportement attendu des résolveurs.
La limite essentielle se trouve dans la notion d’« ancre de confiance ». DLV ne faisait pas accepter automatiquement au résolveur le registre d’un tiers. L’opérateur devait d’abord configurer une ancre pour le domaine DLV. Le mécanisme remplaçait donc un maillon manquant dans la chaîne par une autre source de confiance que l’opérateur du résolveur choisissait d’accepter. Le RFC recommande également de vérifier d’abord les ancres ordinaires applicables ; si la validation normale réussit, le traitement DLV n’a pas lieu.
Lorsque plusieurs domaines DLV se chevauchent, le RFC laisse la priorité aux implémentations et recommande de rendre ce choix visible dans la configuration.
La transition devait avoir une fin maîtrisée
ISC indique que son registre DLV a commencé à fonctionner en 2006 comme aide temporaire au déploiement de DNSSEC. À mesure que la racine puis les délégations de premier niveau devenaient signées, cette voie supplémentaire perdait de son utilité. Le RFC 8749, publié en 2020 par W. Mekking et Dan Mahoney, rappelle que la racine a été signée en juillet 2010 et que 1 389 des 1 531 domaines de premier niveau bénéficiaient d’une délégation sécurisée depuis la racine en mai 2019. Il reclassifie les RFC 4431 et 5074 comme historiques.
Le retrait n’a pas été qu’une mention dans un registre de normes. ISC a supprimé les données de DLV le 30 septembre 2017, mais a conservé dlv.isc.org sous forme de zone signée vide. Selon ISC, supprimer entièrement cette zone aurait conduit des résolveurs BIND encore configurés pour DLV à renvoyer SERVFAIL pour de nombreuses requêtes. La zone vide permettait aux configurations anciennes de continuer à répondre sans trouver d’entrée DLV obsolète, tandis que le registre cessait d’affirmer quoi que ce soit sur la validation.
Le RFC 8749 expose les arbitrages : DLV pouvait réduire la pression sur les zones parentes pour qu’elles signent et sur les bureaux d’enregistrement pour qu’ils acceptent des DS ; il ajoutait aussi du code de validation. Les auteurs mentionnent des implémentations dans BIND 9 et Unbound et aucune utilisation connue en entreprise privée. Ces constats décrivent l’état du dossier lors de la publication, pas un inventaire actuel des résolveurs.
L’histoire permet une conclusion plus limitée : DLV a servi de voie de transition dont l’intérêt a diminué avec l’amélioration de la chaîne ordinaire, et son opérateur a prévu une période de compatibilité pour les anciennes configurations.
La Note 64 de Heng Lu sert uniquement de grille éditoriale : elle invite à examiner si un mécanisme commun reste limité et si les changements suivent l’adoption effective. Elle ne constitue pas une preuve sur Weiler ou DLV.
Sources
- RFC 4431 — The DNSSEC Lookaside Validation (DLV) DNS Resource Record
- RFC 5074 — DNSSEC Lookaside Validation (DLV)
- RFC 8749 — Moving DNSSEC Lookaside Validation (DLV) to Historic Status
- ISC — DNSSEC Look-Aside Validation Registry
- ISC — désactiver dnssec-lookaside après son retrait
- Sources d’identité uniquement : profil Sam Weiler dans IETF Datatracker ; photo légendée de l’équipe W3C ; collage de référence officiel
- Grille éditoriale uniquement : Heng Lu, Note 64
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
