| RFC 9886 | DET in DNS | December 2025 |
| Wiethuechter & Reid | Standards Track | [Page] |
This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote Identification and other services.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9886.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Registries are fundamental to Unmanned Aircraft System (UAS) Remote Identification (RID). Only very limited operational information can be sent via Broadcast RID, but extended information is sometimes needed. The most essential element of information from RID is the UAS ID, the unique key for lookup of extended information in relevant registries (seeFigure 1, which is 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 AvoidGPOD: General Public Observer DevicePSOD: Public Safety Observer DeviceV2I: Vehicle-to-InfrastructureV2V: Vehicle-to-Vehicle
When a DRIP Entity Tag (DET)[RFC9374] is used as the UAS ID in RID, extended information can be retrieved from a DRIP Identity Management Entity (DIME), which manages registration of and associated lookups from DETs. In this document it is assumed the DIME is a function of UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]), but a DIME can be independent or handled by another entity as well.¶
DRIP Entity Tags (DETs) embed a hierarchy scheme that is mapped onto the Domain Name System (DNS)[STD13]. DIMEs enforce registration and information access of data associated with a DET while also providing the trust inherited from being a member of the hierarchy. Other identifiers and their methods are out of scope for this document.¶
Authoritative name servers of the DNS provide the public information such as the cryptographic keys, endorsements and certificates of DETs, and pointers to private information resources. Cryptographic (public) keys are used to authenticate anything signed by a DET, such as in the Authentication Messages defined in[RFC9575] for Broadcast RID. Endorsements and certificates are used to endorse the claim of being part of the hierarchy.¶
This document does not specify AAA mechanisms used by Private Information Registries to store and protect Personally Identifiable Information (PII).¶
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.¶
This document makes use of the terms and abbreviations from previous DRIP documents. Below are subsets, grouped by original document, of terms used this document. Please see those documents for additional context, definitions, and any further referenced material.¶
FromSection 2.2 of [RFC9153], this document uses: AAA, CAA, GCS, ICAO, PII, Observer, Operator, UA, UAS, USS, and UTM.¶
FromSection 2 of [RFC9434], this document uses: Certificate, DIME, and Endorsement.¶
FromSection 2 of [RFC9374], this document uses: HDA, HID, and RAA.¶
[RFC9374] defines the Hierarchical Host Identity Tags (HHIT) and further specifies an instance of them used for UAS RID called DET. The DET is a 128-bit value that is an IPv6 address intended primarily as an identifier rather than locator. The format is shown inFigure 2 and further information is in[RFC9374].¶
+-------------+--------------+---------------+-------------+| 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) | +--------------------------------+-----------------------+
[RFC9374] assigns the IPv6 prefix2001:30::/28 for DETs. Its corresponding domain name for reverse lookups is3.0.0.1.0.0.2.ip6.arpa.. The IAB has administrative control of this domain name.¶
Due to the nature of the hierarchy split and its relationship to nibble reversing of the IPv6 address (Section2.5 of RFC 3596[STD88]), the upper level of the hierarchy (i.e., Registered Assigning Authority (RAA)) "borrows" the upper two bits of their respective HHIT Domain Authority (HDA) space for DNS delegation. As such, the IPv6 prefix of RAAs is2001:3x:xxx0::/44 and HDAs is2001:3x:xxxy:yy00::/56 with respective nibble reverse domains ofx.x.x.x.3.0.0.1.0.0.2.ip6.arpa. andy.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa..¶
This document preallocates a subset of RAAs based on the ISO 3166-1 Numeric Nation Code[ISO3166-1]. This is to support the initial use case of DETs in UAS RID on an international level. SeeSection 6.2.1 for the RAA allocations.¶
The HDA values of 0, 4096, 8192, and 12288 are reserved for operational use of an RAA (a by-product of the above mentioned borrowing of bits), in particular to specify when to register with the apex and endorse delegations of HDAs in their namespace.¶
The administration, management, and policy for the operation of a DIME at any level in the hierarchy (Apex, RAA or HDA) is out of scope for this document. For RAAs or DETs allocated on a per-country basis, these considerations should be determined by the appropriate national authorities, presumably the Civil Aviation Authority (CAA).¶
DRIP relies on the DNS and as such roughly follows the registrant-registrar-registry model. In the UAS ecosystem, the registrant would be the end user who owns/controls the Unmanned Aircraft. They are ultimately responsible for the DET and any other information that gets published in the DNS. Registrants use agents known as registrars to manage their interactions with the registry. Registrars typically provide optional additional services such as DNS hosting.¶
The registry maintains a database of the registered domain names and their related metadata such as the contact details for domain name holder and the relevant registrar. The registry provides DNS service for the zone apex, which contains delegation information for domain names. Registries generally provide services such as the Registration Data Access Protocol (RDAP)[STD95] or equivalent to publish metadata about the registered domain names and their registrants and registrars.¶
Registrants have contracts with registrars who in turn have contracts with registries. Payments follow this model too: 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 with each other on price, service, and customer support.¶
ApexRegistry/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. | +======================================+
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 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 the3.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 inFigure 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.¶
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 underip6.arpa. (nibble reversed per Section2.5 of RFC 3596[STD88]) andMUST resolve to an HHIT RRType. Depending on local circumstances or additional use cases, other RRTypesMAY be present (for example the inclusion of the DS RRTypes or equivalent when using DNSSEC). For UAS RID, the BRID RRTypeMUST be present to provide the Broadcast Endorsements (BEs) defined inSection 3.1.2.1 of [RFC9575].¶
DNSSECMUST be used for apex entities (those which use a self-signedCanonical Registration Certificate) and isRECOMMENDED for other entities. When a DIME decides to use DNSSEC, theySHOULD 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 is out of scope for this document.¶
A DET IPv6 address gets mapped into domain names using the scheme defined in Section2.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 DET2001:30::1 would be returned from a DNS lookup for the HHIT QTYPE for1.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..¶
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].¶
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 theCanonical Registration Certificate containing an entity's public key signed by the registrar, or other trust anchor, to confirm registration.¶
The dataMUST be encoded in the Concise Binary Object Representation (CBOR)[RFC8949] bytes. The Concise Data Definition Language (CDDL)[RFC8610] of the data is provided inFigure 4.¶
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.¶
The dataMAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined inAppendix G of [RFC8610].¶
hhit-rr = [ hhit-entity-type: uint, hid-abbreviation: tstr .size(15), canonical-registration-cert: bstr]
All fields of the HHIT RRTypeMUST be included to be properly formed.¶
TheHHIT Entity Type field is a number with values defined inSection 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 fieldMAY provide a signal of additional information and/or different handling of the data beyond what is defined in this document.¶
TheHID 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 fieldMUST 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.¶
TheCanonical Registration Certificate field is for a certificate-endorsing registration of the DET. ItMUST be encoded as X.509 DER[RFC5280]. This certificateMAY 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.¶
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 of one or more Broadcast Endorsements as defined in[RFC9575] in theauth field. These Endorsements are generated by the registrar upon successful registration and broadcast by the entity.¶
The dataMUST be encoded in CBOR[RFC8949] bytes. The CDDL[RFC8610] of the data is provided inFigure 5.¶
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.¶
The dataMAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined inAppendix G of [RFC8610]. All byte strings longer than a length of 20SHOULD be displayed as base64 when possible.¶
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..15uas_type = 0uas_ids = 1auth = 2self_id = 3area = 4classification = 5operator_id = 6The field names and their general typing are taken from the ASTM data dictionary (Tables 1 and 2)[F3411]. See that document for additional context and background information on aviation application-specific interpretation of the field semantics. The explicitly enumerated values included in the CDDL above are relevant to DRIP for its operation. Other values may be valid but are outside the scope of DRIP operation. Application-specific fields, such as UAS Type, are transported and authenticated by DRIP but are regarded as opaque user data to DRIP.¶
The reverse domain for the DET Prefix, i.e.,3.0.0.1.0.0.2.ip6.arpa., is managed by IANA. IANA will liaise, as needed, with the International Civil Aviation Organization (ICAO) to verify the authenticity of delegations to CAAs (seeSection 6.2.1.4).¶
IANA has created the registry for RAA Allocations under the"Drone Remote ID Protocol" registry group.¶
a 14-bit value used to represent RAAs. Future additions to this registry are to be made based on the following range and policy table:¶
| RAA Range | Allocation | Policy |
|---|---|---|
| 0 - 3 | Reserved | |
| 4 - 3999 | ISO 3166-1 Countries | IESG Approval (Section 4.10 of [RFC8126]),Section 6.2.1.4 |
| 4000 - 8191 | Reserved | |
| 8192 - 15359 | Unassigned | First Come First Served (Section 4.4 of [RFC8126]) |
| 15360 - 16383 | Private Use | Private Use (Section 4.1 of [RFC8126]),Section 6.2.1.5 |
The RAA value delegated for this entry.¶
Name of the delegated RAA. For the ISO 3166-1 Countries (Section 6.2.1.4), this should be the name of the country.¶
A publicly accessible link to the policy requirements for prospective HDA operators to register under this RAA. This field isOPTIONAL.¶
Contact details of the administrator of this RAA that prospective HDA operators can make informational queries to.¶
Value:Name:Reference:Contact:NS RRType Content (HDA=0):NS RRType Content (HDA=4096):NS RRType Content (HDA=8192):NS RRType Content (HDA=12288):
TheNS RRType Content (HDA=X) fields are used by IANA to perform the DNS delegations under3.0.0.1.0.0.2.ip6.arpa.. SeeSection 6.2.1.3 for technical details.¶
To support DNS delegation in3.0.0.1.0.0.2.ip6.arpa., a single RAA is given 4 delegations by borrowing the upper two bits of HDA space (seeFigure 7 for an example). This enables a clean nibble boundary in the DNS to delegate from (i.e., the prefix2001: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
The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is specified and documented by IANA. Each Nation is assigned 4 RAAs that are left to the national authority for their purpose. For RAAs under this range, a shorter prefix of2001:3x:xx00::/40MAY be delegated to each CAA, which 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]) and IANA will liaise with the ICAO to verify the authenticity of delegation requests (usingFigure 6) by CAAs.¶
If nibble-reversed lookup in DNS is desired, it can only be provided by private DNS servers as zone delegations from the global root will not be performed for this address range. Thus the RAAs (with its subordinate HDAs) in this range may be used in like manner and IANA will not 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 for experimentation and testing prior to request allocation or assignment from IANA.¶
This document requests a new registry for HHIT Entity Types under the"Drone Remote ID Protocol" registry group.¶
Numeric, field of the HHIT RRType to encode the HHIT Entity Type. All entries in this registry are under the First Come First Served policy (Section 4.4 of [RFC8126]).¶
Value:HHIT Type:Reference:
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 |
The Registrar and Registry are commonly used concepts in the DNS. These components connect the DIME with the DNS hierarchy and thus operationSHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate except when national regulations prevent it.[BCP237] provides suitable guidance.¶
If DNSSEC is used, a DNSSEC Practice StatementSHOULD be developed and published. ItSHOULD 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 specifications for registry-registrar interactions are intentionally not specified in this document. These will depend on nationally defined policy and prevailing local circumstances. It is expected that registry-registrar activity will use the Extensible Provisioning Protocol (EPP)[STD69] or equivalent. The registrySHOULD provide a lookup service such as RDAP[STD95] or equivalent to publish public information about registered domain names.¶
Decisions about DNS or registry best practices and other operational matters that influence securitySHOULD be made by the CAA, ideally in consultation with local stakeholders.¶
The guidance above is intended to reduce the likelihood of interoperability problems and minimize security and stability concerns. For instance, validation and authentication of DNS responses depends on DNSSEC. If this is not used, entities using DRIP will be vulnerable to DNS spoofing attacks and could be exposed to bogus data. DRIP DNS responses that have not been validated by DNSSEC could contain bogus data that have the potential to create serious security problems and operational concerns for DRIP entities. These 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/relationships. Some regulatory and legal considerations are expected to be simplified by providing a lookup service for access to public information about registered domain names for DETs.¶
When DNSSEC is not in use, due to the length of the ORCHID hash selected for DETs (Section 3.5 of [RFC9374]), clientsMUST "walk" the tree of certificates locating each certificate by performing DNS lookups of HHIT RRTypes for each DET verifying inclusion into the hierarchy. The collection of these certificates (which provide both signature protection from the parent entity and the public key of the entity) is the only way without DNSSEC to prove valid registration.¶
The contents of the BRID RRTypeauth key, containing Endorsements as described inSection 4.2 of [RFC9575], are a shadow of the X.509 certificate found in the HHIT RRType. The validation of these Endorsements follow the guidelines written inSection 6.4.2 of [RFC9575] for Broadcast RID Observers and when presentMUST also be validated.¶
DETs are built upon asymmetric keys. As such the public key must be revealed to enable clients to perform signature verifications.[RFC9374] security considerations cover various attacks on such keys. While unlikely, the forging of a corresponding private key is possible if given enough time (and computational power).¶
When practical, it isRECOMMENDED that no RRTypes under a DET's specific domain name be published unless and until it is required for use by other parties. Such action would cause at least the HHIT RRType to not be in the DNS, protecting the public key in the certificate from being exposed before its needed. The combination of this "just in time" publishing mechanism and DNSSEC is out of scope for this document.¶
Optimally this requires that the UAS somehow signal to the DIME that a flight using a Specific Session ID will soon be underway or 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.¶
An example zone fileip6.arpa., run by IANA, is not shown. It would contain NS RRTypes to delegate to a respective RAA. To avoid any future collisions with production deployments an apex ofip6.example.com. is used instead ofip6.arpa.. All hexadecimal strings in the examples are broken into the lengths of a word, for document formatting purposes.¶
An RAA with a HID ofRAA=16376, HDA=0 and HDA with a the HIDRAA=16376, HDA=10 were used in the examples.¶
$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 10 shows the CBOR decoded RDATA in the HHIT RRType found inFigure 9.¶
[ 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 11 shows the decoded DER X.509 found inFigure 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
$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
$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 14 shows the CBOR decoded RDATA in the HHIT RRType found inFigure 13.¶
[ 14, # Reserved (HDA Auth from DKI) "3ff8 000a", h'308201433081F6A00302010202015F30 0506032B6570302B312930270603550403 0C20323030313030336666653030303030 3535653630613135373165393161306237 301E170D3235303430393231303331395A 170D3235303430393232303331395A301E 311C301A06035504030C13445249502D48 44412D412D31363337362D3130302A3005 06032B6570032100CE681E36E1141AEB56 0D6E76BC796B7B7CB454E463CCB1F12DE3 0A380101803FA34C304A300F0603551D13 0101FF040530030101FF30370603551D11 0101FF042D302B87102001003FFE000A05 6615EE45D42709A0861768747470733A2F 2F7261612E6578616D706C652E636F6D30 0506032B6570034100213293923A680C90 96357FE07D9D381AC148CAE18104441B5C CCC9271C390EA305F4CA76DA2CDEB44D87 BD86A37AF8227748DF1BAC991EDE1A4C82 8AEF843909']
Figure 15 shows the decoded DER X.509 found inFigure 14.¶
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 16 shows the CBOR decoded RDATA in the HHIT RRType found inFigure 13.¶
[ 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 17 shows the decoded DER X.509 found inFigure 16.¶
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
$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 19 shows the CBOR decoded RDATA in the HHIT RRType found inFigure 18.¶
[ 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 20 shows the decoded DER X.509 found inFigure 19.¶
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 21 shows the CBOR decoded RDATA of the BRID RRType inFigure 18.¶
{ 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' ]}Thanks toStuart Card (AX Enterprize, LLC) andBob 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. The authors would also like to thank the DRIP chairs and AD, the reviewers from the various Directorates, and the members of the IESG at time of publication.¶