Résumé

  • NSEC et NSEC3 authentifient des propositions négatives précises sur le contenu d’une zone signée. La preuve dépend du signataire, de la zone, de la requête, du TTL et de la période de validité de la signature.
  • Opt-Out autorise des délégations non sécurisées à ne pas avoir leur propre NSEC3. Un intervalle signé peut alors établir l’absence de DS sans établir l’inexistence de chaque nom sauté.

Une preuve négative n’est pas une histoire complète

Quand un résolveur demande un enregistrement absent, le serveur faisant autorité renvoie soit NXDOMAIN, soit une réponse sans le type demandé. Dans une zone non signée, le client dépend du serveur et du chemin. Dans une zone DNSSEC, il peut vérifier une chaîne de confiance, des signatures et une preuve NSEC ou NSEC3.

La protection est substantielle : un attaquant ne peut pas remplacer librement une réponse positive par une négation et la faire accepter à un validateur. Pourtant, l’expression « déni d’existence authentifié » doit rester dans son périmètre protocolaire. Le RFC 4035 parle d’un RRset absent d’une zone signée. Il ne parle pas d’un nom qui n’aurait jamais existé, d’un droit contractuel éteint ou d’une suppression légitime.

La même absence publique peut suivre des causes différentes : aucune inscription, expiration, suspension, erreur de provisionnement, déplacement d’une délégation ou zone signée incorrecte. DNSSEC permet de vérifier ce que le signataire a publié. Il ne reconstitue pas l’intention ni l’autorité qui devait précéder la publication.

NSEC transforme l’ordre de la zone en preuve

Un enregistrement NSEC relie un nom propriétaire au prochain nom dans l’ordre canonique et contient une carte des types présents au premier nom. L’intervalle signé prouve qu’aucun propriétaire intermédiaire n’existe. La carte prouve qu’un nom peut exister tout en ne possédant pas le type demandé.

Il faut donc distinguer NXDOMAIN, l’absence d’un nom, de NODATA, l’absence d’un type. Un non-terminal vide peut avoir des descendants. Un joker impose encore un autre test : le serveur et le validateur doivent montrer qu’aucune correspondance exacte ou source de joker plus proche ne change la réponse.

Une négation validée est ainsi un petit raisonnement. Quelle zone devait contenir la donnée ? Quel intervalle couvre le nom ? Quelle carte couvre le type ? Un joker était-il possible ? La signature est-elle temporellement valide et reliée à l’ancre de confiance ?

NSEC rend aussi l’ordre des noms observable et permet le parcours de zone. NSEC3 a été conçu en partie pour réduire cette divulgation, mais le compromis reste visible : une preuve vérifiable peut exposer une structure que l’opérateur préférait ne pas publier.

NSEC3 masque les labels sans créer le secret

NSEC3 hache les noms avec des paramètres publiés, puis signe des intervalles de valeurs hachées. Le résolveur reproduit le calcul pour démontrer le plus proche ancêtre existant, l’absence du nom et, si nécessaire, l’absence d’un joker.

Le hachage gêne l’énumération directe sans rendre les labels secrets. Des noms prévisibles peuvent être essayés hors ligne. Le registre IANA ne contient aujourd’hui que SHA-1 comme algorithme de hachage NSEC3 attribué. Le RFC 9276 explique que multiplier les itérations ajoute du coût aux signataires et aux validateurs sans créer une défense proportionnée contre la devinette moderne. Il recommande généralement zéro itération, un sel vide et NSEC lorsque l’énumération n’est pas préoccupante.

Leçon de gouvernance : un paramètre de sécurité plus grand n’est pas automatiquement une meilleure politique. Il faut mesurer ce que le code exécuté protège et qui paie le coût collectif.

Opt-Out limite la conclusion possible

Dans une grande zone composée surtout de délégations, signer une preuve propre à chaque enfant non sécurisé augmente fortement la taille de la zone. Opt-Out permet d’omettre certaines délégations sans DS et les non-terminaux vides qu’elles créent.

Le drapeau change la sémantique. Le RFC 7129 précise qu’un NSEC3 Opt-Out ne peut ni prouver ni nier l’existence des noms couverts par son intervalle. Il peut contribuer à démontrer qu’aucun DS authentifié n’a sécurisé une délégation candidate. Il ne doit pas devenir nom_absent=true dans un entrepôt de données.

La bonne trace sépare l’intervalle signé, le drapeau Opt-Out, l’absence de DS, la présence éventuelle d’une délégation non sécurisée et le résultat final du validateur. Un écran vert indiquant seulement « authentifié » perd la limite la plus importante de la preuve.

Le cache devient un dépositaire de la preuve

Le RFC 2308 permet la mise en cache négative. Le RFC 8020 autorise une coupure NXDOMAIN pour les descendants. Le RFC 8198 autorise un validateur à synthétiser de nouvelles réponses négatives à partir d’intervalles NSEC ou NSEC3 déjà validés.

Le résolveur peut donc répondre sans demander de nouveau au serveur faisant autorité. Il réduit latence, charge et fuite de requêtes. Mais l’utilisateur observe alors l’état signé représenté par une preuve encore valide, pas nécessairement la zone la plus récente. Le TTL, l’instant de réception, le début et la fin de signature et la provenance du cache deviennent des faits d’audit.

Une capture d’écran NXDOMAIN ne suffit pas. Il faut conserver la requête, le code, la zone, les preuves, le plus proche ancêtre, le test de joker, Opt-Out, la chaîne de validation et la question de savoir si la réponse vient de l’autorité ou d’une synthèse locale.

La signature ne décide pas la légitimité d’une suppression

Le registre contrôle une transaction et parfois la zone. Le titulaire peut avoir un droit contractuel. Un opérateur DNS publie des données. Un résolveur contrôle son cache. Un organe de recours peut ordonner un remède défini. La preuve NSEC ne fusionne pas ces rôles.

Elle ne montre pas qu’un avis a été envoyé, qu’un paiement a échoué, qu’une condition d’éligibilité a cessé ou qu’un recours a été entendu. Elle n’autorise pas un tiers à obtenir le label. Elle ne transforme pas le signataire en propriétaire du nom.

La piste responsable relie sans les confondre : dossier d’inscription, décision autorisée de provisionnement, version de zone signée et observations des validateurs. La zone est la réalité publique opérante. Les autres dossiers expliquent sa formation et permettent de la contester.

La couche commune minimale

Le principe de couche minimale de Heng Lu situe la frontière. Le système partagé doit distinguer donnée validée, absence validée, délégation non sécurisée et preuve bogus. Il n’a pas besoin de devenir une juridiction mondiale des noms.

Le code exécuté reste décisif : zone cut, chaîne DS/DNSKEY, paramètres NSEC3, intervalle, Opt-Out, joker, TTL, fenêtre de signature et politique du validateur. Une règle ne rend pas valide une mauvaise preuve ; une bonne signature ne transforme pas une règle en mandat universel.

La conclusion exacte est donc modeste : DNSSEC authentifie ce qu’une zone signée ne contenait pas, à un moment borné et selon des règles déterminées. La cause de l’absence et le droit au nom restent des décisions séparées.

Sources