RFC 9886

DRIP Entity Tags (DETs) in the Domain Name System

📅 published December 2025, from ietf

DRIP Entity Tags (DETs) in the Domain Name System 💖

Okay bestie, this one is RFC 9886 🎀 It's a Standards Track document from the IETF, dated December 2025. It's published under ISSN 2070-1721. The main author is A. Wiethuechter, Ed. from AX Enterprize, LLC, and J. Reid from RTFM llp co-wrote it. The title block doesn't list anything it obsoletes or updates, so there's no older RFC it replaces or patches 🧚

Abstract ✨

Okay so this doc defines the DNS side of a DIME (DRIP Identity Management Entity) 🛰️ The whole thing is built around DRIP Entity Tags (DETs), and it's giving organized. It standardizes a hierarchical registry structure plus the processes for registering and looking stuff up in a way that's trustable and scalable 🔥 The registry handles issuing, discovering, and verifying DETs so UAS (drones!) and their operators can be securely identified and linked together 🦋

It also lays out how the different registry classes work together: root, organizational, and individual. Each has its own role in keeping the registration data intact 💅 The vibe is decentralized and federated, with privacy, traceability, and regulatory compliance all in the mix for UAS Remote Identification and other services 🌈 Main character architecture, honestly.

Status of This Memo 🌸

This is an Internet Standards Track document, so it's an actual standard, not just a suggestion 👑

It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the IESG (Internet Engineering Steering Group) 🫶 For more on Internet Standards, check out Section 2 of RFC 7841 💜

If you want the current status, errata, or a way to send feedback, go to https://www.rfc-editor.org/info/rfc9886 🍓

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this document 🙈 Also, any Code Components pulled out of this document must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, per the Revised BSD License ⚠️

Table of Contents 📖

1.  Introduction
  1.1.  General Concept
  1.2.  Scope
2.  Terminology
  2.1.  Required Terminology
  2.2.  Additional Definitions
3.  DET Hierarchy in DNS
  3.1.  Use of Existing DNS Models
    3.1.1.  DNS Model Considerations for DIMEs
4.  Public Information Registry
5.  Resource Records
  5.1.  HHIT Resource Record
    5.1.1.  Text Representation
    5.1.2.  Field Descriptions
  5.2.  UAS Broadcast RID Resource Record
    5.2.1.  Text Representation
    5.2.2.  Field Descriptions
6.  IANA Considerations
  6.1.  DET Prefix Delegation
  6.2.  IANA DRIP Registry
    6.2.1.  DRIP RAA Allocations
    6.2.2.  HHIT Entity Types
7.  Security Considerations
  7.1.  DNS Operational and Registration Considerations
  7.2.  DET and Public Key Exposure
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  Example Zone Files and RRType Contents
  A.1.  Example RAA
    A.1.1.  Authentication HHIT
    A.1.2.  Delegation of HDA
  A.2.  Example HDA
    A.2.1.  Authentication and Issue HHITs
    A.2.2.  Registrant HHIT and BRID
Acknowledgements
Authors' Addresses

1. Introduction 🚁

Registries are the backbone of Unmanned Aircraft System (UAS) Remote Identification (RID) 🗂️ Broadcast RID can only carry a tiny amount of operational info, but sometimes you need the extended stuff too. The most essential piece is the UAS ID, which is the unique key you use to look up that extended info in the relevant registries 🔑 Figure 1 shows the whole picture (it's the same as Figure 4 of [RFC9434]) 👀

 ***************                                        ***************
 *    UAS1     *                                        *     UAS2    *
 *             *                                        *             *
 * +--------+  *                 DAA/V2V                *  +--------+ *
 * |   UA   o--*----------------------------------------*--o   UA   | *
 * +--o--o--+  *                                        *  +--o--o--+ *
 *    |  |     *   +------+      Lookups     +------+   *     |  |    *
 *    |  |     *   | GPOD o------.    .------o PSOD |   *     |  |    *
 *    |  |     *   +------+      |    |      +------+   *     |  |    *
 *    |  |     *                 |    |                 *     |  |    *
 * C2 |  |     *     V2I      ************     V2I      *     |  | C2 *
 *    |  '-----*--------------*          *--------------*-----'  |    *
 *    |        *              *          *              *        |    *
 *    |        o====Net-RID===*          *====Net-RID===o        |    *
 * +--o--+     *              * Internet *              *     +--o--+ *
 * | GCS o-----*--------------*          *--------------*-----o GCS | *
 * +-----+     * Registration *          * Registration *     +-----+ *
 *             * (and UTM)    *          * (and UTM)    *             *
 ***************              ************              ***************
                                |  |  |
                 +----------+   |  |  |   +----------+
                 | Public   o---'  |  '---o Private  |
                 | Registry |      |      | Registry |
                 +----------+      |      +----------+
                                |  |  |
                                +--o--+
                                | DNS |
                                +-----+

 DAA:  Detect And Avoid
 GPOD: General Public Observer Device
 PSOD: Public Safety Observer Device
 V2I:  Vehicle-to-Infrastructure
 V2V:  Vehicle-to-Vehicle

Figure 1: Global UAS RID Usage Scenario (Figure 4 of RFC 9434)

So when a DRIP Entity Tag (DET) [RFC9374] is used as the UAS ID in RID, you can grab extended info from a DIME, which manages registration and lookups for DETs 🧚 In this doc, the DIME is assumed to be a function of UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]), but a DIME can also be independent or run by some other entity 💜

1.1. General Concept 🌈

DETs embed a hierarchy scheme that gets mapped onto the Domain Name System (DNS) [STD13] 🌐 DIMEs enforce registration and information access for the data tied to a DET, and they also provide the trust you inherit from being part of the hierarchy 🫶 Other identifiers and their methods are out of scope here, so don't go looking for them in this doc 🙅‍♀️

Authoritative name servers in the DNS serve the public info: cryptographic keys, endorsements, certificates for DETs, plus pointers to private info resources 📇 The cryptographic (public) keys are used to authenticate anything a DET signs, like the Authentication Messages defined in [RFC9575] for Broadcast RID 🔐 Endorsements and certificates are used to back up the claim that you belong to the hierarchy 🏅

This doc doesn't specify the AAA mechanisms that Private Information Registries use to store and protect Personally Identifiable Information (PII) 🙈

1.2. Scope 🎯

The scope here is the DNS registration of DETs, along with the DNS delegation of the reverse domain for the IPv6 prefix (2001:30::/28 for DETs), and the RRsets used to handle DETs 💖

2. Terminology 📝

2.1. Required Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔥 Translation: those words only carry their special BCP 14 meaning when they're in ALL CAPS, so lowercase ones are just regular English 🙌

2.2. Additional Definitions 🦋

