Résumé

  • Le DET est un identifiant de forme IPv6 sur 128 bits, et non un localisateur ; RFC 9886 le projette dans le DNS inverse sous 2001:30::/28.
  • Les composantes RAA (Registered Assigning Authority) et HDA (HHIT Domain Authority) structurent la hiérarchie, déléguée sous 3.0.0.1.0.0.2.ip6.arpa.
  • Un nom DET doit renvoyer vers un enregistrement HHIT ; pour l’usage UAS Remote ID, un enregistrement BRID est également obligatoire.
  • DNSSEC est obligatoire pour les entités au sommet et recommandé pour les autres. Sans DNSSEC, le client doit parcourir la hiérarchie des certificats au moyen de recherches HHIT successives.

La vérification concrète commence par le point d’ancrage 3.0.0.1.0.0.2.ip6.arpa. L’opérateur retrouve les délégations RAA et HDA correspondant au DET, interroge les serveurs faisant autorité, puis vérifie au nom DET la présence de HHIT, RRType 67, avec le certificat d’enregistrement canonique. Dans le cas UAS, il vérifie aussi BRID, RRType 68, qui porte les informations statiques du Broadcast RID et les éventuelles attestations. Ce sont des fixtures DNS vérifiables : elles ne justifient pas la reproduction des chaînes d’octets d’exemple des appendices.

La question décisive est celle de la chaîne, pas celle d’un label qui répond. Avec DNSSEC, il faut contrôler les signatures et les délégations, selon la position de l’entité dans l’arbre. Sans DNSSEC, le client suit les certificats par des requêtes HHIT successives afin de démontrer l’enregistrement. Dans les deux cas, une réponse DNS isolée ne prouve pas l’appartenance au registre.

RFC 9886 sépare les données et pointeurs publics du DNS des registres privés. Il ne définit pas les mécanismes AAA destinés à protéger les informations permettant d’identifier des personnes. Une preuve publique de délégation, de HHIT, de BRID et de certificat ne démontre donc ni la qualité d’un processus privé, ni une règle d’éligibilité, ni une politique nationale, ni un prix.

Le DET expose une clé publique nécessaire à la vérification des signatures. Quand cela est possible, RFC 9886 recommande de retarder la publication des types d’enregistrements sous un DET jusqu’à leur nécessité. Le mécanisme de publication juste à temps reste hors périmètre. Cette recommandation concerne l’exposition ; elle ne constitue pas une garantie de confidentialité et aucune mesure de résultat en matière de vie privée n’est fournie.

Parcours de décision opérateur : 1) interpréter le DET comme un identifiant de forme IPv6 ; 2) confirmer sa position inverse sous 2001:30::/28 ; 3) vérifier les délégations RAA/HDA faisant autorité ; 4) exiger HHIT ; 5) exiger BRID pour UAS Remote ID ; 6) valider DNSSEC ou lancer la marche certificat en son absence ; 7) conserver l’état de la délégation, le chemin de certificats et l’heure d’observation ; 8) ne publier un type supplémentaire que si son utilité et son exposition sont justifiées.

Les étapes de suivi, de fraîcheur et de retrait constituent l’analyse de Theo March, et non des exigences de RFC 9886. La délégation est une surface de contrôle : la capacité de modifier un parent, un enregistrement de registre ou une chaîne de certificats peut modifier l’acceptation par les vérificateurs. Il faut donc surveiller les enregistrements obsolètes, les changements de cycle de vie et le moment de divulgation. On ne sait pas, dans le périmètre fourni, quelle est l’adoption en production, la disponibilité ou la latence d’un DIME ou d’un registre, la couverture des implémentations et résolveurs, les incidents, les abus, les effets de traçabilité ou de vie privée, ni les politiques ou tarifs propres à une juridiction.

Sources

Les errata vérifiées 8822 et 8823 corrigent des encodages d’exemple dans les appendices. Ce briefing ne reproduit pas ces chaînes d’octets et ne les présente pas comme des mesures opérationnelles.