The ipn.arpa Zone and IPN DNS Operations

3.1. Discovery Model

The ipn.arpa zone is an infrastructure namespace derived from IPN identifiers. Discovery is keyed on the FQNN of the destination node.¶

Before constructing a DNS name, a BP Agent MUST parse and interpret the destination ipn URI or ipn EID according to [RFC9758], yielding numeric values for its Allocator Identifier, Node Number, and Service Number. This includes the text syntax rules of Section 4 of [RFC9758] and the CBOR decoding rules of Section 6.2 of [RFC9758]. In particular, an Allocator Identifier omitted from the text representation means zero, the Default Allocator (Section 3.2.2 of [RFC9758]). An omitted Allocator Identifier does not cause the allocator label to be omitted from the DNS name.¶

For Allocator Identifier A and Node Number N, the DNS base name MUST be:¶

N.A.ipn.arpa.

Each of N and A MUST be represented as a single label containing its unsigned decimal value, using ASCII digits without leading zeroes. The value zero is represented by the single digit "0". The labels are not padded to a fixed width and are not split into individual digits.¶

The Service Number does not participate in construction. All ipn URIs that share an FQNN map to the same DNS base name.¶

Because the DNS base name is constructed from the parsed numeric components rather than from the text of the URI, equivalent representations of the same FQNN produce the same DNS base name. For example, ipn:16384.345 and ipn:0.16384.345 both identify the FQNN (0,16384). Likewise, equivalent two-element and three-element CBOR encodings of the same ipn EID (Section 6.4 of [RFC9758]) produce the same DNS base name.¶

Names for Allocator Identifier zero, such as 16384.0.ipn.arpa., and for Experimental Use Allocator Identifiers are constructed by the same rule. This includes Private Use Node Numbers, which exist only under Allocator Identifier zero (Section 3.4.3 of [RFC9758]). Such names are not published in the public hierarchy (Section 7.1.3) but can be used in locally served instances (Section 4.3).¶

This document defines TCPCLv4 [TCPCL] discovery using SRV records at the CL-specific query name:¶

_dtn-bundle._tcp.N.A.ipn.arpa.

Here, N.A.ipn.arpa. is the DNS base name constructed by the rules above. SRV processing follows [RFC2782], including priority, weight, port, and target processing. DNS discovery is optional; retention and refresh of discovery results follow Section 4.2.¶

For example, the TCPCLv4 query name for the FQNN (978879,2) is:¶

_dtn-bundle._tcp.2.978879.ipn.arpa.

No preliminary PTR query is required, and this discovery procedure requires no PTR records.¶

This differs from the conventional use of in-addr.arpa and ip6.arpa, in which a PTR record maps an address to a hostname that is then used for further lookups. The discovery procedure in this document publishes service records directly beneath the DNS base name; no IPN-to-hostname mapping step is involved.¶

The Null ipn URI (Section 3.1 of [RFC9758]) and LocalNode ipn URIs (Section 3.4.2 of [RFC9758]) are recognized after the interpretation described above. For example, an ipn URI with a zero Allocator Identifier, a zero Node Number, and a non-zero Service Number is treated as the Null ipn URI (Section 3.4.1 of [RFC9758]), and ipn:!.7 is a LocalNode ipn URI. Neither identifies a remote destination for this procedure: the Null endpoint has no members, and a bundle destined for a LocalNode ipn EID is not allowed to leave the local node (Section 5.4 of [RFC9758]). A BP Agent MUST NOT perform DNS discovery for the Null ipn URI or for a LocalNode ipn URI. In addition, Section 5.4 of [RFC9758] prohibits publishing LocalNode ipn EIDs in any node identification directory, such as a DNS registration.¶

These cases are identified by the complete FQNN: (0,0) for the Null ipn URI and (0,4294967295) for LocalNode ipn URIs. This document does not reserve Node Number 0 or Node Number 4294967295 under any other Allocator Identifier. For example, the FQNNs (978879,0) and (978879,4294967295) are processed like any other FQNN.¶

3.2. Examples

The examples in this section describe one deployment: a fictional space agency that offers a shared public ingress service for its destinations. Other operators can use different arrangements, such as a distinct relay for each node or direct publication of a node's own endpoints; nothing in this document requires the architecture shown here.¶

The agency administers Allocator Identifier 978879. This identifier, and those used in Section 4.4, are from the range reserved for examples (Section 9.1 of [RFC9758]). The zone excerpts illustrate the mechanism; they do not request public provisioning of these identifiers (see Section 7.2). Its example destinations are:¶

