Résumé

  • Le DET utilise le préfixe 2001:30::/28 et prend la forme d’une adresse IPv6 valide mais non routable : il identifie une place dans une hiérarchie, pas une destination réseau ni des coordonnées.
  • Le type HHIT 67 transporte les métadonnées et le certificat canonique d’enregistrement ; le type BRID 68 contient des informations statiques de Broadcast RID et des endorsements.
  • DNSSEC peut authentifier la provenance de la réponse DNS, sans prouver la présence physique, l’usage actuel de la clé, l’accès légitime aux données privées ou le droit de voler.

Un analyste n’a vu aucun aéronef. Son récepteur radio n’a capté aucun message. Pourtant, sa console affiche une chaîne entièrement verte : nom inverse trouvé, HHIT présent, BRID présent, DNSSEC validé, certificat accepté. La machine propose alors une conclusion qui paraît naturelle : « aéronef localisé ».

La chaîne cryptographique peut être correcte et la conclusion fausse.

La RFC 9886 décrit l’enregistrement DNS des DRIP Entity Tags, ou DET. Elle permet de remonter de l’identifiant vers une hiérarchie, une clé publique, un certificat et des endorsements. Elle ne transforme pas un serveur de noms en capteur aéronautique. La résolution répond à une question documentaire ; la position est une question physique.

L’ambiguïté vient de la forme du DET. La RFC 9374 lui attribue 2001:30::/28 et qualifie les HHIT d’adresses IPv6 valides, quoique non routables. Ce choix réutilise un format de 128 bits et l’outillage de nommage inverse. Il ne crée aucune route vers l’appareil et n’encode ni latitude, ni longitude, ni volume aérien.

Le préfixe se place sous 3.0.0.1.0.0.2.ip6.arpa. Les chiffres de chaque DET sont inversés par demi-octet comme pour IPv6, mais la requête ne demande pas le PTR traditionnel. Elle vise les types HHIT ou BRID. Ce qui revient du DNS est une description publique de l’identifiant.

Le certificat et l’endorsement ne racontent pas le même fait

Chaque DET doit résoudre vers un enregistrement HHIT. Dans le cas du Remote ID des UAS, un enregistrement BRID doit aussi exister. Leur coexistence n’en fait pas deux copies du même statut.

Le HHIT RR type 67 comprend un type d’entité, une abréviation de hiérarchie et un certificat canonique d’enregistrement. Ce certificat porte la clé publique de l’entité et la signature du registrar ou d’un autre ancrage de confiance. Sa validation peut confirmer l’inclusion du DET dans la hiérarchie annoncée. Il peut également contenir l’URI d’une ressource privée.

Le BRID RR type 68 conserve les données de Broadcast RID qui sont statiques. Il sert surtout à publier les Broadcast Endorsements produits par le registrar après l’enregistrement. Il peut remplacer une information statique que la réception radio a manquée, ou aider à une validation croisée.

Il ne constitue pas pour autant un journal de réception radio. Trouver un BRID dans le DNS ne démontre pas qu’un observateur a entendu ce message pendant le vol présent. Le registre public et la diffusion locale ont des capteurs, des horloges et des portées différentes.

La RFC 9434 va plus loin : un DET auto-affirmé ne suffit pas à prouver l’identité de l’émetteur. La possession apparente du DET et la répétition d’un contenu signé se prêtent au rejeu. Une preuve actuelle suppose des données nouvelles, variables et vérifiables extérieurement. Une position signée doit, par exemple, rester cohérente avec l’aéronef réellement observé à cet instant. L’authentification du message n’est toujours pas une mesure indépendante de sa position.

DNSSEC protège le chemin de réponse, pas le monde décrit

La RFC 9886 impose DNSSEC aux entités apex dont le certificat canonique est auto-signé et le recommande aux autres. Sans DNSSEC, des réponses falsifiées peuvent faciliter déni de service, rejeu, usurpation ou clonage d’aéronef, détournement d’enregistrement DET, injection de métadonnées et rupture des relations de confiance. En l’absence de DNSSEC, le client doit parcourir l’arbre des certificats HHIT ; les endorsements BRID conservent leur propre validation.

La validation DNSSEC établit l’origine et l’intégrité d’une donnée DNS dans sa chaîne. Elle n’observe rien dans le ciel. Elle ne confirme pas que l’opérateur attendu détient encore la clé privée, qu’une opération est active, que la position déclarée est exacte ou qu’une autorité de l’aviation civile a permis le vol.

Une zone peut signer fidèlement une affirmation erronée. Un enregistrement authentique peut aussi être trop ancien ou incomplet pour la décision en cours. Le statut secure a donc un sens technique précis ; il ne doit jamais devenir un label général de vérité.

Une adresse de registre privé n’est pas une autorisation

Le DNS public peut fournir un pointeur vers des informations privées. La RFC 9886 laisse volontairement hors de son périmètre les mécanismes d’authentification, d’autorisation et de comptabilité qui protègent les données personnelles. La RFC 9434 situe dans cette couche le numéro de série du constructeur, l’identifiant d’intention opérationnelle et d’autres données réglementées.

Un service de sécurité publique, un fournisseur de service aérien et un passant peuvent partir du même DET sans recevoir le même accès. Le DNS indique où demander ; le registre privé décide qui peut savoir, pour quel motif et selon quelle règle locale. La réussite de la consultation publique n’est pas un jeton d’accès privé.

Même l’identité révélée ne vaut pas permission de voler ou d’intervenir. Le registrar enregistre sans piloter. Le fournisseur UAS peut signaler une opération sans exercer le pouvoir réglementaire. Le récepteur peut authentifier une émission sans certifier les coordonnées déclarées.

La publication possède son propre cycle

Publier le HHIT d’un DET expose la clé publique nécessaire aux vérifications. La RFC 9886 recommande donc, lorsque c’est possible, d’attendre qu’un tiers en ait besoin. Elle envisage qu’un UAS ou un composant UTM signale le début prochain ou la fin d’une opération utilisant un Specific Session ID.

Ce mécanisme réduit potentiellement l’exposition, mais il n’est pas un protocole complet de cycle de vie. L’association entre publication juste à temps et DNSSEC est hors périmètre. Une absence peut signifier aucun vol, un échec de publication, une délégation cassée ou une politique restrictive. Une présence peut survivre à l’opération. L’automatisation doit garder la cause au lieu d’inventer un état aérien unique.

Les standards fournissent des preuves bien délimitées. Ils ne fournissent pas un voyant universel « drone localisé ». La primauté du code en fonctionnement impose de conserver ce que chaque composant a effectivement observé, à son heure, et rien de plus.

Sources