Résumé

  • La RFC 5155 permet d’omettre certaines délégations non signées de la chaîne NSEC3 lorsqu’un enregistrement couvrant porte le drapeau Opt-Out.
  • Cet enregistrement ne confirme ni l’existence ni l’inexistence des délégations non sécurisées qu’il peut couvrir.
  • Une délégation sécurisée exige un RRset DS signé et une chaîne validée, pas seulement une signature NSEC3 correcte autour du hachage demandé.
  • Le contrôle doit conserver les résultats sécurisé, non sécurisé et indéterminé au lieu de les réduire à « DNSSEC réussi ».

Imaginons une trace de résolveur où chaque RRSIG est valide et où les hachages NSEC3 s’enchaînent correctement. Une exportation d’audit transforme ensuite cette ligne verte en « délégation enfant sécurisée ». Or le nom demandé se situe dans un intervalle Opt-Out. La preuve est authentique ; la conclusion dépasse sa portée.

Ce scénario est hypothétique. Il montre que la validité cryptographique n’élargit jamais l’assertion réellement signée.

Ce que modifie Opt-Out

La RFC 5155 définit NSEC3 comme une méthode hachée de déni d’existence authentifié. Une zone signe une chaîne ordonnée par hachage plutôt qu’une liste lisible de noms propriétaires.

Dans une zone composée surtout de délégations, produire un enregistrement NSEC3 et une signature pour chaque enfant non signé peut être coûteux. Opt-Out autorise l’exclusion des noms correspondant à certaines délégations non sécurisées. Un NSEC3 portant ce drapeau peut en couvrir zéro ou plusieurs, ce qui permet leur ajout ou leur retrait sans recalculer cette partie de la chaîne.

Cette économie change le sens de la preuve. La RFC précise qu’un NSEC3 Opt-Out ne déclare ni l’existence ni l’absence des délégations non sécurisées couvertes. Il continue d’authentifier des affirmations sur les autres données faisant autorité dans l’intervalle, mais l’enfant non signé est volontairement absent de l’inventaire cryptographique complet.

Une preuve valide peut conclure « non sécurisé »

Les données du parent au point de délégation sont décisives. La RFC 5155 appelle sécurisée une délégation dont le RRset NS est accompagné d’un RRset DS signé. Sans DS, la délégation vers l’enfant non signé est non sécurisée. Le DS relie les données authentifiées du parent au DNSKEY de l’enfant.

Valider la RRSIG du NSEC3 prouve que le parent a signé cette assertion NSEC3. Cela ne crée pas un DS pour l’enfant couvert, et le drapeau Opt-Out n’affirme pas à lui seul que cette délégation existe. La RFC 7129 résume la conséquence : ces enregistrements ne peuvent prouver ni nier l’existence des délégations non sécurisées couvertes, lesquelles ne bénéficient pas de la protection cryptographique de DNSSEC.

Le résolveur doit donc identifier le point de délégation, trouver le DS ou authentifier son absence, évaluer la preuve NSEC3 pertinente et poursuivre la validation lorsqu’une chaîne existe. Les états sécurisé, non sécurisé, erroné et indéterminé ne sont pas interchangeables.

Attacher la portée au résultat

Le dossier doit nommer la requête, le code de réponse, la zone et le point de délégation. Pour NSEC3, il conserve algorithme, itérations, sel, hachage propriétaire, hachage suivant, bitmap de types et drapeau Opt-Out. Il inclut la preuve du plus proche ancêtre démontrable lorsqu’elle intervient, ainsi que DNSKEY, RRSIG et ancre de confiance.

Le temps et le cache font partie de la conclusion. TTL, début et fin de validité des signatures, publication du parent et âge du cache bornent la preuve. Une modification ultérieure du DS peut changer l’état alors qu’une ancienne observation demeure dans l’audit.

La formule défendable reste précise : cette réponse NSEC3 signée a été validée pour cette requête et soutenait cette classification à cet instant. Elle ne signifie pas que toute délégation couverte est sécurisée.