The destination names are descriptive labels chosen independently of the Node Numbers.¶

All three destinations use the same public ingress service, provided by two relay BP Agents, relay-a.space-agency.example. and relay-b.space-agency.example.. The relays are separate BP nodes with their own Node IDs, and each has onward routes to all three destinations. The agency also operates cislunar and deep-space ground facilities; onward forwarding from the relays uses agency-managed routes and contact arrangements, which are not shown.¶

Example A and Example B are alternative configurations of the allocator's zone. The agency publishes one or the other, not both: a CNAME and an SRV RRset must not coexist at the same owner name (see Section 3.3). All records shown are zone excerpts; routine zone infrastructure (such as SOA and NS records) and DNSSEC records are omitted.¶

Both configurations use the following address records for the relays:¶

$ORIGIN space-agency.example.
$TTL 3600

relay-a IN A    192.0.2.10
relay-a IN AAAA 2001:db8::10
relay-b IN A    192.0.2.11
relay-b IN AAAA 2001:db8::11

$ORIGIN 978879.ipn.arpa.
$TTL 3600

_dtn-bundle._tcp.1 IN SRV 10 1 4556 relay-a.space-agency.example.
_dtn-bundle._tcp.1 IN SRV 10 1 4556 relay-b.space-agency.example.

_dtn-bundle._tcp.2 IN SRV 10 1 4556 relay-a.space-agency.example.
_dtn-bundle._tcp.2 IN SRV 10 1 4556 relay-b.space-agency.example.

_dtn-bundle._tcp.3 IN SRV 10 1 4556 relay-a.space-agency.example.
_dtn-bundle._tcp.3 IN SRV 10 1 4556 relay-b.space-agency.example.

$ORIGIN 978879.ipn.arpa.
$TTL 3600

_dtn-bundle._tcp.1 IN CNAME (
    _dtn-bundle._tcp.ingress.space-agency.example. )
_dtn-bundle._tcp.2 IN CNAME (
    _dtn-bundle._tcp.ingress.space-agency.example. )
_dtn-bundle._tcp.3 IN CNAME (
    _dtn-bundle._tcp.ingress.space-agency.example. )

$ORIGIN space-agency.example.
$TTL 3600

_dtn-bundle._tcp.ingress IN SRV (
    10 1 4556 relay-a.space-agency.example. )
_dtn-bundle._tcp.ingress IN SRV (
    10 1 4556 relay-b.space-agency.example. )

3.3. DNS Constraints

The following DNS behaviors apply to the configurations above:¶

• A CNAME aliases only its own owner name (Section 3.6.2 of [RFC1034]). To redirect the service lookup, the CNAME is placed at the complete service owner name (e.g., _dtn-bundle._tcp.2.978879.ipn.arpa.). A CNAME at the bare node name (e.g., 2.978879.ipn.arpa.) does not alias its descendants and so does not redirect the service lookup.¶

• A CNAME record and an SRV RRset cannot coexist at the same owner name (Section 3.6.2 of [RFC1034]).¶

• The Target of the SRV record eventually obtained, unless it is ".", must have one or more address records and must not be an alias ([RFC2782]; see also Section 5.1 of [RFC6672]).¶

3.4. Other Convergence Layers

For other CLs, the applicable discovery specification defines service query names and record types (e.g., SRV or SVCB records) relative to the DNS base name. Appropriately capable BP Agents query for those records using the same DNS base name. The TCPCLv4 SRV discovery binding is specified in Section 3.1; [TCPCL] specifies TCPCLv4 and registers the "dtn-bundle" service name and port 4556, but does not itself define this DNS discovery procedure.¶

4.1. Discovery Results and Failures

Discovery succeeds when a BP Agent obtains usable connection information under the applicable discovery binding: the TCPCLv4 binding in Section 3.1, or the specification applicable to another CL (Section 3.4). The binding determines the query names, record types, processing rules, and required connection parameters. A syntactically valid DNS answer does not necessarily contain a binding that the requesting implementation can use; candidate selection and compatibility checks follow the applicable record-type and CL specifications. This document does not require a BP Agent to query for every CL it supports, and it does not prescribe an order in which to try different CLs.¶

