Résumé

  • Le drapeau Opt-Out autorise un intervalle NSEC3 signé à couvrir des délégations non sécurisées sans affirmer qu’elles existent ni qu’elles n’existent pas. L’absence d’un nœud dans la chaîne n’est donc pas une preuve d’absence dans la zone.
  • L’opérateur du parent doit réconcilier quatre surfaces : registre source, sortie du signataire, réponses NS/DS de chaque serveur faisant autorité et observation du validateur. Toute conclusion d’inventaire tirée de la chaîne seule dépasse la portée de la preuve.

Un audit automatisé reçoit tous les NSEC3 d’une zone parente et reconstruit l’anneau des condensats. Aucun nœud ne correspond au nom enfant qu’il contrôle. Le rapport conclut : « délégation absente ». Quelques secondes plus tard, une requête directe adressée au parent renvoie une référence NS ordinaire vers cet enfant, sans DS. La délégation existe ; elle n’est simplement pas sécurisée.

Ce cas est illustratif, mais la règle ne l’est pas. RFC 5155 permet d’exclure le nom condensé d’une délégation non sécurisée lorsque l’intervalle qui le couvre porte le drapeau Opt-Out. La signature de l’intervalle reste valide. Elle ne certifie ni l’existence ni la non-existence des délégations éligibles qui se trouvent à l’intérieur.

L’erreur de l’audit n’est donc pas une mauvaise vérification cryptographique. C’est une erreur de compétence : il a transformé une projection destinée aux preuves négatives en registre exhaustif de la zone.

Le registre précède la projection

La zone parente possède d’abord un état opérationnel. Pour chaque coupure de délégation, cet état associe un nom, un RRset NS, éventuellement des enregistrements glue, un éventuel RRset DS, un historique de changement et une décision de publication. Le signataire part de cet état pour construire NSEC ou NSEC3.

NSEC3 remplace les noms propriétaires lisibles par des condensats classés dans l’espace de hachage. Chaque record indique le condensat suivant et les types présents au nom original. Avec les RRSIG correspondants, un validateur peut démontrer qu’un nom ou un type demandé n’existe pas selon les règles applicables. Il ne reçoit pas pour autant une copie réversible de la base de délégations.

Opt-Out rend cette différence explicite. Une délégation non sécurisée possède NS mais pas DS au parent. Son nom condensé peut être omis. Une délégation sécurisée, un nom autoritatif ordinaire ou un RRset DS ne deviennent pas facultatifs parce que la chaîne serait plus courte. Chaque omission doit être reliée à une délégation réellement éligible et à un intervalle Opt-Out précis.

Le dossier minimal doit donc conserver le nom source, son état NS/DS, l’identifiant de génération du signataire, les paramètres NSEC3, le condensat calculé, le record couvrant, son drapeau, sa bitmap et les réponses réellement servies. Un simple champ « DNSSEC valide » détruit ces distinctions.

L’intervalle ne dit pas « vide »

Un intervalle Opt-Out n’est pas un sac de noms inexistants. Il constitue une zone d’indétermination volontaire pour les délégations non sécurisées qu’il peut couvrir. Le même intervalle continue à produire des affirmations valides concernant d’autres données autoritatives ; sa portée n’est donc ni nulle ni universelle.

Cette nuance impose une valeur de sortie différente aux outils. Lorsqu’un nom tombe dans un tel intervalle, un inventaire dérivé doit répondre indéterminé depuis la chaîne, jamais absent. Pour trancher, il faut consulter le registre source autorisé, un transfert de zone auquel l’opérateur a droit, ou les réponses directes NS et DS du parent.

La même frontière existe côté résolveur. RFC 8198 autorise l’exploitation agressive de certaines preuves NSEC/NSEC3 déjà validées pour fabriquer des réponses négatives en cache. Mais un record couvrant avec Opt-Out ne prouve pas que le nom n’existe pas. Le résolveur ne peut donc pas synthétiser cette absence à travers l’intervalle.

Un produit de sécurité qui ferait malgré tout cette synthèse ne serait pas « plus strict » que le DNSSEC. Il inventerait une affirmation que le signataire n’a jamais émise.

Le plus proche peut rester improuvable

Les réponses négatives et les wildcards dépendent du closest encloser, le plus long ancêtre existant du nom demandé. Dans une zone Opt-Out, une délégation omise ou un empty non-terminal qui n’existe qu’à cause d’elle peut ne pas disposer de son propre nœud NSEC3. La preuve s’arrête alors au closest provable encloser : l’ancêtre le plus long dont la chaîne peut démontrer l’existence.

Le journal de validation doit conserver cette différence, le next-closer calculé, les records correspondants ou couvrants, la possibilité de retour circulaire dans l’espace de hachage, la bitmap, les RRSIG et l’heure de validation. Une interface verte qui ne garde que « sécurisé » ne permet pas de reconstruire pourquoi la preuve a utilisé cet ancêtre plutôt qu’un autre.

Des paramètres plus simples, pas plus décoratifs

RFC 9276 recommande aujourd’hui d’utiliser NSEC lorsque les propriétés de NSEC3 ne sont pas nécessaires. Si NSEC3 est retenu, le socle recommandé est l’algorithme 1, zéro itération supplémentaire et un sel vide.

Les itérations augmentent le coût de calcul des serveurs et des validateurs sans rendre les noms prévisibles secrets. Le sel modifie les condensats, mais ne fait pas disparaître les attaques par dictionnaire. Une valeur élevée ne constitue donc pas un signe de maturité. Selon sa politique, un validateur peut traiter des itérations non prises en charge comme non sécurisées ou renvoyer SERVFAIL ; après validation du record concerné, il peut signaler l’Extended DNS Error 27. Ce résultat décrit une limite de calcul, pas l’absence d’une délégation.

Opt-Out n’est pas recommandé pour les petites zones. Son emploi peut se justifier dans une zone très grande, centrée sur les délégations et majoritairement composée d’enfants non sécurisés. La justification devrait être mesurée : nombre de délégations, fréquence des changements, part sécurisée, coût de signature et capacité de réconciliation. Une ancienne valeur par défaut du logiciel ne suffit pas.

Changer de paramètres signifie changer de génération

Le NSEC3PARAM publié à l’apex aide à décrire la génération, mais le validateur traite les paramètres présents dans les NSEC3 qu’il vérifie. Modifier sel ou itérations exige de construire une nouvelle chaîne complète et de signer de nouveau la zone.

Avant activation, l’opérateur compare le registre source, les deux générations, les fenêtres RRSIG et l’état de transfert de chaque secondaire. Il teste un nom inexistant connu, une délégation non sécurisée omise, une délégation sécurisée et une frontière wildcard. Après activation, il interroge chaque adresse autoritative et tient compte des anciennes preuves encore en cache.

La possibilité de revenir à la dernière génération cohérente est plus importante qu’un déploiement rapide. Une flotte joignable mais divisée entre deux chaînes n’offre pas un état unique simplement parce que chaque serveur signe correctement sa propre réponse.

Sources