Summary

  • RFC 9886 maps DRIP Entity Tags into reverse DNS and defines HHIT and BRID records for public registration and static Remote ID material.
  • A DET is explicitly an identifier rather than a locator: a valid answer does not prove the aircraft's present position, operation, private-key possession or message delivery.
  • Safe automation must retain an evidence ladder from authoritative DNS and DNSSEC through certificate validation and on-air proof of possession to independent sensor correlation.

The alert looked unusually complete. An observer had captured a 128-bit DRIP Entity Tag. A resolver returned an HHIT record containing a public key and canonical registration certificate. A BRID query returned static Broadcast Remote ID information. The certificate chain checked out. On an operations screen designed around binary states, the temptation was obvious: mark the aircraft verified and place it on the map.

There was only one difficulty. No sensor had located an aircraft.

RFC 9886 is valuable because it builds public identity infrastructure for the Drone Remote Identification Protocol while refusing to promise more than that infrastructure can deliver. Its central object, the DET, resembles an IPv6 address. The resemblance is representational, not operational. The RFC describes a DET as intended primarily as an identifier rather than a locator. It can name a registered cryptographic identity without saying where the thing carrying that identity is, whether it is airborne, or whether the transmitter heard nearby controls.

A reverse tree for identity

The document places DETs from 2001:30::/28 under the reverse-DNS tree rooted at 3.0.0.1.0.0.2.ip6.arpa.. That choice reuses DNS delegation, caching and authentication machinery. It does not convert a DET into an ordinary routed IPv6 endpoint, nor does the query request a PTR record that yields a host address. A client asks for purpose-built HHIT or BRID resource records.

The hierarchy has familiar economic and administrative roles. A registrant obtains an entry through a registrar; one registry governs a delegated domain; authoritative servers publish the permitted public material. At higher levels, the design anticipates allocations connected to national authorities or civil aviation authorities, with IANA administering the relevant reverse namespace. RFC 9886 supplies a technical structure, not a constitution for every decision inside it. Administration, management and policy at the hierarchy's levels remain outside scope.

That boundary matters. DNS provides globally interoperable naming because a delegated authority can answer one bounded question. It does not make the authority omniscient. An authoritative answer means that a particular server published particular bytes at a captured time. Whether those bytes correspond to present physical reality requires additional evidence.

What types 67 and 68 say

IANA records type 67 as HHIT and type 68 as BRID. A DET must resolve to an HHIT record. Its canonical registration certificate associates the DET, public key and registration hierarchy, giving a verifier material with which to test the claimed chain. For UAS Remote ID use, a BRID record is also required. It carries static Broadcast Remote ID information and endorsements, while the application-specific fields remain opaque to the DRIP layer.

These records solve real problems. An observer encountering an unfamiliar Host Identity can query for the key and registration material. If connectivity is unavailable, RFC 9575 allows the message to be cached for later verification. A static BRID record can supply information that was not received over the air or cross-check a broadcast. Registration need not be guessed from a locally maintained proprietary table.

The same facts define the limit. Static information is not a live radio observation. A public key is not proof that the current transmitter possesses its private counterpart. A registration certificate is not a flight authorization. A DNS owner name is not a coordinate. A returned BRID payload is not a radar track, GNSS fix, time-bounded sighting or successful command acknowledgement.

RFC 9575 makes the key distinction explicit. Even when an observer has validated every link in the registration trust chain, the result establishes that the DET and public key are properly registered. It does not yet establish that the unmanned aircraft being observed holds the corresponding private key. That requires proof of possession in the live protocol exchange. Replay remains possible before that step.

Authentication narrows one doubt

DNSSEC is essential but must be described precisely. RFC 9886 requires it for self-signed apex arrangements and recommends protection throughout the hierarchy. A validating answer can establish origin and integrity under the configured DNS trust chain. Without that protection, forged or corrupted data can support impersonation, cloned identities, hijacked registrations or false metadata. Where DNSSEC is absent, a client has to walk and validate the registration certificates itself.

Yet DNSSEC does not certify the physical world. It says that the response came through an authenticated naming chain without undetected alteration. It does not say the registry's underlying assertion is current, the aircraft is at a claimed coordinate, a broadcast was received at that coordinate, or the holder is authorized to fly. Strong authentication makes a bounded assertion stronger; it does not widen the assertion.

This is the same discipline required by the registry principle that a record describes reality but does not create it. Thin coordination is useful precisely because it can preserve uniqueness, accurate references, proof material and auditability without pretending to govern every downstream fact. The failure begins when a system converts the convenience of one common lookup into a universal verdict.

Publication itself can become a signal

The RFC also acknowledges that the lookup layer has operational consequences. Public-key material should, where practical, be published just in time. A record could be activated before an operation and removed afterward. That may reduce long-lived exposure, but it creates another inference hazard: observers may treat publication as evidence that a flight is under way.

The protocol does not guarantee that inference. A record may be pre-positioned, cached past its intended window, left behind after cancellation or withheld during a real operation because connectivity failed. TTL, negative caching, resolver path and clock quality all affect what an observer sees. “Record present” and “aircraft present” are separate events even when a deployment intends them to correlate.

Cost and governance also sit behind the technical answer. Registrar credentials, registry contracts and before-flight transactions may add friction. RFC 9886 notes that dynamic registration can fail to scale and identifies alternative allocation models. If access to authoritative identity becomes a prerequisite for participation, the party controlling enrollment can acquire leverage beyond mere uniqueness coordination. That possibility belongs in institutional design; it must not be concealed inside a green DNS status.

Sources