Record-type processing is defined by the specification for that record type. For SRV-based discovery, [RFC2782] governs priority, weight, and target processing, including a Target of ".", which indicates that the specified service is not available at that domain. For SVCB-based discovery, [RFC9460] and the applicable CL specification govern AliasMode and ServiceMode, parameter compatibility, endpoint selection, and fallback. SRV rules do not carry over to other record types; for example, a ServiceMode SVCB TargetName of "." denotes the record's owner name (Section 2.5.2 of [RFC9460]), not unavailability.¶

Unsuccessful lookups are distinguished using existing DNS terminology [RFC2308]:¶

NXDOMAIN:

The name at which resolution terminated, possibly the target of an alias, does not exist.¶

NODATA:

The name exists, but no records of the requested type exist.¶

SERVFAIL, timeout, and other resolution failures:

The lookup did not complete successfully. This does not establish that the service is absent.¶

These outcomes concern only the DNS discovery attempt. They do not establish that the destination FQNN is invalid or that it is unreachable by other means, and the absence of one CL's discovery records does not establish the absence of another CL's service.¶

An unsuccessful DNS discovery attempt does not by itself invalidate independently obtained forwarding information, such as configured routes or information from other discovery or routing mechanisms, and does not require deletion of a Bundle. Those mechanisms remain governed by the BP Agent's existing policies; this document does not define retry timers or route precedence. Caching is discussed in Section 4.2 and DNSSEC result handling in Section 5.3.1.¶

4.2. Caching and Operation During Disruption

Ordinary positive and negative DNS caching follow existing DNS specifications, including [RFC2308] for negative answers.¶

A discovery result retained by a BP Agent depends on the remaining lifetimes of the records used to obtain it, which can include aliases, SRV or SVCB records, and address records. These records need not have identical TTLs. Copying a result into forwarding information should not silently make it permanent configuration. This document does not require a particular cache representation or a new lookup before each Bundle transfer.¶

DNS TTL expiry does not by itself require closing an established CL session or deleting a Bundle. Refreshing discovery information affects subsequent connection attempts; session management remains governed by the applicable CL specification.¶

When refresh is unavailable, a deployment can use independently configured forwarding information or other routing mechanisms. Continued use of expired discovery information is governed by explicit operational policy, which accounts for possible changes to endpoints, aliases, or administrative control. [RFC8767] describes how resolvers can serve stale DNS data; it does not specify retention of forwarding information by a BP Agent.¶

TTL expiry is distinct from signature expiry. An earlier successful validation does not establish indefinite validity: validation checks the RRSIG validity period (Section 5.3.1 of [RFC4035]), and the TTL of authenticated data is limited by the signature expiration time (Section 5.3.3 of [RFC4035]). Validation failures are handled as described in Section 5.3.1.¶

4.3. Locally Served Namespaces

Deployments that use locally served instances of 0.ipn.arpa or of Experimental Use allocator subtrees (see Section 7.1.3) configure them explicitly through ordinary DNS administration: loading the zones, selecting authoritative servers, and configuring resolvers to forward queries for those names. This document does not request automatic resolver behavior or any addition to the IANA "Locally-Served DNS Zones" registry [RFC6303].¶

The signed public ipn.arpa namespace does not supply a chain of trust to independently administered local data. Where the public namespace contains no corresponding name, ordinary DNSSEC processing can authenticate that name's nonexistence in the public namespace, and a validator relying only on that public chain cannot authenticate a conflicting local answer. A signed local zone can instead be authenticated using an appropriately configured local trust anchor (Section 7 of [RFC6303]); Section 5.10 of [RFC6840] describes how a validator chooses among nested trust anchors. That configuration is needed wherever validation occurs: in a validating resolver relied upon as described in Section 5.3.1, or in a BP Agent that validates independently.¶

A deployment can instead accept unsigned local data under explicit local policy. Such acceptance is a policy decision; it is not successful DNSSEC validation. In either case, local resolution and trust settings are best scoped to the relevant subtrees, without disabling validation for ipn.arpa as a whole.¶

It is recommended that resolution be configured so that queries for these locally served names remain within the intended administrative or experimental scope, including when local resolution fails. Public resolution cannot provide the intended local discovery data, and queries that reach the public DNS can disclose the queried identifiers (see Section 5.5); [RFC6303] describes the motivation for containing such queries. This guidance does not require Internet resolvers in general to recognize these namespaces.¶

4.4. Managing Allocator Ranges

An Allocator may hold a range of Allocator Identifiers (Section 3.2.1 of [RFC9758]). Numeric allocation ranges do not automatically correspond to DNS subtrees. With the decimal-label layout specified in Section 3.1, each Allocator Identifier A has its own name, A.ipn.arpa., directly beneath ipn.arpa. The identifiers in a range are siblings, not descendants of a common name.¶

