DRIP Entity Tags (DETs) in the Domain Name System
Extracted elements (26)
Each RAA is given four DNS delegations (for HDA values 0, 4096, 8192, 12288) by borrowing the upper two bits of HDA space, enabling a clean nibble boundary in the DNS delegation from 3.0.0.1.0.0.2.ip6.arpa. This nibble-splitting approach accommodates the IPv6 reverse lookup structure while preserving the DET hierarchy.
Public information (cryptographic keys, endorsements, certificates) is stored in authoritative DNS servers rather than a proprietary registry to satisfy REG-1 from RFC 9153. This leverages existing DNS infrastructure for scalable, globally accessible lookup of DET metadata.
The HHIT RRType (67) was defined separately from the existing HIP RRType because the HIP RRType lacks mandatory inclusion of a Canonical Registration Certificate. The certificate provides a registrar-signed confirmation of registration and contains URIs pointing to private information resources.
The HHIT RRType (67) does not replace the existing HIP RRType (RFC 8005). Both may coexist; HHIT provides mandatory certificate inclusion not available in HIP. DNS lookups for DETs query HHIT and/or BRID RRTypes rather than the PTR RRType conventionally used for reverse IP lookups.
BRID RR data MUST be encoded in CBOR bytes. For display purposes, byte strings longer than 20 bytes SHOULD be represented as base64 when possible.
DET IPv6 addresses, when looked up under ip6.arpa. using nibble-reversed notation, MUST resolve to an HHIT RRType. For UAS RID deployments, the BRID RRType MUST also be present to provide Broadcast Endorsements.
DNSSEC MUST be used for apex entities (those using a self-signed Canonical Registration Certificate) and is RECOMMENDED for all other entities. A self-signed entity MUST use DNSSEC.
HHIT RR data MUST be encoded in CBOR (RFC 8949). All fields of the HHIT RRType MUST be included for the record to be properly formed.
The Broadcast Endorsements in the BRID RRType auth field, when present, MUST also be validated according to Section 6.4.2 of RFC 9575 for Broadcast RID Observers.
The Canonical Registration Certificate field in the HHIT RRType MUST be encoded as X.509 DER (RFC 5280). It MAY be self-signed when the entity acts as a root of trust (apex). This certificate forms part of a chain used to validate hierarchy membership.
The HID Abbreviation field in the HHIT RRType MUST, absent local policy, be filled with four-character hexadecimal representations of the RAA and HDA values separated by a delimiter character (e.g., '000A 0014' for RAA=10, HDA=20).
When a DIME decides to use DNSSEC, it SHOULD define a framework for cryptographic algorithms and key management per RFC 6841, taking into account frequency of updates, zone size, and applicable policies.
When DNSSEC is not in use, clients MUST 'walk' the tree of certificates by performing DNS lookups of HHIT RRTypes for each DET in the hierarchy chain, verifying each certificate's inclusion. This certificate chain walk is the only way to prove valid registration without DNSSEC.
AAA mechanisms for Private Information Registries storing Personally Identifiable Information (PII) are explicitly out of scope for this document. Only public information (cryptographic keys, endorsements, certificates) is stored in DNS; private operator data is managed separately by DIMEs.
A DRIP Entity Tag (DET) is a 128-bit IPv6 address (prefix 2001:30::/28) structured as: 28-bit IPv6 prefix, 28-bit Hierarchy ID (split into 14-bit RAA and 14-bit HDA), 8-bit HHIT Suite ID, and 64-bit ORCHID hash. DETs serve primarily as identifiers rather than locators.
The DET hierarchy maps onto DNS using a three-level registrant-registrar-registry model: IANA manages the apex (3.0.0.1.0.0.2.ip6.arpa.), Registered Assigning Authorities (RAAs) act as national registries, and HHIT Domain Authorities (HDAs) serve as local registries. Registrants own individual DET entries.
The HHIT Resource Record (RRType 67) is a CBOR-encoded DNS record containing three fields: hhit-entity-type (uint), hid-abbreviation (15-character string), and canonical-registration-cert (byte string holding an X.509 DER certificate). It provides public key material and a URI pointer to private information resources.
The UAS Broadcast RID Resource Record (BRID, RRType 68) is a CBOR-encoded DNS record holding static Broadcast RID information including UAS type, UAS IDs, optional authentication data (Broadcast Endorsements), self-identification, area, classification, and operator ID fields derived from the ASTM F3411 data dictionary.
IANA has created the DRIP RAA Allocations registry under the 'Drone Remote ID Protocol' registry group. It is a 14-bit value space: 0-3 reserved, 4-3999 for ISO 3166-1 countries (IESG Approval), 4000-8191 reserved, 8192-15359 unassigned (First Come First Served), 15360-16383 private use.
IANA has created the HHIT Entity Types registry under the 'Drone Remote ID Protocol' registry group, using First Come First Served policy. Initial values include: 0 (Not Defined), 1 (DIME), 5 (Apex), 9 (RAA), 13 (HDA), 16 (UA), 17 (GCS), 18 (UAS), 19 (RID Module), 20-27 covering Pilot, Operator, DSS, USS, SP, DP, SDSP, and Crowd Sourced RID Finder.
The reverse domain for the DET prefix (3.0.0.1.0.0.2.ip6.arpa.) is managed by IANA, which liaises with ICAO to verify authenticity of delegations to Civil Aviation Authorities (CAAs). ISO 3166-1 country RAA assignments grant each nation 4 RAAs and optionally a /40 prefix covering all four.
DETs are built on asymmetric keys, requiring public key exposure in DNS for signature verification. It is RECOMMENDED to delay publishing HHIT RRTypes until required ('just-in-time' publishing) to minimize the window during which the public key is exposed, reducing the risk from potential private key forgery.
Registry-registrar interactions SHOULD follow best common practices for security including DNSSEC operation per BCP 237. A DNSSEC Practice Statement SHOULD be developed and published. Registry SHOULD provide RDAP or equivalent lookup service for public information about registered DETs.
Without DNSSEC, DRIP entities are vulnerable to DNS spoofing attacks including denial-of-service, replay attacks, impersonation or cloning of UAVs, hijacking of DET registrations, injection of corrupt metadata, and compromise of the established trust hierarchy. DNSSEC validation is essential to authenticate DNS responses.
BRID RR RDATA is CBOR-encoded as a map with required keys uas_type (0) and uas_ids (array of [id_type, 20-byte bstr] groups) and optional keys auth (array of [a_type, 1..362-byte bstr] groups), self_id, area, classification, and operator_id. Text representation is base64.
HHIT RR RDATA is CBOR-encoded as a three-element array: [hhit-entity-type: uint, hid-abbreviation: tstr .size(15), canonical-registration-cert: bstr]. All fields are mandatory. Text representation uses base64 (RFC 4648).