The ipn.arpa Zone and IPN DNS Operations
draft-ek-dtn-ipn-arpa-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Erik Kline | ||
| Last updated | 2026-11-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ek-dtn-ipn-arpa-01
Delay/Disruption Tolerant Networking E. Kline
Internet-Draft Aalyria Technologies, LLC
Intended status: Standards Track 2 November 2026
Expires: 6 May 2027
The ipn.arpa Zone and IPN DNS Operations
draft-ek-dtn-ipn-arpa-01
Abstract
This document requests the creation of ipn.arpa, an infrastructure
DNS namespace for the IPN node identifiers used by the Bundle
Protocol (BP). Each Fully Qualified Node Number has a canonical name
of the form N.A.ipn.arpa, where A is the Allocator Identifier and N
is the Node Number. A BP Agent can query directly beneath that name
for records specified by a convergence-layer discovery binding, such
as SRV or SVCB records. The DNS records identify convergence-layer
endpoints advertised for reaching a destination, including relays.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://ekline.github.io/draft-dtn-ipn-arpa/draft-ek-dtn-ipn-
arpa.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ek-dtn-ipn-arpa/.
Discussion of this document takes place on the Delay/Disruption
Tolerant Networking mailing list (mailto:dtn@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/dtn/. Subscribe
at https://www.ietf.org/mailman/listinfo/dtn/.
Source for this draft and an issue tracker can be found at
https://github.com/ekline/draft-dtn-ipn-arpa.
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/.
Kline Expires 6 May 2027 [Page 1]
Internet-Draft IPN dot ARPA November 2026
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 6 May 2027.
Copyright Notice
Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Concept of Operations . . . . . . . . . . . . . . . . . . . . 4
3.1. Discovery Model . . . . . . . . . . . . . . . . . . . . . 5
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Example A: Service Records in the Allocator's Zone . 8
3.2.2. Example B: Service Lookup Redirected through a
CNAME . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Shared Ingress Behavior . . . . . . . . . . . . . . . 10
3.3. DNS Constraints . . . . . . . . . . . . . . . . . . . . . 10
3.4. Other Convergence Layers . . . . . . . . . . . . . . . . 11
4. Operational Considerations . . . . . . . . . . . . . . . . . 11
4.1. Discovery Results and Failures . . . . . . . . . . . . . 11
4.2. Caching and Operation During Disruption . . . . . . . . . 12
4.3. Locally Served Namespaces . . . . . . . . . . . . . . . . 13
4.4. Managing Allocator Ranges . . . . . . . . . . . . . . . . 14
4.4.1. Provisioning Tools . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Discovery Yields Candidates . . . . . . . . . . . . . . . 16
5.2. Discovery, Peer Authentication, and Forwarding Policy . . 17
5.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Validation by BP Agents . . . . . . . . . . . . . . . 18
5.4. Convergence-Layer Peer Identity . . . . . . . . . . . . . 18
5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.6. Resource Consumption . . . . . . . . . . . . . . . . . . 19
Kline Expires 6 May 2027 [Page 2]
Internet-Draft IPN dot ARPA November 2026
6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.1. Creation of ipn.arpa . . . . . . . . . . . . . . . . . . 20
7.1.1. Allocator Identifier Zero . . . . . . . . . . . . . . 20
7.1.2. Experimental Use Allocator Identifiers . . . . . . . 21
7.1.3. Scope of the Publication Restrictions . . . . . . . . 21
7.2. Allocator DNS Provisioning . . . . . . . . . . . . . . . 22
7.2.1. Request Authorization . . . . . . . . . . . . . . . . 22
7.2.2. Provisioning Alternatives . . . . . . . . . . . . . . 22
7.2.3. Maintenance . . . . . . . . . . . . . . . . . . . . . 23
7.2.4. DS Records for Delegated Allocator Zones . . . . . . 23
7.3. Request Validation and Allocation Review . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
The Bundle Protocol (BP) [RFC9171] supports communication in networks
subject to delay and disruption. The ipn URI scheme [RFC9758]
identifies BP nodes and services numerically. An Allocator,
identified by an Allocator Identifier assigned through an IANA
registry, assigns Node Numbers; together, the two form a Fully
Qualified Node Number (FQNN).
This document requests the creation of ipn.arpa, an infrastructure
namespace in which each FQNN has one canonical DNS name,
N.A.ipn.arpa. (Section 3.1). A BP Agent can optionally query
directly beneath that name for records defined by a convergence-layer
(CL) specification, such as SRV or SVCB records, to learn CL
connection information for a destination node. The advertised
endpoint can belong to the destination node itself or to a relay that
accepts Bundles for onward forwarding.
This mechanism supplies candidate next hops (Section 5.1). It is not
a BP routing protocol and does not perform contact planning; path
selection and forwarding decisions remain with the BP Agent and its
configured policy.
This document specifies public provisioning in ipn.arpa for eligible
Allocator Identifiers (Section 7.2) and excludes other identifiers,
including Allocator Identifier zero and Experimental Use identifiers,
from the public hierarchy (Section 7.1.3). Deployments can also use
explicitly configured locally served namespaces (Section 4.3).
Kline Expires 6 May 2027 [Page 3]
Internet-Draft IPN dot ARPA November 2026
2. Conventions and Definitions
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 uses the following terms as defined in [RFC9758]:
Allocator Identifier: A 32-bit unsigned integer identifying the
Allocator that assigned a Node Number (Section 3.2 of [RFC9758]).
Node Number: A 32-bit unsigned integer identifying a node in the
context of an Allocator (Section 3.3 of [RFC9758]).
Fully Qualified Node Number (FQNN): The combination of an Allocator
Identifier and a Node Number, which uniquely identifies a node
(Section 3.3.1 of [RFC9758]). As in [RFC9758], an FQNN is written
as (Allocator Identifier, Node Number); for example, (978879,2).
Service Number: An unsigned integer identifying a service on a node
(Section 3.5 of [RFC9758]).
ipn URI: A URI using the 'ipn' URI scheme. An ipn URI comprises an
Allocator Identifier, a Node Number, and a Service Number; that
is, an FQNN plus a Service Number (Section 3 of [RFC9758]). An
ipn URI used as a Bundle Protocol Endpoint Identifier (EID) is
termed an "ipn EID" (Section 5 of [RFC9758]).
This document defines the following terms:
DNS base name: The DNS name beneath ipn.arpa that represents an
FQNN, constructed as specified in Section 3.1.
CL-specific query name: A DNS name, defined relative to a DNS base
name by this document or the discovery specification applicable to
another CL, at which a BP Agent queries for the records needed to
reach the node using that CL. The TCPCLv4 query name prepends
_dtn-bundle._tcp to the DNS base name (Section 3.1).
3. Concept of Operations
The Forwarding Information Base (FIB) of a BP Agent may be populated
from a variety of sources. Typically, explicit (manual)
configuration is given to associate BP destination endpoints with the
Convergence Layer parameters required to establish communication with
a responsible receiving BP Agent.
Kline Expires 6 May 2027 [Page 4]
Internet-Draft IPN dot ARPA November 2026
A BP Agent may also dynamically create a FIB entry by querying for
DNS Resource Records as described in this section.
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.
+==================+====================+
| ipn URI | DNS base name |
+==================+====================+
| ipn:978879.2.345 | 2.978879.ipn.arpa. |
+------------------+--------------------+
| ipn:978879.2.0 | 2.978879.ipn.arpa. |
+------------------+--------------------+
| ipn:16384.345 | 16384.0.ipn.arpa. |
+------------------+--------------------+
| ipn:0.16384.345 | 16384.0.ipn.arpa. |
+------------------+--------------------+
Table 1: Example DNS Base Names
Kline Expires 6 May 2027 [Page 5]
Internet-Draft IPN dot ARPA November 2026
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
Kline Expires 6 May 2027 [Page 6]
Internet-Draft IPN dot ARPA November 2026
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:
+============+===========================+====================+
| FQNN | Destination | DNS base name |
+============+===========================+====================+
| (978879,1) | mission operations center | 1.978879.ipn.arpa. |
+------------+---------------------------+--------------------+
| (978879,2) | mars-orbiter | 2.978879.ipn.arpa. |
+------------+---------------------------+--------------------+
| (978879,3) | lunar-lander | 3.978879.ipn.arpa. |
+------------+---------------------------+--------------------+
Table 2: Example Destinations
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.
Kline Expires 6 May 2027 [Page 7]
Internet-Draft IPN dot ARPA November 2026
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
Figure 1: Relay Address Records
3.2.1. Example A: Service Records in the Allocator's Zone
In this configuration, the SRV records for each destination are
published directly in the allocator's zone.
$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.
A BP Agent that has a Bundle destined for ipn:978879.2.345, and that
uses TCPCLv4 [TCPCL]:
1. constructs the query name _dtn-bundle._tcp.2.978879.ipn.arpa.
from Allocator Identifier 978879 and Node Number 2 of the
destination;
2. queries for SRV records at that name, receiving two candidate
relay endpoints, relay-a.space-agency.example. and relay-b.space-
agency.example., both on port 4556 with priority 10 and weight 1;
Kline Expires 6 May 2027 [Page 8]
Internet-Draft IPN dot ARPA November 2026
3. orders the candidates as specified in [RFC2782]: because both
records have the same priority and weight, either relay can be
selected first;
4. queries for A and AAAA records at the selected target; for relay-
a.space-agency.example., it receives 192.0.2.10 and 2001:db8::10;
and
5. attempts a TCPCLv4 connection to [2001:db8::10]:4556 or
192.0.2.10:4556. If that relay cannot be reached, the BP Agent
can try the other candidate, relay-b.space-agency.example.
([2001:db8::11]:4556 or 192.0.2.11:4556). If a session is
established with a peer acceptable under the BP Agent's policy
(Section 5.2), it transfers the Bundle.
3.2.2. Example B: Service Lookup Redirected through a CNAME
In this configuration, the allocator's zone contains, instead of
Example A's SRV records, a CNAME for each destination that redirects
the service lookup to a single shared name in the agency's zone:
$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. )
The agency publishes the shared service in its own zone:
$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. )
Kline Expires 6 May 2027 [Page 9]
Internet-Draft IPN dot ARPA November 2026
The BP Agent starts with the same query as in Example A: it queries
for SRV records at _dtn-bundle._tcp.2.978879.ipn.arpa.. Ordinary DNS
resolution follows the CNAME at that name to _dtn-
bundle._tcp.ingress.space-agency.example. and returns the SRV RRset
found there, which contains the same two candidate relay endpoints as
in Example A. There is no separate preliminary CNAME query. Relay
selection, address resolution, and establishment of the TCPCLv4
connection then proceed as in Example A.
With this configuration, the agency maintains the common relay
selection in one SRV RRset. The allocator's zone holds only the
aliases, and the set of relays can be changed in space-
agency.example. without changes to the allocator's zone.
3.2.3. Shared Ingress Behavior
The following points apply to both configurations:
* Equal SRV priorities and weights express equal preference among
the relays; selection follows the procedure of [RFC2782]. They do
not guarantee equal bundle volume, because a session can carry any
number of Bundles, and they do not indicate current server load.
* Multiple destination FQNNs can share the same discovery result.
Queries for (978879,1), (978879,2), and (978879,3) all yield the
same two relays, but the destinations remain distinct, and each
Bundle retains its destination EID; for example, a Bundle for the
mars-orbiter is still destined for ipn:978879.2.345 when it is
transferred to a relay. Each relay is a session peer with its own
Node ID (see Section 5.4).
* After accepting a Bundle, a relay forwards it using the agency's
configured onward routes and contact arrangements (see also
Section 5.1).
* The example uses a single public DNS view. The agency's internal
forwarding arrangements are configured in its BP Agents rather
than in DNS, so they require no internal DNS overrides.
* The public records expose the advertised FQNNs, their association
with the ingress service, and the relay addresses, but not the
agency's ground facilities or contact arrangements (see
Section 5.5).
3.3. DNS Constraints
The following DNS behaviors apply to the configurations above:
Kline Expires 6 May 2027 [Page 10]
Internet-Draft IPN dot ARPA November 2026
* 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. Operational Considerations
Deployments for which DNS does not meet reliability or performance
requirements, particularly during disruption, can obtain forwarding
information by other means.
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.
Kline Expires 6 May 2027 [Page 11]
Internet-Draft IPN dot ARPA November 2026
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.
Kline Expires 6 May 2027 [Page 12]
Internet-Draft IPN dot ARPA November 2026
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.
Kline Expires 6 May 2027 [Page 13]
Internet-Draft IPN dot ARPA November 2026
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.
Kline Expires 6 May 2027 [Page 14]
Internet-Draft IPN dot ARPA November 2026
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
Kline Expires 6 May 2027 [Page 15]
Internet-Draft IPN dot ARPA November 2026
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.
4.4.1. Provisioning Tools
Some DNS implementations provide implementation-specific facilities,
such as the $GENERATE directive of BIND [BIND-ARM], as conveniences
for producing repetitive records. For example, the two parent-side
DNAME records above can be expressed in BIND syntax as:
$ORIGIN ipn.arpa.
$TTL 3600
$GENERATE 974848-974849 $ DNAME $.allocators.space-agency.example.
Such a directive expands into ordinary records in the zone. It
introduces no numeric-range matching in DNS, and resolvers need no
support for it. Similar tooling can generate NS records or other
repetitive data. Use of these facilities is optional.
5. Security Considerations
This section describes the trust model for forwarding information
derived from DNS and the use of DNSSEC with this mechanism.
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.
Kline Expires 6 May 2027 [Page 16]
Internet-Draft IPN dot ARPA November 2026
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.
Kline Expires 6 May 2027 [Page 17]
Internet-Draft IPN dot ARPA November 2026
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.3.1. Validation by BP Agents
BP Agents using public DNS discovery SHOULD use DNSSEC validation,
either locally or through a trusted validating resolver. When
relying on validation performed by another resolver, the resolver and
the channel used to obtain its results need to satisfy the trust
requirements of Section 4.9.3 of [RFC4035].
DNSSEC distinguishes data that is secure, insecure, bogus, or
indeterminate (Section 4.3 of [RFC4035]). Insecure data lies in a
part of the namespace with no chain of trust, for example a target
zone that is not signed. Bogus data fails validation where a chain
of trust is expected, which can indicate an attack or a
misconfiguration. An application can also receive results whose
security status is unknown to it, for example from a resolver that
does not convey validation results. The absence of an authentication
indication does not by itself establish which of these cases applies.
This document does not impose a universal policy of accepting only
secure results. Acceptance of insecure results, and of results whose
security status is unknown to the application, is subject to the BP
Agent's configured policy.
A known validation failure is a failure of the affected discovery
path (see Section 4.1). It should not lead to automatic acceptance
of the same data without validation, for example by repeating the
query through a non-validating path. This does not preclude
retrieving DNSSEC data in order to validate it independently.
Validation of locally served namespaces is discussed in Section 4.3.
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
Kline Expires 6 May 2027 [Page 18]
Internet-Draft IPN dot ARPA November 2026
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.
6. IAB Considerations
In accordance with the procedure in Section 3 of [RFC3172], the IAB
is requested to approve the zone "ipn.arpa" as an infrastructure
namespace derived from IPN identifiers. Names in this zone are
constructed from FQNNs (Section 3.1) and are usable for discovering
CL endpoints for reaching IPN nodes (Section 3).
This follows the precedent of e164.arpa [RFC6116], in which names are
derived from E.164 telephone numbers and queried directly for service
records (NAPTR).
7. IANA Considerations
Kline Expires 6 May 2027 [Page 19]
Internet-Draft IPN dot ARPA November 2026
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.1.1. Allocator Identifier Zero
"0.ipn.arpa" corresponds to Allocator Identifier zero, the Default
Allocator (Section 3.2.2 of [RFC9758]). Public DNS discovery for
FQNNs with Allocator Identifier zero is intentionally outside the
scope of this document. A populated "0.ipn.arpa" zone MUST NOT be
published in the public ipn.arpa hierarchy specified by this
document. A "0.ipn.arpa" zone MAY exist in local DNS resolvers or
servers that serve it authoritatively as a locally served zone
[RFC6303], much as the IN-ADDR.ARPA zones for the private address
space of [RFC1918] are served locally (Section 4.1 of [RFC6303]).
This restriction covers every Node Number under Allocator Identifier
zero. That includes the Private Use Node Numbers 1 through 16383
(Section 3.4.3 of [RFC9758]) and the Node Numbers 2097152 through
268435455 reserved for Private or Experimental Use, a reservation
carried over from the "CBHE Node Numbers" registry (Section 3.2.1 of
[RFC7116]; Section 9.2 of [RFC9758]).
Kline Expires 6 May 2027 [Page 20]
Internet-Draft IPN dot ARPA November 2026
The restriction does not mean that Allocator Identifier zero has only
local significance: the Default Allocator's registry (Section 9.2 of
[RFC9758]) contains assigned Node Numbers as well as the Private Use
and Private or Experimental Use ranges. Supporting Allocator
Identifier zero in the public DNS would require additional
administration and delegation procedures for existing Default
Allocator Node Number allocations, together with a treatment of those
ranges and of locally served DNS data.
Note to the Working Group (to be removed before publication as an
RFC): Public DNS support for Allocator Identifier zero can be
reconsidered if the working group chooses to take on that scope.
7.1.2. Experimental Use Allocator Identifiers
Section 9.1 of [RFC9758] designates Allocator Identifiers 1073741824
through 2147483647 inclusive (0x40000000 through 0x7FFFFFFF) as
Experimental Use. Experimental Use values are not assigned to any
particular party (Section 4.2 of [RFC8126]), so independent
experiments may reuse the same identifier. A globally authoritative
mapping from such an identifier to discovery data would therefore be
inappropriate.
For each Experimental Use Allocator Identifier A, a populated subtree
beneath "A.ipn.arpa" MUST NOT be published in the public ipn.arpa
hierarchy. Names beneath "A.ipn.arpa" MAY be served by local DNS
resolvers or servers within the scope of an experiment.
7.1.3. Scope of the Publication Restrictions
The restrictions in Section 7.1.1 and Section 7.1.2 apply to every
means of placing discovery data for the affected FQNNs in the public
ipn.arpa hierarchy, including:
* discovery records, such as SRV, SVCB, or CNAME records, at or
beneath "0.ipn.arpa" or "A.ipn.arpa" for an Experimental Use
Allocator Identifier A;
* NS delegations of those names, or of names beneath them, to
servers that publish such discovery data; and
* CNAME or DNAME records at or beneath those names that redirect
discovery queries to data published elsewhere in the global DNS.
Names in these subtrees are absent from the public zone and receive
ordinary DNS negative answers, with normal DNSSEC processing. This
document introduces no special public delegation or negative-answer
mechanism for them. For comparison, home.arpa has an insecure public
Kline Expires 6 May 2027 [Page 21]
Internet-Draft IPN dot ARPA November 2026
delegation to accommodate validators without local trust
configuration (Section 6.2 of [RFC8375] and Section 7 of [RFC8375]);
this document does not request that arrangement. Operational
guidance for locally served instances is given in Section 4.3.
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.2.1. Request Authorization
Requests to create, update, or remove NS, DNAME, or DS records for an
eligible Allocator Identifier are subject to the same administrative
authority and requester-verification procedures that IANA applies to
changes to the corresponding entry in the "'ipn' Scheme URI Allocator
Identifiers" registry. DNS provisioning changes do not themselves
require a new review of the numeric allocation.
The same procedures apply to a request to convert an allocator name
between NS delegation and DNAME redirection.
7.2.2. Provisioning Alternatives
The parent-zone configuration at "A.ipn.arpa" is one of the
following:
Kline Expires 6 May 2027 [Page 22]
Internet-Draft IPN dot ARPA November 2026
NS delegation: The requester supplies the domain names of the
authoritative nameservers for the allocator zone, any addresses
needed for glue, and any DS records to be published (see
Section 7.2.4).
DNAME redirection: The requester supplies the fully qualified target
domain name. See Section 4.4 and [RFC6672].
These are alternatives. A DNAME at the allocator name in ipn.arpa
does not coexist with an NS delegation, or with the DS records of a
delegation, at that name (Section 2.3 of [RFC6672]).
A single request can cover multiple Allocator Identifiers within the
requester's allocation. It identifies each affected identifier and
the configuration that applies to it. Batch provisioning introduces
no numeric-range syntax in DNS; each affected allocator name has its
own parent-zone records (compare Section 4.4).
7.2.3. Maintenance
The same procedures support later updates and removal, including a
change of nameserver provider, a change of DNAME target, and changes
of DNSSEC keys (see Section 7.2.4).
Records beneath an allocator name, such as node-level discovery
records and any further delegations, are managed by the allocator's
authorized DNS administrators. These procedures do not require IANA
or the ipn.arpa operator to provision individual Node Numbers.
7.2.4. DS Records for Delegated Allocator Zones
The ipn.arpa operator MUST support authenticated requests to add,
update, and remove DS records for delegated allocator zones. Such
requests are authorized as described in Section 7.2.1. The operator
of a delegated allocator zone is responsible for coordinating changes
to its signing keys with updates to the corresponding DS records in
ipn.arpa.
This provides support for secure delegations; it does not require
that every delegated allocator zone be signed.
DS procedures apply to NS delegations. A DNAME in ipn.arpa (see
Section 4.4) is not a delegation: it is signed as ordinary data in
the ipn.arpa zone, and the namespace to which it redirects has its
own DNSSEC chain of trust.
Kline Expires 6 May 2027 [Page 23]
Internet-Draft IPN dot ARPA November 2026
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. References
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>.
Kline Expires 6 May 2027 [Page 24]
Internet-Draft IPN dot ARPA November 2026
[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>.
Kline Expires 6 May 2027 [Page 25]
Internet-Draft IPN dot ARPA November 2026
[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>.
Author's Address
Erik Kline
Aalyria Technologies, LLC
Email: ek.ietf@gmail.com
Kline Expires 6 May 2027 [Page 26]