An operator responsible for several Allocator Identifiers can serve an individually delegated zone for each one. Alternatively, DNAME records [RFC6672] can redirect each allocator subtree into a common operator-managed zone.¶

The following example uses Allocator Identifiers 974848 and 974849 and assumes that the agency of Section 3.2 also administers them. The records are zone excerpts; routine zone infrastructure and DNSSEC records are omitted. The address records for the relays are those in Figure 1.¶

$ORIGIN ipn.arpa.
$TTL 3600

974848 IN DNAME 974848.allocators.space-agency.example.
974849 IN DNAME 974849.allocators.space-agency.example.

$ORIGIN 974848.allocators.space-agency.example.
$TTL 3600

_dtn-bundle._tcp.2 IN SRV 10 1 4556 relay-a.space-agency.example.
_dtn-bundle._tcp.2 IN SRV 10 1 4556 relay-b.space-agency.example.

$ORIGIN 974849.allocators.space-agency.example.

_dtn-bundle._tcp.2 IN SRV 10 1 4556 relay-a.space-agency.example.
_dtn-bundle._tcp.2 IN SRV 10 1 4556 relay-b.space-agency.example.

A BP Agent discovering TCPCLv4 service for ipn:974848.2.345 constructs its initial query from the standard DNS base name, exactly as in Section 3.1, and queries for SRV records at:¶

_dtn-bundle._tcp.2.974848.ipn.arpa.

The DNAME at 974848.ipn.arpa. redirects this query to:¶

_dtn-bundle._tcp.2.974848.allocators.space-agency.example.

There the BP Agent finds the same relay-a/relay-b SRV pair as in Section 3.2. Ordinary DNS processing performs the redirection (Section 3 of [RFC6672]). The BP Agent does not construct any name in the agency's zone itself.¶

The example retains the Allocator Identifier in each target subtree. As a result, node 2 under Allocator 974848 (2.974848.allocators.space-agency.example.) remains distinct from node 2 under Allocator 974849 (2.974849.allocators.space-agency.example.), even though their service records select the same relay hosts. Both FQNNs are also distinct from (978879,2), the mars-orbiter; they identify other nodes. Pointing both DNAMEs at the same target would merge their corresponding lookup names: queries for the FQNNs (974848,2) and (974849,2) would then reach the same records. Distinct target subtrees need to be preserved whenever the allocator namespaces must remain distinct. Retaining the decimal allocator label in the target is a convenient convention, not a DNS requirement.¶

One agency-managed zone can contain all of these subtrees. One DNAME is still required in ipn.arpa for each redirected Allocator Identifier. The technique reduces the number of separately administered child zones, not the number of allocator entries in the parent.¶

The following constraints apply:¶

• A DNAME redirects the descendants of its owner name, not the owner name itself (Section 2.3 of [RFC6672]).¶

• Records cannot be published beneath the DNAME owner in the source zone (Section 2.4 of [RFC6672]). Once 974848.ipn.arpa. owns a DNAME, data beneath the allocator name is published in the target subtree.¶

• DNAME redirection is distinct from NS delegation. An NS delegation creates a zone cut and transfers authority for the child zone to its own servers. A DNAME instead rewrites names beneath its owner into the target namespace. A parent-side DNAME cannot coexist with a delegation NS RRset at the same owner name (Section 2.3 of [RFC6672]). An allocator zone that is already delegated can instead publish a DNAME at its own apex, keeping its SOA and NS records. That arrangement retains the separate child-zone administration.¶

See [RFC6672] for processing details and DNSSEC considerations (Section 5.3 of [RFC6672]).¶

Locally served instances of 0.ipn.arpa and of Experimental Use allocator subtrees (Section 4.3) can use DNAMEs in the same way, for example at N.0.ipn.arpa., subject to authorization by the administrator of that namespace.¶

$ORIGIN ipn.arpa.
$TTL 3600

$GENERATE 974848-974849 $ DNAME $.allocators.space-agency.example.

5.1. Discovery Yields Candidates

The discovery procedure in Section 3 identifies candidate convergence-layer endpoints through which a destination node might be reached. A candidate can be the destination node itself or a relay that accepts Bundles for onward forwarding, as in Section 3.2.3. Successful discovery does not guarantee that the destination is currently reachable, that a candidate will accept a session or a Bundle, or that the Bundle will eventually be delivered.¶

