]> Independent Avian Infrastructure Researcher

contacto@christianecg.com

General DNS avian carriers pigeon IPoAC bootstrapping 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.

Introduction established a framework for the transmission of IP datagrams using homing pigeons. Subsequent documents extended this work to include Quality of Service and IPv6 support . 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.

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 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 .

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 .

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 .

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 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.

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:

LATITUDE (32 bits):

Signed fixed-point integer in network byte order (big-endian) representing the Loft latitude in microdegrees (degrees × 10⁶). 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.

LONGITUDE (32 bits):

Signed fixed-point integer in network byte order (big-endian) representing the Loft longitude in microdegrees (degrees × 10⁶). 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 ).

(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: Operators MUST NOT configure HEADING values that direct inbound Carriers toward known raptor nesting sites. The consequences of such misconfigurations are described in .

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.

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 . In the event that the PoLR is unavailable due to conditions described in , 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.

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.

Retransmission Behavior 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.

Negative Caching and SERVFAIL Semantics When a Carrier fails to arrive, the resolver faces an ambiguous situation: the Carrier may have been intercepted (), may be resting in a non-authoritative location (), 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 . 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 . 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 Considerations DNSSEC 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 . Key rollover events MUST be scheduled outside of migration season (see ) 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.

Resolution Example The following diagram illustrates a complete DoAC resolution for the name "loft.example.com" under nominal atmospheric conditions, with no retransmission events. | | 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.

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, 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.

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.

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.

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.

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.

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. Loft operators SHOULD implement ingress filtering based on ring identification () and SHOULD maintain an up-to-date blocklist of known unauthorized Carriers.

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 .

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 (), 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.

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 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.

Zone Signing Key Compromise via Pigeon Theft The physical transport of Zone Signing Keys by Trusted Courier Pigeon (TCP, see ) 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.

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.

IANA Considerations This document requests the following actions from IANA:

• 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 .
• 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 .
• 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."

References Normative References IETF

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 .