DRIP Entity Tag (DET) Identity Management Architecture

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 3 October 2024.¶

Copyright Notice

Copyright (c) 2024 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.¶

Table of Contents

1. Introduction

Registries are fundamental to Unmanned Aircraft System (UAS) Remote ID (RID). Only very limited operational information can be sent via Broadcast RID, but extended information is sometimes needed. The most essential element of information is the UAS ID, the unique key for lookup of extended information in relevant registries (see Figure 4 of [RFC9434]).¶

Such extended information is retrieved from the UAS ID via the use of a DRIP Entity Tag (DET) [RFC9374] which is managed by the DRIP Identity Management Entity (DIME). In this document we assume the DIME belongs to the UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]) but a DIME can be independent or handled by another entity as well.¶

While most data to be sent via Broadcast RID (Section 1.2.1 of [RFC9434]) or Network RID (Section 1.2.2 of [RFC9434]) is public, much of the extended information will be private. As discussed in Section 7 of [RFC9434], Authentication, Attestation, Authorization, Access Control, Accounting, Attribution, and Audit (typically known as AAA) is essential, not just to ensure that access is granted only to strongly authenticated, duly authorized parties, but also to support subsequent attribution of any leaks, audit of who accessed information when and for what purpose. As specific AAA requirements will vary by jurisdictional regulation, provider choices, customer demand, etc., they are left to specification in policies which are out of scope for this document.¶

The intent of the access control requirements is to ensure that no member of the public would be hindered from accessing public information, while only duly authorized parties would be enabled to access private information.¶

Registration is necessary to guarantee the uniqueness of the DET and thus to ensure the extended information is bound to the UAS ID.¶

This document creates the DRIP registration and discovery architecture focusing on the DET for UAS at its surrounding ecosystem. Clients in the architecture that can use a DET include Unmanned Aircraft (UA), Registered Assigning Authority (RAA), Hierarchical HIT Domain Authority (HDA), Ground Control Station (GCS), and USS.¶

This document uses the Concise Data Definition Language (CDDL) [RFC8610] for describing the registration data.¶

2. General Concept

DETs when generated are only "proposed" and MUST be registered within the hierarchy to become legitimate. DIME's are the points in the hierarchy that enforce requirements on registration and information access. This document standardizes the basic interactions and methods for registration and lookup to support interoperability based around DETs. Other identifiers and their methods are out of scope for this document.¶

This document selects the Domain Name System (DNS) as the Public Information Registry for both storing and retrieving public information, such as the public key of DETs and pointers to Private Information Registries. Personally Identifiable Information (PII) is stored in Private Information Registries and MUST be protected through AAA.¶

For UAS, a DIME can provide the following congruent registration and lookup services:¶

1. personal information (e.g. for pilots and operators)¶
2. UAS Serial Number and aircraft physical characteristics¶
3. DETs as a Key ID for UAS RID Authentication ([drip-auth])¶
4. DETs as a pseudo-anonymous UAS Specific Session ID (UAS ID Type 4)¶
5. binding of UAS ID to UTM Operational Intent¶

A DIME's services are determined by their intended role (Section 4) and policies (both internally and from cognizant authorities). For example, services 1 and 2 can be restricted to non-public access controlled lookups with mandatory registration and 5 to publicly available but access controlled lookups.¶

For this document only services 3 and 4, as they directly relate to DETs, are detailed. Services 1 and 5 will be talked about conceptually while service 2 is out of scope.¶

Requirements on the elements of information in registration and lookup (beyond the scope basic interoperability) is out of scope for this document. It is left to cognizant authorities to determine these details along with policy for access. For the UAS use-case this is Civil Aviation Authorities (CAAs).¶

3. Terminology

4. DIME Roles

[RFC9374] defines the Hierarchical Host Identity Tag (HHIT) and further specifies an instance of them used for UAS RID called DETs.¶

As a review, HHITs are comprised of four major components: a Prefix, a Hierarchy ID (HID), a HHIT Suite ID (fixed 8-bits) and an ORCHID Hash. DETs use a 28-bit prefix and 64-bit hash leaving 28-bits for the HID. For UAS RID this HID is further divided into two fields: RAA and HDA, each 14-bits in length. Figure 1 shows this breakdown.¶