5.2. Discovery, Peer Authentication, and Forwarding Policy

Using DNS-derived forwarding information involves two distinct authentication questions: whether the DNS data used in discovery is authentic (see Section 5.3), and whether the convergence-layer peer to which a session is established is the entity it claims to be (see Section 5.4). Authenticating one does not authenticate the other.¶

A BP Agent's configured forwarding and security policies govern the use of DNS-derived forwarding information. Those policies may distinguish among sources of forwarding information, for example between configured routes and discovery results, or between authenticated and unauthenticated discovery results. A BP Agent's configured forwarding policy may permit automatic use of authenticated discovery mappings, subject to the security requirements of the applicable convergence layer.¶

5.3. DNSSEC

Forged discovery information can redirect connection attempts, and therefore bundle transfers, to endpoints chosen by an attacker. DNSSEC [RFC9364] provides data origin authentication and integrity for DNS data. It does not guarantee that the advertised service is available; ENUM makes similar observations (Section 7.1 of [RFC6116]).¶

Operators publishing discovery data for this mechanism in the public DNS SHOULD provide DNSSEC authentication of that data, including the necessary chain of trust. This recommendation applies to all DNS records relied upon in discovery, including records published outside ipn.arpa:¶

• aliases and redirections, such as the CNAME and DNAME records in Section 3.3 and Section 4.4, or SVCB AliasMode records;¶

• service records and other records carrying connection parameters, such as SRV records or SVCB ServiceMode records; and¶

• address records for the resulting targets.¶

The ipn.arpa zone itself is signed (see Section 7.1), and delegated allocator zones can be linked into its chain of trust with DS records (see Section 7.2.4). Signing ipn.arpa alone does not authenticate records in delegated zones or external target namespaces; each record used in discovery has its own security status.¶

Validation of these records follows standard DNSSEC processing. For example, a CNAME synthesized from a validated DNAME does not require its own signature (Section 3.1 of [RFC6672] and Section 5.3.1 of [RFC6672]).¶

5.4. Convergence-Layer Peer Identity

The applicable convergence-layer specification and configured security policy govern authentication of the convergence-layer peer. For TCPCLv4, session security, including certificate-based identification of the peer, is specified in Section 4.4 of [TCPCL], and the handling of the peer's Node ID is specified in Section 4.6 of [TCPCL]. This document does not modify those procedures.¶

Discovery names are derived from the destination FQNN, whereas the selected session peer can be the destination node or a relay. In Section 3.2, the peer is one of the relays, each a separate BP node with its own Node ID; other deployments publish a destination node's own endpoints. A discovery name can also serve as the effective connection target, for example when a ServiceMode SVCB record has a TargetName of "." (Section 2.5.2 of [RFC9460]). In every case, the Bundle's destination EID is unchanged, and a BP Agent distinguishes it from the Node ID that the peer presents. Discovery does not by itself supply an expected peer Node ID; Section 4.6 of [TCPCL] describes the handling of a peer Node ID that differs from the one intended, and of a peer Node ID that is not authenticated.¶

5.5. Privacy

Discovery records published in the public DNS can reveal destination identifiers, their association with services and relays, and connection endpoints. Queries for those records can reveal to resolvers and other observers which destinations a BP Agent is trying to reach, and when. DNSSEC provides authentication and integrity, not confidentiality. [RFC9076] describes DNS privacy threats and mitigations, such as resolver selection and encrypted DNS transports. Operators can limit what published records disclose (as in Section 3.2.3) and keep queries for locally served names within their intended scope (Section 4.3).¶

5.6. Resource Consumption

Bundles addressed to many distinct destination FQNNs, whether malicious or not, can induce corresponding DNS queries, retained discovery state, and connection attempts. Implementations SHOULD bound outstanding discovery work, retained discovery state, and connection attempts, using existing mechanisms such as resolver limits, queueing, and connection management.¶

7.1. Creation of ipn.arpa

Following approval by the IAB in accordance with Section 3 of [RFC3172], IANA is requested to add "ipn.arpa" to the ".arpa" domain. Names in ipn.arpa are constructed as specified in Section 3.1.¶

IANA is requested to arrange the ongoing administration of ipn.arpa, consistent with the arrangements approved by the IAB under [RFC3172]. Administration includes processing the requests described in Section 7.2. It is distinct from operation of the authoritative DNS servers for ipn.arpa; this document does not require that IANA itself operate those servers. In this document, the "ipn.arpa operator" is the entity that performs the DNS provisioning and operational functions for the ipn.arpa zone under those arrangements.¶