This doc uses terms and abbreviations from earlier DRIP documents. The lists below are grouped by the original document they came from, so you can go check those docs for more context, definitions, and any further referenced material 📚

From Section 2.2 of [RFC9153], this document uses: AAA, CAA, GCS, ICAO, PII, Observer, Operator, UA, UAS, USS, and UTM 🛸

From Section 2 of [RFC9434], this document uses: Certificate, DIME, and Endorsement 🎀

From Section 2 of [RFC9374], this document uses: HDA, HID, and RAA 🌸

3. DET Hierarchy in DNS 🌳

[RFC9374] defines the Hierarchical Host Identity Tags (HHIT) and then specifies a particular instance of them for UAS RID, called the DET 🧚 A DET is a 128-bit value that is an IPv6 address, and it's meant mainly as an identifier rather than a locator 📍 The format is in Figure 2, and [RFC9374] has the deeper details 👀

  +-------------+--------------+---------------+-------------+
  | IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
  | (28 bits)   | (28 bits)    | (8 bits)      | (64 bits)   |
  +-------------+--------------+---------------+-------------+
               /                \
              /                  \
             /                    \-----------------------------\
            /                                                    \
           /                                                      \
          +--------------------------------+-----------------------+
          | Registered Assigning Authority | HHIT Domain Authority |
          | (14 bits)                      | (14 bits)             |
          +--------------------------------+-----------------------+

Figure 2: DRIP Entity Tag Breakdown

[RFC9374] assigns the IPv6 prefix 2001:30::/28 to DETs 🌟 The matching domain name for reverse lookups is 3.0.0.1.0.0.2.ip6.arpa.. The IAB has administrative control over that domain name 🏛️

Now here's where it gets spicy 🌶️ Because of how the hierarchy is split, and how it lines up with nibble reversing of the IPv6 address (Section 2.5 of RFC 3596 [STD88]), the upper level (the Registered Assigning Authority, or RAA) "borrows" the top two bits of its HHIT Domain Authority (HDA) space for DNS delegation 🪄 That means RAA prefixes look like 2001:3x:xxx0::/44 and HDA prefixes look like 2001:3x:xxxy:yy00::/56, with nibble reverse domains of x.x.x.x.3.0.0.1.0.0.2.ip6.arpa. and y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa. respectively 🧩

This doc preallocates a subset of RAAs based on the ISO 3166-1 Numeric Nation Code [ISO3166-1] 🌍 The point is to support the first use case for DETs in UAS RID at an international level. The RAA allocations are in Section 6.2.1 💖

The HDA values 0, 4096, 8192, and 12288 are reserved for operational use of an RAA (kind of a side effect of that bit borrowing), specifically for when an RAA needs to register with the apex and endorse HDA delegations in its namespace 🎀

Last but definitely not least: the administration, management, and policy for running a DIME at any level of the hierarchy (Apex, RAA, or HDA) is out of scope for this doc 🙅‍♀️ For RAAs or DETs allocated on a per-country basis, those decisions should be made by the appropriate national authorities, presumably the Civil Aviation Authority (CAA) ✈️ Iconic energy from the standards body, honestly 💀

3.1. Use of Existing DNS Models 💅

okay so DRIP borrows the DNS and roughly follows the registrant-registrar-registry model 🫶. In the UAS ecosystem, the registrant is the end user who owns or controls the Unmanned Aircraft. They're ultimately responsible for the DET and anything else published in the DNS 💀. Registrants use agents called registrars to manage their interactions with the registry. Registrars typically offer optional extras like DNS hosting ✨.

The registry keeps a database of registered domain names and their related metadata, like contact details for the domain name holder and the relevant registrar 📋. It provides DNS service for the zone apex, which holds the delegation info for domain names. Registries generally offer services like the Registration Data Access Protocol (RDAP) [STD95] or equivalent, which publish metadata about registered domain names and their registrants and registrars 🦋.

Registrants have contracts with registrars, who in turn have contracts with registries. Payments follow the same chain: the registrant buys services from a registrar, who pays for services provided by the registry 💸.

By definition, there can only be one registry for a domain name 👑. A registry can have an arbitrary number of registrars who compete on price, service, and customer support 🔥.

3.1.1. DNS Model Considerations for DIMEs 🌸

     Apex
     Registry/Registrar
     (IANA)
                              +=========================+
                              | 3.0.0.1.0.0.2.ip6.arpa. |
                              +============o============+
                                           |
     --------------------------------------|-------------------------
     National                              |
     Registries/Registrars                 |
     (RAA)                                 |
                                           |
             +--------------+--------------o-+---------------+
             |              |                |               |
       +=====o====+    +====o=====+    +=====o====+    +=====o====+
       | 0.0.0.0. |    | 1.0.0.0. |    | 2.0.0.0. |    | 3.0.0.0. |
       +====o=====+    +====o=====+    +====o=====+    +====o=====+
                                            |
     ---------------------------------------|------------------------
     Local                                  |
     Registries/Registrars                  |
     (HDA)                                  |
                                            |
             +--------------+---------------o--------...-----+
             |              |               |                |
       +=====o====+    +====o=====+    +====o=====+    +=====o====+
       |  1.0.0.  |    |  2.0.0.  |    |  3.0.0.  |    |  f.f.f.  |
       +====o=====+    +=====o====+    +====o=====+    +====o=====+
                                            |
     ---------------------------------------|------------------------
     Local                                  |
     Registrants                            |
                      +=====================o================+
                      | x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.5.0. |
                      +======================================+

                      Figure 3: Example DRIP DNS Model

While the registrant-registrar-registry model is mature and well understood, it may not be appropriate for DRIP registrations in some circumstances. It could add costs and complexity to develop policies and contracts as outlined above. On the other hand, registries and registrars offer customer service and support, and they can provide the supporting infrastructure for reliable DNS and RDAP service 🤝.

Another approach could be to handle DRIP registrations in a comparable way to how IP address space gets provisioned. Here, blocks of addresses get delegated to a "trusted" third party, typically an ISP, who then issues IP addresses to its customers. For DRIP, blocks of IP addresses could be delegated from the 3.0.0.1.0.0.2.ip6.arpa. domain (reverse domain of prefix allocated by [RFC9374]) to an entity chosen by the appropriate Civil Aviation Authority (CAA). This third party would be responsible for the corresponding DNS and RDAP infrastructure for these IP address blocks. They would also provision the HHIT records [RFC9374] for these IP addresses. In principle, a manufacturer or vendor of UAS devices could provide that role. This is shown as an example in Figure 3 🛫.

Dynamic DRIP registration is another possible solution, for example when the operator of a UAS device registers its corresponding HHIT record and other resources before a flight and deletes them afterwards. This may be feasible in controlled environments with well-behaved actors. However, this approach may not scale, since each device is likely to need credentials for updating the IT infrastructure that provisions the DNS 🙈.

