DNS over Avian Carriers (DoAC)
draft-cruzgonzalez-ipoac-dns-00
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 | Christian Elías Cruz González | ||
| Last updated | 2026-06-08 | ||
| 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-cruzgonzalez-ipoac-dns-00
Network Working Group C. E. Cruz Gonzalez
Internet-Draft Independent Avian Infrastructure Researcher
Intended status: Informational 8 June 2026
Expires: 10 December 2026
DNS over Avian Carriers (DoAC)
draft-cruzgonzalez-ipoac-dns-00
Abstract
The Domain Name System (DNS) was designed under the implicit
assumption that the underlying transport would be fast, reliable, and
free from predation. This document specifies DNS over Avian Carriers
(DoAC), enabling hostname resolution for networks operating over
avian-carrier infrastructure. Without DoAC, operators of avian-
carrier networks are forced to hardcode IP addresses directly onto
their Carriers, a practice that does not scale and is widely
considered inelegant.
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 10 December 2026.
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.
Cruz Gonzalez Expires 10 December 2026 [Page 1]
Internet-Draft DoAC June 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 4
4. The AA Resource Record . . . . . . . . . . . . . . . . . . . 4
5. The Bootstrapping Problem . . . . . . . . . . . . . . . . . . 5
5.1. The Pigeon of Last Resort (PoLR) . . . . . . . . . . . . 6
5.2. Resolver Discovery Without Prior State . . . . . . . . . 6
6. Retransmission Behavior . . . . . . . . . . . . . . . . . . . 6
7. Negative Caching and SERVFAIL Semantics . . . . . . . . . . . 7
8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Resolution Example . . . . . . . . . . . . . . . . . . . . . 8
10. Operational Considerations . . . . . . . . . . . . . . . . . 8
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11.1. Hawk-in-the-Middle (HitM) Attacks . . . . . . . . . . . 9
11.2. Pigeon Spoofing and Plumage-Based Authentication . . . . 10
11.3. Loft Hijacking . . . . . . . . . . . . . . . . . . . . . 10
11.4. Denial of Flight (DoF) . . . . . . . . . . . . . . . . . 10
11.5. Migration Season Routing Anomalies . . . . . . . . . . . 11
11.6. The Hungry Cat as a Physical Layer Threat . . . . . . . 11
11.7. Replay Attacks via Taxidermied Carrier . . . . . . . . . 11
11.8. Zone Signing Key Compromise via Pigeon Theft . . . . . . 12
11.9. Covert Feather Channel . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
[RFC1149] established a framework for the transmission of IP
datagrams using homing pigeons. Subsequent documents extended this
work to include Quality of Service [RFC2549] and IPv6 support
[RFC6214].
Despite these advances, a critical gap has remained unaddressed for
over three decades: how does a host on an avian-carrier network
resolve a hostname?
Prior to this document, the only available solution was to hardcode
the IP address of the destination loft directly onto the message
attached to the Carrier. This approach is operationally burdensome,
does not support load balancing across multiple lofts, and makes
pigeon renumbering events catastrophically disruptive.
Cruz Gonzalez Expires 10 December 2026 [Page 2]
Internet-Draft DoAC June 2026
This document specifies DNS over Avian Carriers (DoAC), closing this
gap and completing the avian-carrier protocol stack to a degree that
the authors consider satisfying, if not advisable.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] [BCP14] when, and only when, they appear in
all capitals, as shown here.
The following terms are used throughout this document:
Carrier:
A homing pigeon or other avian entity participating in packet
transport as specified in [RFC1149].
Loft:
The physical structure serving as the network endpoint for one or
more Carriers. Analogous to a host in conventional networking.
TTL (Time To Live):
In the context of DoAC, this field retains its DNS semantic
meaning but acquires an additional biological interpretation.
Operators SHOULD ensure that TTL values do not exceed the expected
lifespan of the Carrier. Setting TTL values in excess of 15 years
is NOT RECOMMENDED.
NXPIGEON:
A condition in which the Carrier fails to arrive at the
destination Loft within the expected transmission window. See
Section 7.
Pigeon of Last Resort (PoLR):
A pre-trained Carrier designated to handle queries that cannot be
resolved through any other means. Analogous to the recursive
resolver of last resort.
Trusted Courier Pigeon (TCP):
A Carrier designated for the transport of sensitive keying
material. The acronym collision with Transmission Control
Protocol is noted and considered appropriate.
Apex Predator:
Any entity in the physical environment capable of intercepting a
Carrier in flight. See Section 11.1.
Cruz Gonzalez Expires 10 December 2026 [Page 3]
Internet-Draft DoAC June 2026
3. Message Format
DNS messages transmitted via DoAC MUST be transcribed onto a
lightweight, weather-resistant medium prior to attachment to the
Carrier. The use of microfilm is RECOMMENDED. Plain paper is
permitted but NOT RECOMMENDED in regions with annual precipitation
exceeding 50mm.
The DNS query SHOULD be attached to the Carrier's left leg, and the
DNS response to the right leg. This convention simplifies visual
triage at the Loft and is consistent with emerging best practices in
the avian-carrier operator community. Implementations MUST NOT
attach both a query and a response to the same leg simultaneously.
The maximum message size is constrained by the carrying capacity of
the Carrier, which [RFC1149] defines as a maximum segment size of 256
milligrams. Operators requiring larger DNS responses, such as those
containing DNSKEY RRsets, SHOULD consider using a larger bird. The
use of eagles is OPTIONAL but acknowledged as impressive.
DNS-over-TCP semantics are outside the scope of this document, as TCP
over avian carriers already introduces sufficient complexity.
4. The AA Resource Record
This document defines the AA (Avian Address) resource record type for
use in DoAC-capable deployments. The AA record encodes the physical
address of a Loft in a format suitable for Carrier navigation.
The RDATA section of an AA record has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LATITUDE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LONGITUDE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HEADING | ALT-BAND | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LATITUDE (32 bits):
Signed fixed-point integer in network byte order (big-endian)
representing the Loft latitude in microdegrees (degrees × 10^6).
Range: −90,000,000 to +90,000,000. This encoding provides sub-
meter precision, sufficient for Loft identification in all but the
most densely populated aviaries. Zone file presentation uses
decimal degrees.
Cruz Gonzalez Expires 10 December 2026 [Page 4]
Internet-Draft DoAC June 2026
LONGITUDE (32 bits):
Signed fixed-point integer in network byte order (big-endian)
representing the Loft longitude in microdegrees (degrees × 10^6).
Range: −180,000,000 to +180,000,000. Zone file presentation uses
decimal degrees.
HEADING (16 bits):
Unsigned integer in network byte order specifying the preferred
Carrier approach heading in degrees magnetic north. Valid values
are 0–359. Values in the range 360–65535 are reserved and MUST
NOT be used; receivers encountering such values MUST treat the
record as malformed. Operators SHOULD set this field to the
heading that minimizes prevailing headwind exposure at the Loft
entrance.
ALT-BAND (8 bits):
Preferred cruising altitude band for inbound Carriers. Valid
values are maintained in the IANA Avian Address Altitude Band
registry (see Section 12).
(reserved) (8 bits):
Reserved for future use. MUST be set to zero on transmission and
MUST be ignored on receipt.
A zone file entry for a Loft located in Bergen, Norway, with a
preferred westerly approach at medium altitude, would be represented
as:
example.com. 86400 IN AA 60.391263 5.322054 270 1
Operators MUST NOT configure HEADING values that direct inbound
Carriers toward known raptor nesting sites. The consequences of such
misconfigurations are described in Section 11.1.
5. The Bootstrapping Problem
The fundamental challenge of DoAC is that in order to dispatch a
Carrier to resolve a hostname, the operator must first know the IP
address of the DoAC resolver's Loft. If that address is itself
stored in DNS, a dependency cycle is formed that cannot be resolved
through any known protocol mechanism.
This is hereafter referred to as the Pigeon-Before-Egg Problem.
This document specifies the following resolution strategy.
Cruz Gonzalez Expires 10 December 2026 [Page 5]
Internet-Draft DoAC June 2026
5.1. The Pigeon of Last Resort (PoLR)
Each host on an avian-carrier network MUST maintain at least one pre-
trained Carrier whose destination Loft address is known a priori and
hardcoded into the host's configuration. This Carrier is designated
the Pigeon of Last Resort (PoLR).
The PoLR MUST be trained to the address of a well-known recursive
resolver Loft. The IANA-assigned PoLR Loft coordinates are specified
in Section 12.
In the event that the PoLR is unavailable due to conditions described
in Section 11, the host MUST fall back to a secondary PoLR if one is
configured. Hosts SHOULD maintain a minimum of two PoLR Carriers at
all times. The use of a single PoLR is operationally equivalent to
having a single point of failure, which remains, as always,
inadvisable.
5.2. Resolver Discovery Without Prior State
In environments where no PoLR has been provisioned, such as upon
initial deployment of a new avian-carrier network, the operator MUST
physically travel to the nearest authoritative Loft and obtain a
Carrier trained to its address. This process is referred to as
Manual Resolver Bootstrap (MRB) and is considered out-of-band.
DHCP over Avian Carriers is not addressed in this document, as that
problem is considered sufficiently complex to warrant its own
document and its own bird.
6. Retransmission Behavior
[RFC1035] specifies that DNS resolvers SHOULD retransmit unanswered
queries after approximately 5 seconds. This interval is wholly
inappropriate for avian-carrier transport, where one-way latency is
measured in hours to days depending on atmospheric conditions,
Carrier motivation, and prevailing winds.
Implementations of DoAC MUST NOT retransmit a query until a minimum
of 72 hours has elapsed since the initial dispatch. Implementations
SHOULD account for seasonal variation by applying a jitter factor
derived from the average wind speed at the Carrier's latitude of
origin.
Cruz Gonzalez Expires 10 December 2026 [Page 6]
Internet-Draft DoAC June 2026
The retransmission limit MUST be set to 1. Dispatching multiple
Carriers for the same query is strongly discouraged, as it may result
in out-of-order delivery should one Carrier select a more efficient
flight path, producing query ID collisions that are difficult to
debug and impossible to explain to management.
In cases where a Carrier has not returned within 21 days, the query
MUST be considered lost and a new Carrier dispatched. The operator
SHOULD inspect the Carrier's last known trajectory for diagnostic
purposes before declaring the incident closed.
7. Negative Caching and SERVFAIL Semantics
When a Carrier fails to arrive, the resolver faces an ambiguous
situation: the Carrier may have been intercepted (Section 11.1), may
be resting in a non-authoritative location (Section 11.5), or the
destination Loft may genuinely not exist (NXPIGEON).
DoAC resolvers MUST NOT issue NXDOMAIN until at least three
independent Carriers have failed to arrive at the destination Loft
within the retransmission window defined in Section 6.
A SERVFAIL response SHOULD be issued in cases where one or more
Carriers have departed but none have returned within 30 days, and the
operator has reasonable grounds to suspect a non-DNS cause of
failure, such as those enumerated in Section 11.
Negative cache TTL for DoAC is RECOMMENDED to be no less than 7 days,
as re-querying on shorter intervals is both operationally wasteful
and distressing to the Carriers.
8. DNSSEC Considerations
DNSSEC [RFC4033] requires cryptographic signing of DNS resource
records. In the DoAC context, this introduces novel operational
challenges that have no precedent in the existing DNSSEC literature.
The Zone Signing Key (ZSK) MUST be physically transported to the
signing Loft by a Trusted Courier Pigeon (TCP). The use of an
untrusted Carrier for this purpose is a significant security risk and
is further addressed in Section 11.8.
Key rollover events MUST be scheduled outside of migration season
(see Section 11.5) to ensure reliable delivery of new keying
material. Operators SHOULD plan a minimum of 45 days of lead time
for key rollover operations, excluding weekends and adverse weather.
Cruz Gonzalez Expires 10 December 2026 [Page 7]
Internet-Draft DoAC June 2026
The RRSIG validity period MUST be set to a value that accounts for
the maximum expected round-trip transit time of the signing Carrier.
Signatures that expire while a Carrier is in flight are a known
operational hazard, hereafter referred to as In-Flight Expiry (IFE).
Operators experiencing IFE SHOULD increase their RRSIG validity
period or invest in faster Carriers.
9. Resolution Example
The following diagram illustrates a complete DoAC resolution for the
name "loft.example.com" under nominal atmospheric conditions, with no
retransmission events.
Querier PoLR Loft Auth. Loft
| | |
|--[Carrier A]-->| | T+0h (query dispatched)
| | | T+19h (arrives; headwind noted)
| |--[Carrier B]-->| T+19h (recursive query)
| | | T+31h (arrives; thermal assist)
| |<--[Carrier C]--| T+31h (response dispatched)
| | | T+44h (arrives)
|<--[Carrier D]--| | T+44h (response forwarded)
| | | T+63h (arrives)
| | |
Total RTT: 63 hours. Carriers: 4.
Upon receipt of Carrier D, the querier SHOULD cache the response in
accordance with the AA record TTL and release the Carrier to its
resting perch. The Carrier MUST NOT be interrogated for diagnostic
purposes until it has had adequate recovery time.
10. Operational Considerations
Operators deploying DoAC in production environments should be aware
of the following baseline performance characteristics.
Mean Time Between Hawk Intercepts (MTBHI):
Empirical studies suggest approximately 1 interception event per
200 carrier-flights in open terrain. MTBHI degrades significantly
in environments with documented raptor activity and should be
factored into redundancy planning. Operators in high-raptor-
density zones are advised to provision accordingly and to maintain
a current incident log.
Query Latency:
Median round-trip latency for a two-hop DoAC resolution is 48–72
hours under nominal conditions. The 95th percentile latency,
Cruz Gonzalez Expires 10 December 2026 [Page 8]
Internet-Draft DoAC June 2026
incorporating adverse weather and Carrier motivational variance,
is 21 days. Operators accustomed to sub-millisecond DNS
resolution are advised to recalibrate their SLA expectations
before deploying DoAC in production.
Carrier Utilization:
Defined as the ratio of actively deployed Carriers to total
provisioned Carriers. Operators SHOULD maintain utilization at or
below 70% to preserve capacity for retransmission events, moulting
season, and unplanned incidents.
Sustained Query Rate:
A well-managed Loft with 20 active Carriers can sustain
approximately 0.3 queries per hour under nominal conditions. This
figure assumes an average round-trip transit time of 66 hours and
a post-flight recovery period of 2 hours per Carrier. Operators
requiring higher throughput should acquire more birds.
11. Security Considerations
The security properties of DoAC differ substantially from those of
conventional DNS transport mechanisms. The threat model is expanded
to include a class of physical-layer adversaries not previously
considered in DNS security analyses. This section enumerates known
threats and recommended mitigations.
11.1. Hawk-in-the-Middle (HitM) Attacks
The most significant threat to DoAC integrity is interception of the
Carrier by a raptor or other apex predator mid-flight. This attack
is classified as a Hawk-in-the-Middle (HitM) attack and results in
permanent, unrecoverable loss of the DNS message.
Unlike conventional Man-in-the-Middle attacks, HitM attacks do not
afford the adversary an opportunity to inspect or modify the message
before delivery; the message is destroyed along with the Carrier.
While this limits the attacker's ability to perform active
interception, it constitutes an effective and highly targeted Denial
of Service.
Mitigations include dispatching Carriers in pairs to increase
redundancy, equipping Carriers with raptor-deterrent plumage, and
routing flight paths away from known raptor nesting sites. The
standardization of deterrent plumage profiles is an open problem and
is left to operator discretion pending further research.
Cruz Gonzalez Expires 10 December 2026 [Page 9]
Internet-Draft DoAC June 2026
11.2. Pigeon Spoofing and Plumage-Based Authentication
An adversary may introduce a counterfeit Carrier bearing a fraudulent
DNS response. This attack is of particular concern because baseline
DoAC implementations do not verify the physical identity of the
Carrier delivering the response.
Operators MUST implement Carrier authentication prior to accepting
any DNS response. The RECOMMENDED authentication mechanism is ring-
based identification, wherein each authorized Carrier is assigned a
unique, tamper-evident leg ring at provisioning time. Ring
identifiers MUST be maintained in a local registry and verified upon
every arrival.
Plumage-based authentication (PBA), while intuitive, is NOT
RECOMMENDED as a sole authentication mechanism, as it is susceptible
to adversarial dye application by a motivated attacker with access to
craft supplies.
11.3. Loft Hijacking
An attacker who gains physical control of an authoritative Loft may
modify or replace the DNS records stored therein and dispatch
Carriers bearing fraudulent responses to unsuspecting queriers. This
attack is analogous to DNS zone takeover in conventional networks and
is considerably more difficult to detect remotely, as there is no BGP
equivalent for Loft ownership verification.
Operators are advised to secure their Lofts with appropriate physical
access controls including locks, fencing, and where the threat model
warrants, guards. Remote attestation of Loft integrity is an open
research problem outside the scope of this document.
11.4. Denial of Flight (DoF)
A volumetric attack on DoAC infrastructure may be achieved by
dispatching a large number of inbound Carriers toward the target
Loft, exhausting its capacity to process incoming messages. This is
classified as a Denial of Flight (DoF) attack.
Unlike conventional DDoS amplification attacks, DoF attacks require
the adversary to possess a substantial number of Carriers, imposing a
natural rate limit on attack scale. However, the barrier to entry
may be lower than anticipated in urban areas with high ambient pigeon
populations, where recruitment of untrained Carriers has been
observed to require only breadcrumbs.
Cruz Gonzalez Expires 10 December 2026 [Page 10]
Internet-Draft DoAC June 2026
Loft operators SHOULD implement ingress filtering based on ring
identification (Section 11.2) and SHOULD maintain an up-to-date
blocklist of known unauthorized Carriers.
11.5. Migration Season Routing Anomalies
Homing pigeons exhibit seasonal migratory instincts that may cause
Carriers to deviate from their trained routes during spring and
autumn transition periods. This behavior can result in DNS queries
being delivered to incorrect Lofts, increased latency of several
weeks, or complete non-delivery.
Operators SHOULD avoid scheduling DNS operations that require
reliable, timely delivery during known migration periods. TTL values
SHOULD be extended by a minimum of 30 days during March through May
and September through November in the Northern Hemisphere, and
adjusted accordingly for Southern Hemisphere deployments.
The interaction between migration season and DNSSEC key rollover is
considered particularly hazardous and is documented separately in
Section 8.
11.6. The Hungry Cat as a Physical Layer Threat
Domestic and feral felids (_Felis catus_) represent a persistent and
statistically underestimated threat to DoAC deployments in urban and
peri-urban environments. Unlike raptor-based HitM attacks
(Section 11.1), felid interceptions typically occur at the Loft
perimeter rather than in flight, and may therefore be mitigated
through physical security measures rather than flight path planning.
Operators deploying DoAC in environments with known felid presence
MUST implement deterrence at the Loft perimeter. The specific
deterrence mechanism is implementation-defined. Anti-cat netting is
RECOMMENDED. The use of a Carrier Guardian Dog is noted as a viable
complementary control, though its provisioning, training, and ongoing
operational costs are outside the scope of this document.
11.7. Replay Attacks via Taxidermied Carrier
A sophisticated adversary may preserve a Carrier following
interception and subsequently present it, together with its attached
DNS message, to the destination Loft at a time of the adversary's
choosing. This constitutes a replay attack.
The risk of replay via taxidermied Carrier is considered low in
practice, as the operational complexity is considerable and the
effective attack window is bounded by the decomposition timeline of
Cruz Gonzalez Expires 10 December 2026 [Page 11]
Internet-Draft DoAC June 2026
the Carrier. However, operators in environments with known taxidermy
expertise SHOULD implement replay protection by including a
monotonically increasing sequence number in each DNS message.
Operators MAY additionally verify Carrier vitality upon arrival at
the Loft. Carriers that do not respond to standard Loft stimuli
SHOULD be treated as suspect and quarantined pending investigation.
11.8. Zone Signing Key Compromise via Pigeon Theft
The physical transport of Zone Signing Keys by Trusted Courier Pigeon
(TCP, see Section 8) introduces the possibility of key compromise
through deliberate Carrier theft. An adversary who intercepts the
TCP and successfully recovers the attached keying material gains the
ability to sign arbitrary DNS responses that will validate as
authentic to DNSSEC-aware resolvers.
Operators MUST encrypt all keying material prior to attachment to the
TCP. The decryption key MUST NOT be transported by the same Carrier.
Dual-Carrier key transport is RECOMMENDED, wherein two Carriers are
dispatched simultaneously, each carrying one half of the keying
material. The capture of either Carrier in isolation MUST NOT be
sufficient to recover the full key.
This protocol constitutes, to the authors' knowledge, the first
cryptographic key ceremony to require physical bird management as a
procedural step.
11.9. Covert Feather Channel
In environments where DoAC traffic is subject to monitoring, an
adversary with access to one or more Carriers may encode information
in the physical characteristics of the Carrier itself: feather
arrangement, banding configuration, or the specific Carrier selected
from a pool with known identities. This constitutes a Covert Feather
Channel (CFC).
Detection of Covert Feather Channels requires ornithological
expertise that is not readily automatable with current tooling.
Operators with elevated security requirements SHOULD retain the
services of a licensed ornithologist as part of their security
operations team. Job postings for this role are expected to generate
significant interest.
12. IANA Considerations
This document requests the following actions from IANA:
Cruz Gonzalez Expires 10 December 2026 [Page 12]
Internet-Draft DoAC June 2026
* Assignment of a new DNS Resource Record type code for "AA" (Avian
Address) in the "Resource Record (RR) TYPEs" registry of the
"Domain Name System (DNS) Parameters" registry group. The wire
format is defined in Section 4.
* Creation of a new registry, "Avian Address Altitude Band
Registry," under the "Domain Name System (DNS) Parameters"
registry group. The initial contents are as follows:
- 0 — Low (below 100m AGL)
- 1 — Medium (100–300m AGL)
- 2 — High (above 300m AGL)
- 3 — Thermal (altitude operator-defined; Carrier selects optimal
soaring layer)
Future assignments require Standards Action per [RFC8126].
* Designation of official PoLR Loft coordinates to serve as the
well-known resolver Loft of last resort for the global Internet.
IANA is requested to provision, staff, and maintain at least one
such Loft at a geographically central location with good flight
visibility, and to publish its coordinates as an AA record in the
IANA-maintained zone. The authors acknowledge that this
represents a novel operational category for IANA and that existing
budget allocations may not cover avian husbandry costs.
* Existing registration of UDP port 53 for DNS remains valid. The
authors note that in the DoAC context, the "D" in the port
assignment no longer stands for "Datagram."
13. References
13.1. Normative References
[BCP14] IETF, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, 1997,
<https://www.rfc-editor.org/info/bcp14>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
Cruz Gonzalez Expires 10 December 2026 [Page 13]
Internet-Draft DoAC June 2026
[RFC1149] Waitzman, D., "Standard for the transmission of IP
datagrams on avian carriers", RFC 1149,
DOI 10.17487/RFC1149, April 1990,
<https://www.rfc-editor.org/info/rfc1149>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of
Service", RFC 2549, DOI 10.17487/RFC2549, April 1999,
<https://www.rfc-editor.org/info/rfc2549>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC6214] Carpenter, B. and R. Hinden, "Adaptation of RFC 1149 for
IPv6", RFC 6214, DOI 10.17487/RFC6214, April 2011,
<https://www.rfc-editor.org/info/rfc6214>.
[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/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Acknowledgements
The authors wish to thank D. Waitzman for RFC 1149, without which
this document would have no foundation, and the entire avian-carrier
operator community for decades of informal experimentation that
informed the operational parameters described herein.
Special thanks are due to the Carriers who participated in
preliminary interoperability testing. Their contributions to this
work were involuntary but appreciated. Those who did not return are
remembered.
The authors also thank the hawks, whose consistent behavior provided
the empirical basis for the threat model in Section 11.1.
Cruz Gonzalez Expires 10 December 2026 [Page 14]
Internet-Draft DoAC June 2026
Author's Address
Christian Elias Cruz Gonzalez
Independent Avian Infrastructure Researcher
Email: contacto@christianecg.com
Cruz Gonzalez Expires 10 December 2026 [Page 15]