Summary

  • RFC 9886 maps a 128-bit IPv6-form DET—not a locator—into reverse DNS below the 2001:30::/28 prefix.
  • The hierarchy separates the Registered Assigning Authority (RAA) from the HHIT Domain Authority (HDA), with delegation beneath 3.0.0.1.0.0.2.ip6.arpa.
  • A DET name must resolve to an HHIT record; for the UAS Remote ID use case, a BRID record must also be present.
  • DNSSEC is mandatory for apex entities and recommended for other entities. If DNSSEC is unavailable, validation falls back to a certificate walk through successive HHIT lookups.

The operational fixture is a DNS investigation, not a byte-string reconstruction. Start with the reverse-tree anchor 3.0.0.1.0.0.2.ip6.arpa, locate the RAA and HDA delegations derived from the DET, and query the authoritative servers. At the DET name, verify HHIT RRType 67 and its canonical registration certificate. For a UAS, verify BRID RRType 68 as well, including the static Broadcast RID information and any endorsements represented by that record. Follow the certificate chain to the relevant registry authority; do not treat a syntactically present label as proof of inclusion.

The public/private boundary matters. RFC 9886 puts public DRIP information and pointers in authoritative DNS, while private registries remain separate. It does not specify the AAA mechanisms used to protect personally identifiable information. A public lookup can therefore establish particular DNS and certificate evidence without proving that a private registry’s identity controls, eligibility rules, pricing, or jurisdictional policy are sound.

DNSSEC changes the evidence path. Validate the signed delegation and records when required by the entity’s position in the hierarchy. Without DNSSEC, the client must walk the certificate hierarchy through successive HHIT lookups. A successful lookup alone is insufficient in either path: the relying party needs an unbroken, appropriate chain and the required record set.

The DET also exposes a public key for signature verification. RFC 9886 recommends, when practical, delaying publication of record types under a DET until they are needed. The just-in-time mechanism is out of scope. This is exposure guidance, not a promise of anonymity or a measured privacy result.

Operator decision path: (1) parse the DET as an IPv6-form identifier, not a locator; (2) derive and inspect its 2001:30::/28 reverse-DNS position; (3) confirm authoritative RAA/HDA delegation; (4) require HHIT; (5) require BRID for UAS Remote ID; (6) validate DNSSEC, or perform the certificate walk when DNSSEC is absent; (7) record certificate freshness and delegation state as operational evidence; and (8) publish additional DET records only when their verification and exposure purpose is justified.

Those last lifecycle checks are Theo March analysis, not RFC requirements. Delegation control is a governance control surface: whoever can change a delegation, registry record, or certificate path can affect what a relying party accepts. Operators should monitor stale records, withdrawn credentials, broken parent-child evidence, and disclosure timing. RFC 9886 does not establish production deployment, adoption, DIME or registry availability or latency, implementation coverage, incident history, abuse, privacy, traceability outcomes, or any jurisdiction-specific policy or price.

Sources

The verified errata records 8822 and 8823 correct appendix example encodings. This briefing deliberately does not reproduce those example byte strings and does not treat them as operational measurements.