Registration policies (pricing, renewals, registrar and registrant agreements, etc.) will need to be developed. These considerations should be determined by the CAA, perhaps in consultation with local stakeholders to assess the cost-benefits of these approaches (and others). All of these are out of scope for this document. The specifics for the UAS RID use case are detailed in the rest of document 🧾.

4. Public Information Registry 🗂️

Per [RFC9434], all information classified as public is stored in the DNS, specifically authoritative name servers, to satisfy REG-1 from [RFC9153] ✅.

Authoritative name servers use domain names as identifiers, and data is stored in Resource Records (RRs) with associated RRTypes. This document defines two new RRTypes: one for HHIT metadata (HHIT, Section 5.1) and another for UAS Broadcast RID information (BRID, Section 5.2). The former RRType is particularly important, as it contains a URI (as part of the certificate) that points to Private Information resources 🔐.

DETs, being IPv6 addresses, are to be under ip6.arpa. (nibble reversed per Section 2.5 of RFC 3596 [STD88]) and MUST resolve to an HHIT RRType. Depending on local circumstances or additional use cases, other RRTypes MAY be present (for example, the inclusion of the DS RRTypes or equivalent when using DNSSEC). For UAS RID, the BRID RRType MUST be present to provide the Broadcast Endorsements (BEs) defined in Section 3.1.2.1 of [RFC9575] 🧩.

DNSSEC MUST be used for apex entities (those which use a self-signed Canonical Registration Certificate) and is RECOMMENDED for other entities. When a DIME decides to use DNSSEC, they SHOULD define a framework for cryptographic algorithms and key management [RFC6841]. This may be influenced by the frequency of updates, size of the zone, and policies 🔑.

UAS-specific information, such as physical characteristics, may also be stored in DNS, but it is out of scope for this document 🚁.

A DET IPv6 address gets mapped into domain names using the scheme defined in Section 2.5 of RFC 3596 [STD88]. However, DNS lookups of these names query for HHIT and/or BRID resource records, rather than the PTR resource records conventionally used in reverse lookups of IP addresses. For example, the HHIT resource record for the DET 2001:30::1 would be returned from a DNS lookup for the HHIT QTYPE for 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.1.0.0.2.ip6.arpa.. Main character lookup energy 🦋✨.

The HHIT RRType provides the public key for signature verification and URIs via the certificate. The BRID RRType provides static Broadcast RID information, such as the Broadcast Endorsements sent as described in [RFC9575] 📡.

5. Resource Records 📇

5.1. HHIT Resource Record 🔑

The HHIT Resource Record (HHIT, RRType 67) is a metadata record for various bits of HHIT-specific information that isn't available in the pre-existing HIP RRType. The HHIT RRType does not replace the HIP RRType [RFC8005]. The primary advantage of the HHIT RRType over the existing RRType is the mandatory inclusion of the Canonical Registration Certificate, containing an entity's public key signed by the registrar (or other trust anchor), to confirm registration 💖.

The data MUST be encoded in the Concise Binary Object Representation (CBOR) [RFC8949] bytes. The Concise Data Definition Language (CDDL) [RFC8610] of the data is provided in Figure 4 🧠.

5.1.1. Text Representation

The data are represented in base64 [RFC4648] and may be divided into any number of white-space-separated substrings, down to single base64 digits, which are concatenated to obtain the full object. These substrings can span lines using the standard parenthesis. Note that the data has internal subfields, but these do not appear in the zone file representation; only a single logical base64 string will appear 🧵.

5.1.1.1. Presentation Representation

The data MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of [RFC8610] 👀.

5.1.2. Field Descriptions

   hhit-rr = [
       hhit-entity-type: uint,
       hid-abbreviation: tstr .size(15),
       canonical-registration-cert: bstr
   ]

                      Figure 4: HHIT Wire Format CDDL

All fields of the HHIT RRType MUST be included to be properly formed 🎀.

HHIT Entity Type: The HHIT Entity Type field is a number with values defined in Section 6.2.2. It is envisioned that there may be many types of HHITs in use. In some cases, it may be helpful to understand the role of the HHITs in the ecosystem, like that described in [drip-dki]. This field provides such context. This field MAY provide a signal of additional information and/or different handling of the data beyond what is defined in this document 🏷️.

HID Abbreviation: The HID Abbreviation field is a string that provides an abbreviation to the HID (Hierarchy ID) structure of a DET for display devices. The convention for such abbreviations is a matter of local policy. Absent of such a policy, this field MUST be filled with the four character hexadecimal representations of the RAA and HDA (in that order), with a separator character, such as a space, in between. For example, a DET with an RAA value of 10 and HDA value of 20 would be abbreviated as: 000A 0014 🌈.

Canonical Registration Certificate: The Canonical Registration Certificate field is for a certificate-endorsing registration of the DET. It MUST be encoded as X.509 DER [RFC5280]. This certificate MAY be self-signed when the entity is acting as a root of trust (i.e., an apex). Such self-signed behavior is defined by policy, such as in [drip-dki], and is out of scope for this document. This certificate is part of a chain of certificates that can be used to validate inclusion in the hierarchy 📜.

5.2. UAS Broadcast RID Resource Record 📡

The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format to hold information typically sent over UAS Broadcast RID that is static. It can act as a data source if information is not received over Broadcast RID, or for cross validation. The primary function for DRIP is to include one or more Broadcast Endorsements, as defined in [RFC9575], in the auth field. These Endorsements are generated by the registrar upon successful registration and broadcast by the entity 🥹.

The data MUST be encoded in CBOR [RFC8949] bytes. The CDDL [RFC8610] of the data is provided in Figure 5 🫶.

5.2.1. Text Representation 🌸

Okay so the data is written in base64 [RFC4648]. It can be chopped into any number of chunks separated by whitespace, all the way down to single base64 digits 🤯, and then glued back together to make the full object. The chunks can wrap across lines using the standard parentheses. Lowkey the most important bit: the data has internal subfields, but those don't show up in the zone file representation. You only ever see one long base64 string 💅

5.2.1.1. Presentation Representation 🦋

For display purposes only, the data MAY be shown using the Extended Diagnostic Notation from Appendix G of [RFC8610] 👀 All byte strings longer than a length of 20 SHOULD be displayed as base64 whenever that's possible 💖

5.2.2. Field Descriptions 🎀

Here's the wire format in CDDL, the vibe check for the whole broadcast structure 🧚

