| Internet-Draft | DoAC | June 2026 |
| Cruz Gonzalez | Expires 10 December 2026 | [Page] |
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.¶
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 (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.¶
[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.¶
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.¶
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:¶
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.¶
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
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.¶
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.¶
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.¶
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.¶
[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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
Operators deploying DoAC in production environments should be aware of the following baseline performance characteristics.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
This document requests the following actions from IANA:¶
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:¶
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.¶