The ipn.arpa operator MUST sign the public ipn.arpa zone using DNSSEC and maintain a chain of trust through the arpa zone. This requirement applies to the ipn.arpa zone itself. Recommendations concerning discovery data in delegated allocator zones and in other namespaces are addressed to the operators of those zones and are given in Section 5.3.¶

The following subsections restrict publication of discovery data for two sets of names in the public ipn.arpa hierarchy. The restrictions are established by this document, not by [RFC9758]; they concern only the DNS discovery mechanism specified here and do not alter any allocation or its Bundle Protocol semantics.¶

7.2. Allocator DNS Provisioning

IANA and the ipn.arpa operator are requested to maintain a procedure that links requests for DNS provisioning at "A.ipn.arpa" to the entry for Allocator Identifier A in the "'ipn' Scheme URI Allocator Identifiers" registry (Section 9.1 of [RFC9758]). The storage format, the request interface, and the presentation of provisioning information are left to IANA and the ipn.arpa operator.¶

DNS provisioning is optional. It can be requested when an Allocator Identifier is assigned or at any later time. Having a DNS entry is not a condition for the validity or use of an allocator assignment.¶

Eligible Allocator Identifiers are those assigned for operational use in the "'ipn' Scheme URI Allocator Identifiers" registry, subject to the exclusions in this document. Ordinary public provisioning is not requested for:¶

• Allocator Identifier zero (Section 7.1.1);¶

• Experimental Use Allocator Identifiers (Section 7.1.2);¶

• unassigned or reserved Allocator Identifiers; or¶

• Allocator Identifiers 974848 through 978943, reserved for documentation examples (Section 9.1 of [RFC9758]).¶

7.3. Request Validation and Allocation Review

The allocation procedures of Section 9.1 of [RFC9758], including Expert Review, continue to apply to numeric assignments of Allocator Identifiers (see also Section 7.2.1).¶

The ipn.arpa operator performs the applicable DNS technical checks on provisioning requests under its published operational procedures. IANA's technical requirements for delegations in the zones it manages [IANA-NS-REQS] are relevant background. DNAME provisioning is subject to the requirements of [RFC6672].¶

8.1. Normative References

[RFC1034]

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/rfc/rfc1034>.

[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/rfc/rfc2119>.

[RFC2782]

Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/rfc/rfc2782>.

[RFC3172]

Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <https://www.rfc-editor.org/rfc/rfc3172>.

[RFC4035]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/rfc/rfc4035>.

[RFC6672]

Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <https://www.rfc-editor.org/rfc/rfc6672>.

[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/rfc/rfc8174>.

[RFC9364]

Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, <https://www.rfc-editor.org/rfc/rfc9364>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

[RFC9758]

Taylor, R. and E. Birrane III, "Updates to the 'ipn' URI Scheme", RFC 9758, DOI 10.17487/RFC9758, May 2025, <https://www.rfc-editor.org/rfc/rfc9758>.

[TCPCL]

Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4", RFC 9174, DOI 10.17487/RFC9174, January 2022, <https://www.rfc-editor.org/rfc/rfc9174>.

8.2. Informative References

[BIND-ARM]

Internet Systems Consortium, "BIND 9 Administrator Reference Manual", <https://bind9.readthedocs.io/en/latest/chapter3.html>.

[IANA-NS-REQS]

IANA, "Technical requirements for authoritative name servers", <https://www.iana.org/help/nameserver-requirements>.

[RFC1918]

Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.

[RFC2308]

Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/rfc/rfc2308>.

[RFC6116]

Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, DOI 10.17487/RFC6116, March 2011, <https://www.rfc-editor.org/rfc/rfc6116>.

[RFC6303]

Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-editor.org/rfc/rfc6303>.

[RFC6840]

Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, <https://www.rfc-editor.org/rfc/rfc6840>.

[RFC7116]

Scott, K. and M. Blanchet, "Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries", RFC 7116, DOI 10.17487/RFC7116, February 2014, <https://www.rfc-editor.org/rfc/rfc7116>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8375]

Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, <https://www.rfc-editor.org/rfc/rfc8375>.

[RFC8767]

Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data to Improve DNS Resiliency", RFC 8767, DOI 10.17487/RFC8767, March 2020, <https://www.rfc-editor.org/rfc/rfc8767>.

[RFC9076]

Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076, DOI 10.17487/RFC9076, July 2021, <https://www.rfc-editor.org/rfc/rfc9076>.

[RFC9171]

Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.