bcast-rr = {
    uas_type => nibble-field,
    uas_ids => [+ uas-id-grp],
    ? auth => [+ auth-grp],
    ? self_id => self-grp,
    ? area => area-grp,
    ? classification => classification-grp,
    ? operator_id => operator-grp
}
uas-id-grp = [
    id_type: &uas-id-types,
    uas_id: bstr .size(20)
]
auth-grp = [
    a_type: &auth-types,
    a_data: bstr .size(1..362)
]
area-grp = [
    area_count: 1..255,
    area_radius: float,  # in decameters
    area_floor: float,   # wgs84-hae in meters
    area_ceiling: float  # wgs84-hae in meters
]
classification-grp = [
    class_type: 0..8,
    class: nibble-field,
    category: nibble-field
]
self-grp = [
    desc_type: 0..255,
    description: tstr .size(23)
]
operator-grp = [
    operator_id_type: 0..255,
    operator_id: bstr .size(20)
]
uas-id-types = (none: 0, serial: 1, session_id: 4)
auth-types = (none: 0, specific_method: 5)
nibble-field = 0..15
uas_type = 0
uas_ids = 1
auth = 2
self_id = 3
area = 4
classification = 5
operator_id = 6

Figure 5: BRID Wire Format CDDL

The field names and their general typing come from the ASTM data dictionary (Tables 1 and 2) [F3411] ✨ That doc has the extra context and background on how aviation apps read these fields. The explicitly listed values in the CDDL above are the ones that matter for DRIP's operation. Other values might be valid, but they're outside DRIP's scope 🌈 Application-specific fields, like UAS Type, get transported and authenticated by DRIP, but to DRIP they're just opaque user data 🫶

6. IANA Considerations 👑

6.1. DET Prefix Delegation 🌍

The reverse domain for the DET Prefix, which is 3.0.0.1.0.0.2.ip6.arpa., is managed by IANA. IANA will liaise with the International Civil Aviation Organization (ICAO), as needed, to verify the authenticity of delegations to CAAs (see Section 6.2.1.4) 🛡️

6.2. IANA DRIP Registry 🗂️

6.2.1. DRIP RAA Allocations 🍓

IANA has created the registry for RAA Allocations under the "Drone Remote ID Protocol" registry group at <https://www.iana.org/assignments/drip> 🎉

RAA Allocations is a 14-bit value used to represent RAAs. Future additions to this registry are made based on the following range and policy table 💜

+===========+======================+================================+
| RAA Range | Allocation           | Policy                         |
+===========+======================+================================+
| 0 - 3     | Reserved             |                                |
+-----------+----------------------+--------------------------------+
| 4 - 3999  | ISO 3166-1           | IESG Approval (Section 4.10 of |
|           | Countries            | [RFC8126]), Section 6.2.1.4    |
+-----------+----------------------+--------------------------------+
| 4000 -    | Reserved             |                                |
| 8191      |                      |                                |
+-----------+----------------------+--------------------------------+
| 8192 -    | Unassigned           | First Come First Served        |
| 15359     |                      | (Section 4.4 of [RFC8126])     |
+-----------+----------------------+--------------------------------+
| 15360 -   | Private              | Private Use (Section 4.1 of    |
| 16383     | Use                  | [RFC8126]), Section 6.2.1.5    |
+-----------+----------------------+--------------------------------+

Table 1: RAA Ranges

6.2.1.1. RAA Allocation Fields 💅

  • Value: The RAA value delegated for this entry.
  • Name: Name of the delegated RAA. For the ISO 3166-1 Countries (Section 6.2.1.4), this should be the name of the country.
  • Reference: A publicly accessible link to the policy requirements for prospective HDA operators to register under this RAA. This field is OPTIONAL.
  • Contact: Contact details of the administrator of this RAA that prospective HDA operators can make informational queries to.

6.2.1.2. RAA Registration Form 📝

Value:
Name:
Reference:
Contact:
NS RRType Content (HDA=0):
NS RRType Content (HDA=4096):
NS RRType Content (HDA=8192):
NS RRType Content (HDA=12288):

Figure 6: RAA Delegation Request Form

IANA uses the NS RRType Content (HDA=X) fields to do the DNS delegations under 3.0.0.1.0.0.2.ip6.arpa.. See Section 6.2.1.3 for the technical details 🤓

6.2.1.3. Handling Nibble Split 🍰

To support DNS delegation in 3.0.0.1.0.0.2.ip6.arpa., a single RAA gets 4 delegations by borrowing the upper two bits of HDA space (see Figure 7 for an example). This gives a clean nibble boundary in the DNS to delegate from, which is the prefix 2001:3x:xxx0::/44. These HDAs (0, 4096, 8192 and 12288) are reserved for the RAA 🧠✨

 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0
 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           0           | x |         RAA=16376         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    0   |   0   |   0   |   0   |   E   |   F   |   F     HDA=0,x=00
    0   |   0   |   0   |   1   |   E   |   F   |   F     HDA=4096,x=01
    0   |   0   |   0   |   2   |   E   |   F   |   F     HDA=8192,x=10
    0   |   0   |   0   |   3   |   E   |   F   |   F     HDA=12288,x=11

Figure 7: Example Bit Borrowing of RAA=16376

6.2.1.4. ISO 3166-1 Countries Range 🌏

The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is specified and documented by IANA. Each Nation gets 4 RAAs, which are left to the national authority to use for their own purposes. For RAAs in this range, a shorter prefix of 2001:3x:xx00::/40 MAY be delegated to each CAA, and it covers all 4 RAAs (and reserved HDAs) assigned to them 💖

The registration policy for this range is set to IESG Approval (Section 4.10 of [RFC8126]). IANA will liaise with the ICAO to verify the authenticity of delegation requests (using Figure 6) from CAAs 🔐

6.2.1.5. Private Range 🕵️

If nibble-reversed lookup in DNS is wanted, it can only be provided by private DNS servers, because zone delegations from the global root won't be performed for this address range. So the RAAs (with their subordinate HDAs) in this range can be used in the same way, and IANA won't delegate any value in this range to any party (as per Private Use, Section 4.1 of [RFC8126]) 🙈

One anticipated acceptable use of the private range is experimentation and testing before requesting an allocation or assignment from IANA 🧪

6.2.2. HHIT Entity Types 🦋

This document requests a new registry for HHIT Entity Types under the "Drone Remote ID Protocol" registry group at <https://www.iana.org/assignments/drip> 🌸

HHIT Entity Type is a numeric field of the HHIT RRType that encodes the HHIT Entity Type. All entries in this registry are under the First Come First Served policy (Section 4.4 of [RFC8126]) ✨

6.2.2.1. HHIT Type Registry Fields 📋

  • Value: HHIT Type value of the entry.
  • HHIT Type: Name of the entry and an optional abbreviation.
  • Reference: Public document allocating the value and any additional information such as semantics. This can be a URL pointing to an Internet-Draft, IETF RFC, or web page among others.

6.2.2.2. HHIT Type Registration Form 🧾

Value:
HHIT Type:
Reference:

Figure 8: HHIT Type Registration Form

6.2.2.3. Initial Values 👑

