Résumé

  • La RFC 9083 définit delegationSigned comme vrai lorsque des enregistrements DS existent dans la zone parente ; zoneSigned et les données DS ou de clé sont des éléments distincts de l’objet RDAP secureDNS.
  • Ce champ est une preuve d’enregistrement, non un résultat de validation en direct. Une conclusion DNSSEC défendable exige aussi le DS parent actuel, les DNSKEY et RRSIG de l’enfant, l’accessibilité des serveurs, la validité temporelle et le résultat d’un validateur identifié.

Un booléen précis au champ d’application limité

La réponse LACNIC échantillonnée pour 84.7.200.in-addr.arpa expose clairement son état. L’objet est de classe domain. Il énumère trois serveurs de noms et un objet secureDNS où zoneSigned et delegationSigned valent tous deux faux, avec un tableau dsData vide.

Cette réponse constitue une preuve utile sur l’enregistrement retourné par LACNIC au moment de l’observation. Elle ne permet pas de généraliser à toutes les zones inverses de la région LACNIC et ne décrit pas l’état opérationnel actuel des serveurs listés. Elle ne contient ni trace de résolveur ni paquets permettant d’en reconstruire une.

La présence du DS parent n’est qu’un maillon

La RFC 9083 sépare volontairement les significations. zoneSigned indique si la zone est signée. delegationSigned indique si des enregistrements DS existent chez le parent. dsData peut décrire le tag de clé, l’algorithme, le condensat et son type ; keyData peut porter des données DNSKEY.

Ces champs décrivent des données d’enregistrement. La validation DNSSEC est une opération effectuée sur une chaîne de réponses DNS vivantes à un instant déterminé. Le validateur doit obtenir le DS parent, récupérer les DNSKEY et les enregistrements signés de l’enfant, comparer condensats et algorithmes, contrôler les signatures et leurs périodes de validité, puis traiter les échecs de réponse ou d’accès. Aucun booléen RDAP n’accomplit silencieusement ces étapes.

Vrai et faux exigent la même discipline

Lorsque delegationSigned vaut vrai, la formulation justifiable est que la représentation RDAP signale des DS dans le parent. Elle ne prouve pas que l’enfant publie la DNSKEY correspondante, que les signatures sont valides à cet instant, que la chaîne atteint une ancre de confiance ou qu’un résolveur donné valide avec succès.

Lorsque la valeur est fausse, la représentation RDAP signale l’absence de DS parent selon la définition du champ. Elle n’explique pas cette absence, ne tranche pas l’état d’une modification en cours et ne garantit pas qu’une observation ultérieure sera identique. Il faut conserver l’URL, les octets de la réponse et l’heure de collecte.

Construire un dossier à deux surfaces

La surface de registre doit conserver l’URL exacte de l’objet RDAP, ldhName, les serveurs de noms, les valeurs secureDNS, les tableaux DS ou de clés, le condensat de la réponse et l’heure de récupération. La surface opérationnelle doit enregistrer séparément les requêtes DNS vers le parent et l’enfant, les adresses des serveurs, les codes de réponse, les drapeaux d’autorité, les DNSKEY, DS et RRSIG, le résultat du validateur et le contexte temporel.

Ce n’est qu’après comparaison de ces deux surfaces qu’un analyste peut décrire la validation actuelle. Même alors, le résultat reste lié au point d’observation et à l’heure identifiés. Une chaîne cryptographique valide n’établit ni propriété, ni droit contractuel, ni contrôle des hôtes.

Sources