+-------------+--------------+---------------+-------------+
| 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)             |
        +--------------------------------+-----------------------+

[RFC9434] defines the DRIP Identity Management Entity (DIME) as an entity that vets Claims and/or Evidence from a registrant and delivers, to successful registrations, Endorsements and/or Certificates in response. The DIME encompasses various logical components (Section 5) and can be classified to serve a number of different roles, mapped to levels in the hierarchy, which are detailed in the following subsections.¶

5. DIME Architecture

The DIME, in any of its roles (Section 4), is comprised of a number of logical components that are depicted in Figure 2. Any of these components could be delegated to other entities as a service both co-located or remote.¶

Interfaces with a specific transport requirement (such as HTTPS) are labeled accordingly. Interfaces not labeled can be implementation specific or proprietary due to co-location of components. For example the interface between the DPA and Registry/Name Server, when delegated, might be Extensional Provisioning Protocol (EPP) [RFC5730] (due to Registry/Name Server requirements) while implementations co-locating these components might use an internal code library. These non-labeled interfaces are out of scope for this document.¶

+--------------------+
| Registering Client |
+---------o----------+
          |
          | HTTPS
          |
**********|*********************************************************
*         |       DRIP Identity Management Entity (DIME)           *
*         |                                                        *
*  +------o-------+         +-------------+      +--------------+  *
*  | DRIP         |         |             |      |              |  *
*  | Provisioning o---------o             |      |              |  *
*  | Agent (DPA)  |         |             |      |              |  *
*  +-------o------+         |             |      |              |  *
*          |                |             |      |              |  *
*          |                | DRIP        |      | Registration |  *
*          |                | Information o------o Data         |  *
*          |                | Agent (DIA) |      | Directory    |  *
*          |                |             |      | Service      |  *
*  +-------o----------+     |             |      | (RDDS)       |  *
*  |     Registry     |     |             |      |              |  *
*  |        /         |     |             |      |              |  *
*  | Name Server (NS) |     |             |      |              |  *
*  +------o-----------+     +-----o-------+      +--------------+  *
*         |                       |                                *
*         |                       |                                *
**********|***********************|*********************************
          |                       |
          | TCP/UDP               | RDAP
          |                       |
          |               +-------o-------+
          '---------------o Lookup Client |
                          +---------------+

6. DET Registration Process

The general process for a registering DET is as follows:¶

1. Verify inputs (such as Endorsement(s)) from registering client¶
2. DPA checks for collision of DET and HI¶
3. Populate Registry/Name Server with resource record(s)¶
4. Populate RDDS via DIA with PII and other info¶
5. Generate and return Endorsement(s)¶

Generically a DET can be used as an identifier for any client in UTM and SHOULD be registered to a DIME. For example a CAA may choose to use DETs for its Operators. A data model (such as what is specified in Section 6.1) would be required to define all the information for registration for a given classification of client.¶

Such specification beyond using DETs as a Session ID and/or Key ID (Section 6.2, Section 6.3 and Section 6.4) is out of scope for this document.¶

In the following subsections an abbreviated form of Figure 2 seen below in Figure 3 uses co-located components to describe the flow of information. Each section gives specific example details for the components, interfaces and data elements. Each section has an associated appendix (Appendix E) containing DNS examples.¶

    +----------+
    |  Client  |
    +--o---o---+
       |   ^
 (1,2) |   | (5)
       |   |
*******|***|*****************************
*      |   |      DIME                  *
*      |   |                            *
*      v   |             +----------+   *
*   +--o---o--+          |          |   *
*   | DPA (2) o--------->o          |   *
*   +----o----+   (4)    |          |   *
*        |               |          |   *
*        | (3)           | DIA/RDDS |   *
*        v               |          |   *
*   +----o--------+      |          |   *
*   | Registry/NS |      |          |   *
*   +-------------+      |          |   *
*                        +----------+   *
*                                       *
*****************************************

det_registration_info = {
    serial_number: tstr .size 20,  ; ANSI CTA2063-A UAS Serial Number
    uas_id: bstr .size 20,  ; UAS ID per ASTM F3411-22a Basic ID Message
    uas_id_type: 0..15,  ; UAS ID Type per ASTM F3411-22a
    ? key_id: bstr,
    ? self_endorsement: bstr .size 120,
    ? utm_binding,
    * tstr => any
}
utm_binding = (
    utm_id: bstr .size 16,  ; Operational Intent (UUIDv4)
    utm_source: tstr  ; URI to USS with Operational Intent
)