The following values are defined by this document 🌈

+=======+===========================================+===========+
| Value | HHIT Type                                 | Reference |
+=======+===========================================+===========+
| 0     | Not Defined                               | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 1     | DRIP Identity Management Entity (DIME)    | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 5     | Apex                                      | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 9     | Registered Assigning Authority (RAA)      | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 13    | HHIT Domain Authority (HDA)               | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 16    | Unmanned Aircraft (UA)                    | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 17    | Ground Control Station (GCS)              | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 18    | Unmanned Aircraft System (UAS)            | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 19    | Remote Identification (RID) Module        | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 20    | Pilot                                     | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 21    | Operator                                  | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 22    | Discovery & Synchronization Service (DSS) | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 23    | UAS Service Supplier (USS)                | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 24    | Network RID Service Provider (SP)         | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 25    | Network RID Display Provider (DP)         | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 26    | Supplemental Data Service Provider (SDSP) | RFC 9886  |
+-------+-------------------------------------------+-----------+
| 27    | Crowd Sourced RID Finder                  | RFC 9886  |
+-------+-------------------------------------------+-----------+

Table 2: HHIT Entity Type Initial Values

7. Security Considerations 🔐

Things are about to get serious, bestie, so pay attention 👀

7.1. DNS Operational and Registration Considerations ✨

Okay bestie, the Registrar and Registry are super common DNS concepts 💅 They're the bits that plug DIME into the DNS hierarchy, so operation SHOULD follow best common practices, especially for security stuff like running DNSSEC as appropriate, unless national regulations prevent it 🔐. [BCP237] has suitable guidance, so go read that one 🤓

If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed and published 📜 It SHOULD explain how DNSSEC has been deployed and what security measures are in place 🛡️ [RFC6841] documents a framework for DNSSEC policies and DNSSEC Practice Statements. A self-signed entity (i.e., an entity that self-signed its certificate as part of the HHIT RRType) MUST use DNSSEC 🔒

The interfaces and protocol specs for registry-registrar interactions are intentionally NOT specified in this doc 🙅‍♀️ That's because they depend on nationally defined policy and local circumstances 🌍 Registry-registrar activity is expected to use the Extensible Provisioning Protocol (EPP) [STD69] or something equivalent. The registry SHOULD provide a lookup service such as RDAP [STD95] or an equivalent, so it can publish public info about registered domain names 📖

Decisions about DNS or registry best practices, and other operational stuff that affects security, SHOULD be made by the CAA 🏛️ ideally in consultation with local stakeholders. Main character energy for real 💜

The guidance above is meant to reduce the chance of interoperability problems and keep security and stability concerns to a minimum 🧚 For instance, validation and authentication of DNS responses depends on DNSSEC. Without it, entities using DRIP are vulnerable to DNS spoofing attacks and could be exposed to bogus data 😭 DRIP DNS responses that haven't been validated by DNSSEC could contain bogus data that can cause serious security problems and operational concerns for DRIP entities 💀 Those threats include denial-of-service attacks, replay attacks, impersonation or cloning of UAVs, hijacking of DET registrations, injection of corrupt metadata, and compromising established trust architecture and relationships. Some regulatory and legal stuff is expected to get simpler by offering a lookup service for public info about registered domain names for DETs 🌸

When DNSSEC is NOT in use, the ORCHID hash length chosen for DETs (Section 3.5 of [RFC9374]) means clients MUST "walk" the tree of certificates 🌳 They do this by doing DNS lookups of HHIT RRTypes for each DET and checking that each one is included in the hierarchy. Those certificates give signature protection from the parent entity AND the entity's public key, and without DNSSEC they're the only way to prove a valid registration 🎀

The contents of the BRID RRType auth key, which contain Endorsements as described in Section 4.2 of [RFC9575], are basically a shadow of the X.509 certificate found in the HHIT RRType 🦋 The validation of these Endorsements follows the guidelines in Section 6.4.2 of [RFC9575] for Broadcast RID Observers, and when they're present they MUST also be validated ✅

7.2. DET and Public Key Exposure

Let's talk about keys, because DETs are built on asymmetric keys 🔑 So the public key has to be revealed so clients can do signature verifications. [RFC9374] security considerations cover various attacks on these keys. It's unlikely, but forging a matching private key is possible if someone has enough time and computing power 🥶

When practical, it is RECOMMENDED that no RRTypes under a DET's specific domain name get published unless and until another party actually needs them 🙈 That way at least the HHIT RRType isn't in the DNS, so the public key in the certificate doesn't get exposed before it's needed. Not oversharing, iconic 💅 The combo of this "just in time" publishing mechanism and DNSSEC is out of scope for this document.

Optimally, the UAS would somehow signal to the DIME that a flight using a Specific Session ID is about to be underway or is complete 🚁 It may also be facilitated under UTM if the USS (which may or may not be a DIME) signals when a given operation using a Session ID goes active 🌈

8. References 📚

8.1. Normative References

[F3411] ASTM International, "Standard Specification for Remote ID and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July 2022, https://www.astm.org/f3411-22a.html.

[ISO3166-1] ISO, "Codes for the representation of names of countries and their subdivisions - Part 1: Country code", ISO 3166-1:2020, August 2020, https://www.iso.org/standard/72482.html.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, https://www.rfc-editor.org/info/rfc4648.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, https://www.rfc-editor.org/info/rfc8949.

