DNS via Postduiven: Het Absurdste Protocol Stack Dat Je Ooit Zult Liefhebben

Laat me maar eerlijk zijn: ik heb veel te veel tijd besteed aan het lezen van een IETF-draft over "DNS over Avian Carriers (DoAC)" en ik heb geen seconde spijt.

Voor wie dit niet kent: de IETF is de organisatie die verantwoordelijk is voor de technische standaarden achter het moderne internet. Hun documenten zijn doorgaans dichtbevolkt, methodisch en bloedserieus. Dus wanneer je een draft tegenkomt die serieus voorstelt om homing pigeons te gebruiken voor hostname-resolutie, dan luister je aandachtig — niet omdat het praktisch is, maar omdat het iets fascinerends onthult over hoe we denken over netwerkprotocollen.

Het Protocol Stack dat de Tijd Vergeten Is

Het verhaal begint in 1990 met RFC 1149, dat IP over Avian Carriers (IPoAC) introduceerde. Ja, de IETF publiceerde een formele specificatie voor het verzenden van IP-datagrammen via postduiven. Het document bevat schattingen voor pakketverlies ("ongeveer 55% ongewogen"), latentieberekeningen en doorvoervergelijkingen. In 2001 volgde RFC 2549 (Quality of Service-ondersteuning voor vogeltransport) en in 2011 nogmaals RFC 6214 (IPv6-compatibiliteit).

Dit waren geen grapjes — het waren legitieme experimentele protocollen, compleet met werkende implementaties en tests in de echte wereld. Universiteiten en hackergroepen hebben daadwerkelijk op duiven gebaseerde netwerken gebouwd voor educatie en vermaak.

Maar hier is het probleem: dertig jaar lang had dit protocol stack een enorme lacune. Je kon IP-pakketten versturen via duif, maar je kon geen domeinnamen resolven. Zonder DNS moest elke bestemming rechtstreeks als IP-adres op de vogel worden geprogrammeerd. Stel je voor dat je aan je netwerkbeheerders uit moet leggen dat het toevoegen van een nieuwe server betekende dat je fysiek je duiven moest omscholen.

DoAC: DNS voor de Gevleugelden

De DoAC-draft probeert dit op te lossen met kenmerkende technische ernst. Het definieert:

• Berichtformaten voor DNS-queries en -responses die aan duiven kunnen worden bevestigd
• Het AA (Avian Authority) Resource Record voor het publiceren van duiventil-adressen
• Hertransmissiegedrag dat rekening houdt met het onvoorspelbare karakter van vogelbezorging
• Opstartprocedures inclusief de "Pigeon of Last Resort" voor initiële resolver-ontdekking

De aandacht voor detail is oprecht indrukwekkend. Sectie 5.2 bespreekt "Resolver Discovery Without Prior State," waarin wordt erkend dat je eerste duif niet kan weten waar hij een DNS-server vindt omdat er geen DNS beschikbaar is om dat op te zoeken. De oplossing? Een vooraf geconfigureerde noodduif.

Beveiligingsoverwegingen die Klinken als een Natuurdocumentaire

Waar DoAC echt in uitblinkt is de beveiligingsanalyse. De draft identificeert dreigingen waaronder:

• Hawk-in-the-Middle attacks waarbij een roofvogel je query halverwege onderschept
• Pigeon spoofing en de voorgestelde oplossing van "Plumage-Based Authentication"
• Loft hijacking waarbij een aanvaller controle krijgt over je bestemming
• Denial of Flight attacks (DoF) — essentially een DDoS maar dan voor vogels
• The Hungry Cat as a Physical Layer Threat (zelfverklarend)
• Replay attacks via taxidermied carrier (iemand stuurt een opgezet exemplaar met oude gecachte responses)

Ik zou serieus geld neerleggen om een red team te zien dat een paar van deze aanvalsvectoren daadwerkelijk uitprobeert.

Wat Dit Ons Echt Vertelt

Hier is het ding over absurde technische documenten: ze zijn vaak instructiever dan voor de hand liggende exemplaren. DoAC dwingt je om aannames onder ogen te zien waarvan je niet wist dat je ze maakte.

Wanneer je vandaag DNS gebruikt, vertrouw je impliciet op:

• Dat de resolvers van je ISP je niet voorliegen
• Dat pakketten niet worden onderschept of aangepast
• Dat de servers beschikbaar zijn wanneer je ze nodig hebt
• Dat de fysieke infrastructuur niet catastrofaal faalt

DoAC maakt al deze impliciete vertrouwensrelaties expliciet — en belachelijk. Een duifnetwerk heeft geen enkele zin voor productiesystemen, maar de oefening om het te ontwerpen onthult exact hoeveel we afhangen van infrastructuur die we als vanzelfsprekend beschouwen.

De Echte Les

Er zit een les in voor ontwikkelaars die moderne systemen bouwen, vooral degenen die werken met edge computing, mesh-netwerken of intermitterende connectiviteit:

** Elk protocol gaat uit van een onderliggend transport met specifieke eigenschappen.** Wanneer die eigenschappen veranderen, heb je nieuwe protocollen nodig.

DNS over TCP/IP gaat uit van betrouwbare, snelle pakketbezorging. DNS over Avian Carriers gaat uit van... nou ja, dat je pakketten uiteindelijk aankomen, waarschijnlijk, misschien. De DoAC-draft is niet zomaar een grapje — het is een herinnering dat "altijd-aan, lage-latentie, hoge-betrouwbaarheid" een luxe is, geen constant gegeven.

Voor startups die applicaties bouwen voor opkomende markten, plattelandsgebieden of rampenscenario's is dit inzicht waardevol. De IETF heeft dertig jaar nagedacht over wat er gebeurt wanneer je netwerk uit een zwerm duiven bestaat. Dat werk zou wel eens relevanter kunnen zijn dan je denkt.

Heb je ooit een protocol tegen gekomen dat je deed twijfelen aan je aannames over hoe netwerken werken? Deel je favoriete absurde RFC in de reacties. En als je een opgezette duif met DNS-records hebt gevonden, vertel ons alsjeblieft hoe dat is afgelopen.