7. Differentiated Access Process

Per [RFC9434] all information classified as private is stored in a datastore protected using some form of differentiated access (i.e. AAA) to satisfy REG-2 from [RFC9153].¶

Differentiated access, as a process, is a requirement for DIMEs as defined in [RFC9153] by the combination of PRIV-1, PRIV-3, PRIV-4, REG-2 and REG-4. [RFC9434] further elaborates on the concept by citing RDAP (from [RFC7480], [RFC9082] and [RFC9083]) as a potential means of fulfilling this requirement.¶

Typically the cognizant authority is the primary querant of private information from a DIME if a Session ID is reported (the case of the owner of the private information is ignored for the moment). This capability MAY be delegated to other parties at the authorities discretion (be it to a single user or many), thus requiring a flexible system to delegate, determine and revoke querent access rights for information. XACML MAY be a good technology choice for this flexibility.¶

It is noted by the authors that as this system scales the problem becomes a, well known and tricky, key management problem. While recommendations for key management are useful they are not necessarily in scope for this document as best common practices around key management should already be mandated and enforced by the cognizant authorities in their existing systems. This document instead focuses on finding a balance for generic wide-spread interoperability between DIMEs with authorities and their existing systems in a Differentiated Access Process (DAP).¶

A system where cognizant authorities would require individual credentials to each HDA is not scalable, nor practical. Any change in policy would require the authority to interact with every single HDA (active or inactive) to grant or revoke access; this would be tedious and prone to mistakes. A single credential for a given authority is also strongly NOT RECOMMENDED due to the security concerns it would entail if it leaked.¶

A zero-trust model would be the most appropriate for a DAP; being highly flexible and robust. Most authorities however use "oracle" based systems with specific user credentials and the oracle knowing the access rights for a given user. This would require the DAP the have some standard mechanism to locate and query a given oracle for information on the querent to determine if access is granted.¶

DRIP has no intention to develop a new "art" of key management, instead hoping to leverage existing systems and be flexible enough to adapt as new ones become popular.¶

8. DRIP in the Domain Name System

Per [RFC9434] all information classified as public is stored in the DNS to satisfy REG-1 from [RFC9153].¶

DIMEs MUST be responsible for the operation of the DNS-related infrastructure for domain names under DRIP. It MAY chose to run that infrastructure directly or outsource it to competent third parties or some combination of the two.¶

DIMEs SHOULD specify the technical and administrative criteria for the provision of these services: contractual terms (if any), reporting, uptime, SLAs (if any), DNS query handling capacity, response times, incident handling, complaints, law enforcement interaction and so on. National policy and regulations will define how long DNS data are stored or archived. These are all National Matters where national law/regulation prevail ensuring DRIP complies with national law and regulation since these are matters of national sovereignty.¶

DNSSEC is strongly RECOMMENDED (especially for RAA-level and higher zones). When a DIME decides to use DNSSEC they SHOULD define a framework for cryptographic algorithms and key management [RFC6841]. This may be influenced by frequency of updates, size of the zone, and policies.¶

Static UAS specific information that is publicly available MAY also be stored in DNS but is out of scope for this document.¶

• Author Note: proposal for a UAS RR that is a CBOR map of static UAS data elements (UAS ID, UAS Type, Self Description, etc.)¶

For DRIP, IANA has agreed to act as the Apex at least initially (see Section 11.1 for more details). The delegation of civil aviation authorities to RAAs is already done per Section 4.2.1 using their ISO 3166-1 Numeric Codes. Since these are public, any entity can stand up an RAA with that value. The Apex SHOULD be the root of trust in a Endorsement or certificate chain that provides validation of any of these specific RAAs, in the ISO RAA range, thus protecting against bad actors standing up fraudulent RAAs.¶

9. Endorsements

DRIP Endorsements are defined in a CDDL [RFC8610] structure (Figure 4) that can be encoded to CBOR, JSON or as a binary blob by concatenating values. CBOR is the preferred encoding format.¶

