DNS Over Pigeon Carriers: The Most Absurd Protocol Stack You'll Ever Love

Let's start with a confession: I spent an embarrassing amount of time reading an IETF draft titled "DNS over Avian Carriers (DoAC)" and I regret nothing.

For those who haven't had the pleasure, the IETF is the organization responsible for the technical standards that power the modern internet. Their documents are typically dense, methodical, and deeply serious. So when you encounter a draft that seriously proposes using homing pigeons to resolve hostnames, you pay attention—not because it's practical, but because it reveals something fascinating about how we think about networking protocols.

The Protocol Stack That Time Forgot

The story begins in 1990 with RFC 1149, which introduced IP over Avian Carriers (IPoAC). Yes, the IETF published a formal specification for transmitting IP datagrams via carrier pigeons. The document includes packet loss estimates ("approximately 55% unweighted"), latency calculations, and throughput comparisons. It was updated in 2001 with RFC 2549 (Quality of Service support for avian carriers) and again in 2011 with RFC 6214 (IPv6 compatibility).

These weren't jokes—they were legitimate experimental protocols, complete with working implementations and real-world testing. Universities and hacker groups have actually deployed pigeon-based networks for fun and education.

Here's the problem, though: for three decades, this protocol stack had a massive gap. You could send IP packets via pigeon, but you couldn't resolve domain names. Without DNS, every destination had to be hardcoded as an IP address directly onto the bird. Imagine explaining to your network operators that adding a new server required physically retraining your pigeons.

Enter DoAC: DNS for the Birds

The DoAC draft attempts to solve this with characteristic technical seriousness. It defines:

• Message formats for DNS queries and responses that can be attached to pigeons
• The AA (Avian Authority) Resource Record for publishing loft addresses
• Retransmission behavior accounting for the unpredictable nature of avian delivery
• Bootstrapping procedures including the "Pigeon of Last Resort" for initial resolver discovery

The attention to detail is genuinely impressive. Section 5.2 discusses "Resolver Discovery Without Prior State," acknowledging that your first pigeon can't know where to find a DNS server because it doesn't have DNS to look it up. The solution? A pre-configured emergency pigeon.

Security Considerations That Read Like a Nature Documentary

Where DoAC truly shines is in its security analysis. The draft identifies threats including:

• Hawk-in-the-Middle attacks where a raptor intercepts your query mid-flight
• Pigeon spoofing and the proposed solution of "Plumage-Based Authentication"
• Loft hijacking where an attacker takes control of your destination
• Denial of Flight attacks (DoF)—essentially a DDoS but for birds
• The Hungry Cat as a Physical Layer Threat (self-explanatory)
• Replay attacks via taxidermied carrier (someone sends a dead pigeon with old cached responses)

I would pay actual money to see a red team attempt some of these attack vectors.

What This Actually Tells Us

Here's the thing about absurd technical documents: they're often more instructive than sensible ones. DoAC forces you to confront assumptions you never realized you were making.

When you use DNS today, you implicitly trust:

• Your ISP's resolvers won't lie to you
• The packets won't be intercepted or modified
• The servers will be available when you need them
• The physical infrastructure won't fail catastrophically

DoAC makes all these implicit trusts explicit—and ridiculous. A pigeon network makes no sense for production systems, but the exercise of designing for it reveals exactly how much we depend on infrastructure we take for granted.

The Real Takeaway

There's a lesson here for developers building modern systems, especially those working with edge computing, mesh networks, or intermittent connectivity:

Every protocol assumes an underlying transport with specific properties. When those properties change, you need new protocols.

DNS over TCP/IP assumes reliable, fast packet delivery. DNS over Avian Carriers assumes... well, that your packets will eventually arrive, probably, maybe. The DoAC draft isn't just a joke—it's a reminder that "always-on, low-latency, high-reliability" is a luxury, not a constant.

For startups building applications for emerging markets, rural areas, or disaster scenarios, understanding these tradeoffs matters. The IETF spent 30 years thinking about what happens when your network is a flock of pigeons. That work might be more relevant than you think.

Have you ever encountered a protocol that made you question your assumptions about how networking works? Share your favorite absurd RFC in the comments. And if you found a taxidermied pigeon with DNS records attached, please let us know how that worked out.