[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, https://www.rfc-editor.org/info/rfc9374.

8.2. Informative References ✨

Okay, these are the informative refs, so they're the good-to-know reading rather than the must-read stuff 📚 Same deal as before: every citation, DOI, and URL is here exactly as the RFC has it 🫶

Appendix A. Example Zone Files and RRType Contents 🧚

Okay, so this appendix is the show-and-tell part 🎀 There's an example zone file for ip6.arpa., run by IANA, but it's not shown here 💀 It would contain NS RRTypes to delegate to a respective RAA. To avoid any future collisions with production deployments, an apex of ip6.example.com. is used instead of ip6.arpa.. And all the hexadecimal strings in the examples are broken into word-length chunks, purely for document formatting 💅

The examples use an RAA with a HID of RAA=16376, HDA=0 and an HDA with a the HID RAA=16376, HDA=10 🌸

A.1. Example RAA

A.1.1. Authentication HHIT

Here's the zone file entry for the RAA Auth HHIT 🦋

$ORIGIN 5.0.0.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com.
7.b.0.a.1.9.e.1.7.5.1.a.0.6.e.5. IN HHIT (
    gwppM2ZmOCAwMDAwWQFGMIIBQjCB9aAD
    AgECAgE1MAUGAytlcDArMSkwJwYDVQQD
    DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx
    NTcxZTkxYTBiNzAeFw0yNTA0MDkyMDU2
    MjZaFw0yNTA0MDkyMTU2MjZaMB0xGzAZ
    BgNVBAMMEkRSSVAtUkFBLUEtMTYzNzYt
    MDAqMAUGAytlcAMhAJmQ1bBLcqGAZtQJ
    K1LH1JlPt8Fr1+jB9ED/qNBP8eE/o0ww
    SjAPBgNVHRMBAf8EBTADAQH/MDcGA1Ud
    EQEB/wQtMCuHECABAD/+AAAFXmChVx6R
    oLeGF2h0dHBzOi8vcmFhLmV4YW1wbGUu
    Y29tMAUGAytlcANBALUPjhIB3rwqXQep
    r9/VDB+hhtwuWZIw1OUkEuDrF6DCkgc7
    5widXnXa5/uDfdKL7dZ83mPHm2Tf32Dv
    b8AzEw8=
)

Figure 9: RAA Auth HHIT RRType Example

Figure 10 shows the CBOR decoded RDATA in the HHIT RRType found in Figure 9. Bestie, this is the decoded version 🔍

[
    10,  # Reserved (RAA Auth from DKI)
    "3ff8 0000",
    h'308201423081F5A00302010202013530
    0506032B6570302B312930270603550403
    0C20323030313030336666653030303030
    3535653630613135373165393161306237
    301E170D3235303430393230353632365A
    170D3235303430393231353632365A301D
    311B301906035504030C12445249502D52
    41412D412D31363337362D30302A300506
    032B65700321009990D5B04B72A18066D4
    092B52C7D4994FB7C16BD7E8C1F440FFA8
    D04FF1E13FA34C304A300F0603551D1301
    01FF040530030101FF30370603551D1101
    01FF042D302B87102001003FFE0000055E
    60A1571E91A0B7861768747470733A2F2F
    7261612E6578616D706C652E636F6D3005
    06032B6570034100B50F8E1201DEBC2A5D
    07A9AFDFD50C1FA186DC2E599230D4E524
    12E0EB17A0C292073BE7089D5E75DAE7FB
    837DD28BEDD67CDE63C79B64DFDF60EF6F
    C033130F'
]

Figure 10: 2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded HHIT RRType CBOR

Figure 11 shows the decoded DER X.509 found in Figure 10 🧁

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 53 (0x35)
        Signature Algorithm: ED25519
        Issuer: CN = 2001003ffe0000055e60a1571e91a0b7
        Validity
            Not Before: Apr  9 20:56:26 2025 GMT
            Not After : Apr  9 21:56:26 2025 GMT
        Subject: CN = DRIP-RAA-A-16376-0
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    99:90:d5:b0:4b:72:a1:80:66:d4:09:2b:52:c7:d4:
                    99:4f:b7:c1:6b:d7:e8:c1:f4:40:ff:a8:d0:4f:f1:
                    e1:3f
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE00:5:5E60:A157:1E91:A0B7,
                URI:https://raa.example.com
    Signature Algorithm: ED25519
    Signature Value:
        b5:0f:8e:12:01:de:bc:2a:5d:07:a9:af:df:d5:0c:1f:a1:86:
        dc:2e:59:92:30:d4:e5:24:12:e0:eb:17:a0:c2:92:07:3b:e7:
        08:9d:5e:75:da:e7:fb:83:7d:d2:8b:ed:d6:7c:de:63:c7:9b:
        64:df:df:60:ef:6f:c0:33:13:0f

Figure 11: 2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded Certificate

A.1.2. Delegation of HDA

Last bit of the RAA story: the delegation to the HDA 🎀

$ORIGIN c.d.f.f.3.0.0.1.0.0.2.ip6.example.com.
a.0.0. IN NS ns1.hda-10.example.com

Figure 12: HDA Delegation Example

A.2. Example HDA

A.2.1. Authentication and Issue HHITs ✨

okay bestie, this is the good part 🎀 we finally get to see the HDA's two HHIT records sitting in the zone file, one for auth and one for issue, both hanging off the $ORIGIN 🦋

$ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com.
0.a.9.0.7.2.4.d.5.4.e.e.5.1.6.6.5.0. IN HHIT (
    gw5pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD
    AgECAgFfMAUGAytlcDArMSkwJwYDVQQD
    DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx
    NTcxZTkxYTBiNzAeFw0yNTA0MDkyMTAz
    MTlaFw0yNTA0MDkyMjAzMTlaMB4xHDAa
    BgNVBAMME0RSSVAtSERBLUEtMTYzNzYt
    MTAwKjAFBgMrZXADIQDOaB424RQa61YN
    bna8eWt7fLRU5GPMsfEt4wo4AQGAP6NM
    MEowDwYDVR0TAQH/BAUwAwEB/zA3BgNV
    HREBAf8ELTArhxAgAQA//gAKBWYV7kXU
    JwmghhdodHRwczovL3JhYS5leGFtcGxl
    LmNvbTAFBgMrZXADQQAhMpOSOmgMkJY1
    f+B9nTgawUjK4YEERBtczMknHDkOowX0
    ynbaLN60TYe9hqN6+CJ3SN8brJke3hpM
    gorvhDkJ
)
8.2.e.6.5.2.b.6.7.3.4.d.e.0.6.2.5.0. IN HHIT (
    gw9pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD
    AgECAgFYMAUGAytlcDArMSkwJwYDVQQD
    DCAyMDAxMDAzZmZlMDAwYTA1NjYxNWVl
    NDVkNDI3MDlhMDAeFw0yNTA0MDkyMTA1
    MTRaFw0yNTA0MDkyMjA1MTRaMB4xHDAa
    BgNVBAMME0RSSVAtSERBLUktMTYzNzYt
    MTAwKjAFBgMrZXADIQCCM/2utQaLwUhZ
    0ROg7fz43AeBTj3Sdl5rW4LgTQcFl6NM
    MEowDwYDVR0TAQH/BAUwAwEB/zA3BgNV
    HREBAf8ELTArhxAgAQA//gAKBSYO1Ddr
    JW4ohhdodHRwczovL2hkYS5leGFtcGxl
    LmNvbTAFBgMrZXADQQBa8lZyftxHJqDF
    Vgv4Rt+cMUmc8aQwet4UZdO3yQOB9uq4
    sLVAScaZCWjC0nmeRkgVRhize1esfyi3
    RRU44IAE
)

Figure 13: HDA Auth/Issue HHIT RRType Example

Figure 14 is the CBOR decoded RDATA for the HHIT RRType from Figure 13, so you can see what's actually inside the blob 👀💅

[
    14,  # Reserved (HDA Auth from DKI)
    "3ff8 000a",
    h'308201433081F6A00302010202015F30
    0506032B6570302B312930270603550403
    0C20323030313030336666653030303030
    3535653630613135373165393161306237
    301E170D3235303430393231303331395A
    170D3235303430393232303531395A301E
    311C301A06035504030C13445249502D48
    44412D412D31363337362D3130302A3005
    06032B6570032100CE681E36E1141AEB56
    0D6E76BC796B7B7CB454E463CCB1F12DE3
    0A380101803FA34C304A300F0603551D13
    0101FF040530030101FF30370603551D11
    0101FF042D302B87102001003FFE000A05
    6615EE45D42709A0861768747470733A2F
    2F7261612E6578616D706C652E636F6D30
    0506032B6570034100213293923A680C90
    96357FE07D9D381AC148CAE18104441B5C
    CCC9271C390EA305F4CA76DA2CDEB44D87
    BD86A37AF8227748DF1BAC991EDE1A4C82
    8AEF843909'
]

Figure 14: 2001:3f:fe00:a05:6615:ee45:d427:9a0 Decoded HHIT RRType CBOR

Figure 15 is the decoded DER X.509 certificate from Figure 14, and this is where the cert details get spelled out, like who issued it, the validity window, the public key, and the SAN with the RAA URI 🔥

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 95 (0x5f)
        Signature Algorithm: ED25519
        Issuer: CN = 2001003ffe0000055e60a1571e91a0b7
        Validity
            Not Before: Apr  9 21:03:19 2025 GMT
            Not After : Apr  9 22:03:19 2025 GMT
        Subject: CN = DRIP-HDA-A-16376-10
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    ce:68:1e:36:e1:14:1a:eb:56:0d:6e:76:bc:79:6b:
                    7b:7c:b4:54:e4:63:cc:b1:f1:2d:e3:0a:38:01:01:
                    80:3f
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE00:A05:6615:EE45:D427:9A0,
                URI:https://raa.example.com
    Signature Algorithm: ED25519
    Signature Value:
        21:32:93:92:3a:68:0c:90:96:35:7f:e0:7d:9d:38:1a:c1:48:
        ca:e1:81:04:44:1b:5c:cc:c9:27:1c:39:0e:a3:05:f4:ca:76:
        da:2c:de:b4:4d:87:bd:86:a3:7a:f8:22:77:48:df:1b:ac:99:
        1e:de:1a:4c:82:8a:ef:84:39:09

Figure 15: 2001:3f:fe00:a05:6615:ee45:d427:9a0 Decoded Certificate

Figure 16 is the CBOR decoded RDATA for the HHIT RRType, once again pointing back at Figure 13, and this one is the issue side of the HDA 💜

[
    15,  # Reserved (HDA Issue from DKI)
    "3ff8 000a",
    h'308201433081F6A00302010202015830
    0506032B6570302B312930270603550403
    0C20323030313030336666653030306130
    3536363135656534356434323730396130
    301E170D3235303430393231303531345A
    170D3235303430393232303531345A301E
    311C301A06035504030C13445249502D48
    44412D492D31363337362D3130302A3005
    06032B65700321008233FDAEB5068BC148
    59D113A0EDFCF8DC07814E3DD2765E6B5B
    82E04D070597A34C304A300F0603551D13
    0101FF040530030101FF30370603551D11
    0101FF042D302B87102001003FFE000A05
    260ED4376B256E28861768747470733A2F
    2F6864612E6578616D706C652E636F6D30
    0506032B65700341005AF256727EDC4726
    A0C5560BF846DF9C31499CF1A4307ADE14
    65D3B7C90381F6EAB8B0B54049C6990968
    C2D2799E4648154618B37B57AC7F28B745
    1538E08004'
]

Figure 16: 2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded HHIT RRType CBOR

Figure 17 is the decoded DER X.509 certificate from Figure 16, and yes, the HDA-I cert is giving the same level of detail 💅✨

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 88 (0x58)
        Signature Algorithm: ED25519
        Issuer: CN = 2001003ffe000a056615ee45d42709a0
        Validity
            Not Before: Apr  9 21:05:14 2025 GMT
            Not After : Apr  9 22:05:14 2025 GMT
        Subject: CN = DRIP-HDA-I-16376-10
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    82:33:fd:ae:b5:06:8b:c1:48:59:d1:13:a0:ed:fc:
                    f8:dc:07:81:4e:3d:d2:76:5e:6b:5b:82:e0:4d:07:
                    05:97
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE00:A05:260E:D437:6B25:6E28,
                URI:https://hda.example.com
    Signature Algorithm: ED25519
    Signature Value:
        5a:f2:56:72:7e:dc:47:26:a0:c5:56:0b:f8:46:df:9c:31:49:
        9c:f1:a4:30:7a:de:14:65:d3:b7:c9:03:81:f6:ea:b8:b0:b5:
        40:49:c6:99:09:68:c2:d2:79:9e:46:48:15:46:18:b3:7b:57:
        ac:7f:28:b7:45:15:38:e0:80:04

Figure 17: 2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded Certificate

A.2.2. Registrant HHIT and BRID 🎀

Okay bestie, here's the registrant example! 💅 The $ORIGIN is set first, and then we get the HHIT and BRID records for the same registrant.

$ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com.
2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. IN HHIT (
    gxJpM2ZmOCAwMDBhWQEYMIIBFDCBx6AD
    AgECAgFUMAUGAytlcDArMSkwJwYDVQQD
    DCAyMDAxMDAzZmZlMDAwYTA1MjYwZWQ0
    Mzc2YjI1NmUyODAeFw0yNTA0MDkyMTEz
    MDBaFw0yNTA0MDkyMjEzMDBaMAAwKjAF
    BgMrZXADIQDJLi+dl+iWD5tfFlT4sJA5
    +drcW88GHqxPDOp56Oh3+qM7MDkwNwYD
    VR0RAQH/BC0wK4cQIAEAP/4ACgUTCCRp
    mkvGsoYXaHR0cHM6Ly9oZGEuZXhhbXBs
    ZS5jb20wBQYDK2VwA0EA0DbcdngC7/BB
    /aLjZmLieo0ZFCDbd/KIxAy+3X2KtT4J
    todVxRMPAkN6o008gacbNfTG8p9npEcD
    eYhesl2jBQ==
)
2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. IN BRID (
    owAAAYIEUQEgAQA//gAKBRMIJGmaS8ay
    AogFWIkB+t72Zwrt9mcgAQA//gAABV5g
    oVcekaC3mZDVsEtyoYBm1AkrUsfUmU+3
    wWvX6MH0QP+o0E/x4T8gAQA//gAABV5g
    oVcekaC3vC9m1JguvXt7W2o4wxPumaT1
    IP3TQN3fQP28hpInSIlsSwq8UCNjm2ad
    7pdTvm2EqfOJQNPKClvRZm4qTO5FDAVY
    iQGX4PZnp+72ZyABAD/+AAoFZhXuRdQn
    CaDOaB424RQa61YNbna8eWt7fLRU5GPM
    sfEt4wo4AQGAPyABAD/+AAAFXmChVx6R
    oLfv3q+mLRB3ya5TmjY8+3CzdoDZT9RZ
    +XpN5hDiA6JyyxBJvUewxLzPNhTXQp8v
    ED71XAE82tMmt3fB4zbzWNQLBViJAQrh
    9mca7/ZnIAEAP/4ACgUmDtQ3ayVuKIIz
    /a61BovBSFnRE6Dt/PjcB4FOPdJ2Xmtb
    guBNBwWXIAEAP/4ACgVmFe5F1CcJoIjy
    CriJCxAyAWTOHPmlHL02MKSpsHviiTze
    qwBH9K/Rrz41CYix9HazAIOAZO8FcfU5
    M+WLLJZoaQWBHnMbTQwFWIkB3OL2Z+zw
    9mcgAQA//gAKBRMIJGmaS8ayyS4vnZfo
    lg+bXxZU+LCQOfna3FvPBh6sTwzqeejo
    d/ogAQA//gAKBSYO1DdrJW4ogOfc8jTi
    mYLmTOOyFZoUx2jOOwtB1jnqUJr6bYaw
    MoPrR3MlKGBGWsVz1yXNqUURoCqYdwsY
    e61vd5i6YJqnAQ==
)

Figure 18: Registrant HHIT/BRID RRType Example 🦋

Figure 19 is the CBOR decoded RDATA from the HHIT RRType in Figure 18, and it's so pretty to look at ✨

[
    18,  # Uncrewed Aircraft System (UAS)
    "3ff8 000a",
    h'308201143081C7A00302010202015430
    0506032B6570302B312930270603550403
    0C20323030313030336666653030306130
    3532363065643433373662323536653238
    301E170D3235303430393231313330305A
    170D3235303430393232313330305A3000
    302A300506032B6570032100C92E2F9D97
    E8960F9B5F1654F8B09039F9DADC5BCF06
    1EAC4F0CEA79E8E877FAA33B3039303706
    03551D110101FF042D302B87102001003F
    FE000A05130824699A4BC6B28617687474
    70733A2F2F6864612E6578616D706C652E
    636F6D300506032B6570034100D036DC76
    7802EFF041FDA2E36662E27A8D191420DB
    77F288C40CBEDD7D8AB53E09B68755C513
    0F02437AA34D3C81A71B35F4C6F29F67A4
    470379885EB25DA305'
]

Figure 19: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded HHIT RRType CBOR 🌸

Figure 20 shows the decoded DER X.509 that lives inside Figure 19. It's giving certificate realness 🔐

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 84 (0x54)
        Signature Algorithm: ED25519
        Issuer: CN = 2001003ffe000a05260ed4376b256e28
        Validity
            Not Before: Apr  9 21:13:00 2025 GMT
            Not After : Apr  9 22:13:00 2025 GMT
        Subject:
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    c9:2e:2f:9d:97:e8:96:0f:9b:5f:16:54:f8:b0:90:
                    39:f9:da:dc:5b:cf:06:1e:ac:4f:0c:ea:79:e8:e8:
                    77:fa
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address:2001:3F:FE00:A05:1308:2469:9A4B:C6B2,
                URI:https://hda.example.com
    Signature Algorithm: ED25519
    Signature Value:
        d0:36:dc:76:78:02:ef:f0:41:fd:a2:e3:66:62:e2:7a:8d:19:
        14:20:db:77:f2:88:c4:0c:be:dd:7d:8a:b5:3e:09:b6:87:55:
        c5:13:0f:02:43:7a:a3:4d:3c:81:a7:1b:35:f4:c6:f2:9f:67:
        a4:47:03:79:88:5e:b2:5d:a3:05

Figure 20: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded Certificate 💜

Figure 21 is the CBOR decoded RDATA of the BRID RRType in Figure 18. Main character energy 👑

{
    0: 0,
    1: [4, h'012001003FFE000A05130824699A4BC6B2'],
    2: [
        5,
        h'01FADEF6670AEDF6672001003FFE0000
        055E60A1571E91A0B79990D5B04B72A180
        66D4092B52C7D4994FB7C16BD7E8C1F440
        FFA8D04FF1E13F2001003FFE0000055E60
        A1571E91A0B7BC2F66D4982EBD7B7B5B6A
        38C313EE99A4F520FDD340DDDF40FDBC86
        922748896C4B0ABC5023639B669DEE9753
        BE6D84A9F38940D3CA0A5BD1666E2A4CEE
        450C',
        5,
        h'0197E0F667A7EEF6672001003FFE000A
        056615EE45D42709A0CE681E36E1141AEB
        560D6E76BC796B7B7CB454E463CCB1F12D
        E30A380101803F2001003FFE0000055E60
        A1571E91A0B7EFDEAFA62D1077C9AE539A
        363CFB70B37680D94FD459F97A4DE610E2
        03A272CB1049BD47B0C4BCCF3614D7429F
        2F103EF55C013CDAD326B777C1E336F358
        D40B',
        5,
        h'010AE1F6671AEFF6672001003FFE000A
        05260ED4376B256E288233FDAEB5068BC1
        4859D113A0EDFCF8DC07814E3DD2765E6B
        5B82E04D0705972001003FFE000A056615
        EE45D42709A088F20AB8890B10320164CE
        1CF9A51CBD3630A4A9B07BE2893CDEAB00
        47F4AFD1AF3E350988B1F476B300838064
        EF0571F53933E58B2C96686905811E731B
        4D0C',
        5,
        h'01DCE2F667ECF0F6672001003FFE000A
        05130824699A4BC6B2C92E2F9D97E8960F
        9B5F1654F8B09039F9DADC5BCF061EAC4F
        0CEA79E8E877FA2001003FFE000A05260E
        D4376B256E2880E7DCF234E29982E64CE3
        B2159A14C768CE3B0B41D639EA509AFA6D
        86B03283EB4773252860465AC573D725CD
        A94511A02A98770B187BAD6F7798BA609A
        A701'
    ]
}

Figure 21: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded BRID RRType CBOR 🧚

Acknowledgements 🫶

Huge thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT Consulting, LLC) for their early work on the DRIP registries concept! Their early contributions laid the foundation for the content and processes of this architecture and document, so they really did the groundwork 🌈 The authors also want to thank the DRIP chairs and AD, the reviewers from the various Directorates, and the members of the IESG at time of publication. Y'all are iconic 💖

Authors' Addresses 📮

Adam Wiethuechter (editor)
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com


Jim Reid
RTFM llp
St Andrews House
382 Hillington Road, Glasgow Scotland
G51 4BL
United Kingdom
Email: jim@rfc1035.com
📦 where this page comes from