The CDDL was derived from the more specific structure developed for [drip-auth]. As such the structures found in [drip-auth], such as the UA Signed Evidence and the contents of DRIP Link (known as a Broadcast Endorsement), are a subset of the below definition in a strict binary form.¶

• Note: this section uses the term HHIT instead of DET as the Endorsements are designed to be generic and re-useable for other HHIT use-cases.¶

endorsement = 6.xxx(e-data: array)
e-data = [e-type, scope, ? $$evidence, $$endorser, $$signature]

e-type = uint .size(2)
scope = (vnb: time, vna: time, ? $$scope-ext)

$$endorser //= (hhit,)
$$endorser //= (hhit, eddsa25519-hi,)
$$endorser //= (eddsa25519-hi,)
hhit = #6.54(bstr .size(16))
eddsa25519-hi = bstr .size(32)

$$signature = (eddsa25519-sig,)
eddsa25519-sig = bstr .size(64)

Endorsement Type:

a 16-bit value used to hint at the content of the $$evidence group. Four special values (1 through 4) map to the SAM Type of the Authentication framing in [drip-auth], allowing the 16-bit value to be excluded from the Endorsement structure. See Section 11.2.2 for more details.¶

Scope & Scope Extensions:

The scope section is more formally "the scope of validity of the endorsement". The scope can come in various forms but MUST always have a "valid not before" (vnb) and "valid not after" (vna) timestamps. Other forms of the scope could for example be a 4-dimensional volume definition. This could be in raw latitude, longitude, altitude pairs or may be a URI pointing to scope information. Additional scope fields are out of scope for this document and should be defined for specific Endorsement structures if they are desired using the $$scope-ext socket group.¶

Evidence:

socket group containing a set claims. The content and order of claims is specified explicitly for each e-type.¶

Endorser:

socket group where the main identity information of the signer of the Endorsement is found. The identity can take many forms such as a handle to the identity (e.g. an HHIT), or can include more explicit data such as the public key (e.g. an HI). The content and ordering is specified explicitly for each e-type.¶

Signature:

socket group containing the signature data for the Endorsement. The content and ordering is specified explicitly for each e-type. Signatures MUST be generated using the preceding sections (except for e-type) in their binary forms (i.e. as a concatenated bytestring of values) rather than their CBOR encoding.¶

Appendix D specifies Endorsement structures for the UAS RID use-case.¶

10. X.509 Certificates

11. IANA Considerations

12. Security Considerations

13. Public Key Exposure

DETs are built upon asymmetric keypairs. As such the public key must be revealed to enable clients to perform signature verifications.¶

While unlikely the forging of a corresponding private key is possible if given enough time (and computational power). As such it is RECOMMENDED that the public key for any DET not be exposed in DNS (using the HIP RR) until it is required.¶

Optimally this requires the UAS somehow signal the DIME that a flight using a Specific Session ID is 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.¶

14. Contributors

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 foundations for the content and processes of this architecture and document. Bob Moskowitz is also instrumental in the PKIX work defined in this document with his parallel work in ICAO.¶

Appendix A. HHIT Resource Record

This appendix is normative.¶

The HHIT Resource Record is a metadata record for various bits of HHIT specific information that isn't available in the pre-existing HIP RR Type. It is encoded as a CBOR array.¶

rr = 6.xxx(rr_data: array)
rr_data= [hhit, type, status, abbreviation, endorsements]
hhit = #6.54(bstr .size(16))
type = uint .size(2)
status = uint .size(1)
abbreviation = tstr .size(15)
endorsements = [1* endorsement]  ; MUST be in e-type order

<domain> HHIT IN ( HHIT TYPE STATUS ABBREV [Endorsement(s)] )

Type:

This field is two octets with values defined in Section 11.2.3. It is envisioned that there may be many types of HHITs in use. In some cases it may be helpful to understand the HHITs role in the ecosystem like described in [drip-dki].¶

Status:

This field is a single byte with values defined in Section 11.2.4. A HHIT can go through various states during its life-cycle in the ecosystem. It is helpful for a querant to understand the current status as a further requirement for verification.¶

Abbreviation:

This field is meant to provide an abbreviation to the HID structure for display devices. The specific contents of this field are not defined here, but a recommendation/example can be found in Appendix B.¶

Endorsements:

This field is a list of CBOR encoded Endorsements in e-type order. It MUST included at least one Broadcast Endorsement (Appendix D.2). A special case for the Apex is that the Broadcast Endorsement is filled with its own DET and HI as evidence (i.e. a self-signed Broadcast Endorsement).¶

Appendix B. HID Abbreviation Recommendation

This appendix is informative.¶

On receiver devices a DET can be translated to a more human readable form such as: {RAA Abbreviation} {HDA Abbreviation} {Last 4 Characters of DET Hash}. An example of this would be US FAA FE23.¶

To support this DIMEs are recommended to have an abbreviation that could be used for this form. These abbreviations should be a maximum of six characters (for each section) in length. Spaces should not be used and be replaced with either underscores (_) or dashes (-).¶

The concatenation of {RAA Abbreviation} and {HDA Abbreviation} with a space between them can be what fills in the HID field of the HHIT RR in Appendix A.¶

For RAAs allocated in the ISO range Section 4.2.1, the RAA abbreviation should be set to the ISO 3166-1 country code (either Alpha-2 or Alpha-3). A common abbreviation for an RAAs four allocated RAA values are out of scope. Other documents such as [drip-dki] may have more specific recommendations or requirements.¶

If a DIME does not have an abbreviation or it can not be looked up then the receiver must use the uppercase 4-character hexadecimal encoding of the field it is missing when using this form.¶

Appendix C. DETs as Fully Qualified Domain Names

This appendix is informative.¶

• {hash}.{oga_id}.{hda}.{raa}.{prefix}.{apex}.¶

When building a DET FQDN it MUST must be built using the exploded (all padding present) form of the IPv6 address.¶

Apex: .example.com
DET: 2001:0030:0280:1405:c465:1542:a33f:dc26
ID: c4651542a33fdc26
OGA: 05
HID: 0028014
HDA: 0014
RAA: 000a
Prefix: 2001003
FQDN: c4651542a33fdc26.05.0014.000a.2001003.example.com

Appendix D. DRIP Endorsements for UAS

This appendix is normative.¶

; e-type=0, Self Endorsement
$$evidence //= (eddsa25519-hi,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                              VNB                              |
+---------------+---------------+---------------+---------------+
|                              VNA                              |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                              HI                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                             HHIT                              |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                           Signature                           |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

TODO

; e-type=1, SAM Type=1, Broadcast Endorsement
$$evidence //= (hhit, eddsa25519-hi,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                              VNB                              |
+---------------+---------------+---------------+---------------+
|                              VNA                              |
+---------------+---------------+---------------+---------------+
|                                                               |
|                            HHIT of                            |
|                             Child                             |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                             HI of                             |
|                             Child                             |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                            HHIT of                            |
|                            Parent                             |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                           Signature                           |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

TODO

; e-type=2, SAM Type=2, Wrapper Endorsement
$$evidence //= (*4 astm-message,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
astm-message = bstr .size(25)

TODO

TODO

; e-type=3, SAM Type=3, Manifest Endorsement
$$evidence //= (3*11 manifest-hash,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
manifest-hash = bstr .size(8)

TODO

TODO

; e-type=4, SAM Type=4, Frame Endorsement
$$evidence //= (frame-type, frame-data,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
frame-type = uint .size(1)
frame-data = bstr .size(1..111)

TODO

TODO

Appendix E. DNS Examples

This appendix is informative.¶

@ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN DET
( 2001003fff800005ba8af5252a35030e 0 1 "TEST DRIP" "" ... )
e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN HIP
( 5 2001003fff800005ba8af5252a35030e ... )
e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN URI
( https://example.com/operator/* )

@ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN DET
( 2001003fff800005b6ce935b616306d4 0 1 "TEST DRIP" "" ... )
4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN HIP
( 5 2001003fff800005b6ce935b616306d4 ... )
4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN URI
( https://example.com/session/* )

RAA:
@ORIGIN 8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
0.0.0 IN NS 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa

HDA:
@ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN DET
( 2001003fff8000054e486394a60bb669 0 1 "TEST DRIP" "" ... )
9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN HIP
( 5 2001003fff8000054e486394a60bb669 ... )
9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN URI
( https://example.com/dime/* )

Authors' Addresses