Brevduer som DNS-bærere: Protokollstakken du ikke visste du trengte
DNS over duer: Protokollstakken du aldri visste du trengte
La meg starte med en tilståelse: Jeg har brukt pinlig mye tid på å lese et IETF-utkast om "DNS over Avian Carriers (DoAC)", og jeg angrer ingenting.
For de som ikke har hatt gleden av dette, er IETF organisasjonen som har ansvaret for de tekniske standardene som får dagens internett til å fungere. Deres dokumenter er som regel tette, metodiske og dypt seriøse. Så når du kommer over et utkast som seriøst foreslår å bruke brevduer til å løse hostnavn, tar du seg tid til å lese det — ikke fordi det er praktisk, men fordi det avslører noe fascinerende om hvordan vi tenker på nettverksprotokoller.
Protokollstakken som tiden glemte
Historien begynner i 1990 med RFC 1149, som introduserte IP over Avian Carriers (IPoAC). Ja, IETF publiserte en formell spesifikasjon for å sende IP-datagrammer via brevduer. Dokumentet inneholder estimater for pakkutap ("cirka 55% uvektet"), latensberegninger og throughput-sammenligninger. Det ble oppdatert i 2001 med RFC 2549 (Quality of Service-støtte for aviære transportører) og igjen i 2011 med RFC 6214 (IPv6-kompatibilitet).
Dette var ikke vitser — det var legitime eksperimentelle protokoller, komplett med fungerende implementasjoner og testing i virkeligheten. Universiteter og hackergrupper har faktisk satt opp duebaserte nettverk for moro skyld og læringsformål.
Men her er greia: i tre tiår hadde denne protokollstakken et enormt hull. Du kunne sende IP-pakker via due, men du kunne ikke løse domenenavn. Uten DNS måtte hver destinasjon hardkodes som en IP-adresse direkte på fuglen. Tenk deg å forklare nettverksadministratorene dine at å legge til en ny server krevde fysisk omtrening av duene dine.
DoAC: DNS for fuglene
DoAC-utkastet prøver å løse dette med karakteristisk teknisk alvor. Det definerer:
- Meldingsformater for DNS-spørringer og -svar som kan festes til duer
- AA (Avian Authority) Resource Record for å publisere loftadresser
- Retransmisjonsatferd som tar høyde for den uforutsigbare naturen til aviær levering
- Oppstartsprosedyrer inkludert "Reserveduen" for initial resolver-oppdagelse
Detaljnivået er genuint imponerende. Seksjon 5.2 diskuterer "Resolver Discovery Without Prior State," og erkjenner at din første due ikke kan vite hvor den skal finne en DNS-server fordi den ikke har DNS til å slå det opp. Løsningen? En forhåndskonfigurert nøddue.
Sikkerhetsbetraktninger som leses som et naturdokumentar
Der DoAC virkelig skinner, er i sikkerhetsanalysen. Utkastet identifiserer trusler som:
- Hauk-i-midten-angrep der et rovfugl avskjærer spørringen din på midtveien
- Duefalsk og den foreslåtte løsningen "Plumage-Based Authentication"
- Loftkapring der en angriper tar kontroll over destinasjonen din
- Denial of Flight-angrep (DoF) — essentially a DDoS but for fugler
- Den sultne katten som et fysisk lag-trussel (forklarer seg selv)
- Replay-angrep via taksidermert brevdue (noen sender en død due med gamle cachede svar)
Jeg ville betalt ekte penger for å se et red team prøve seg på noen av disse angrepsvektorene.
Hva dette egentlig forteller oss
Her er greia med absurde tekniske dokumenter: de er ofte mer lærerike enn fornuftige. DoAC tvinger deg til å konfrontere antakelser du aldri visste du gjorde.
Når du bruker DNS i dag, stoler du implisitt på:
- At ISP-ene dine ikke lyver til deg
- At pakkene ikke blir avlyttet eller endret
- At serverne er tilgjengelige når du trenger dem
- At den fysiske infrastrukturen ikke feiler katastrofalt
DoAC gjør alle disse implisitte tillitsforholdene eksplisitte — og latterlige. Et duenettverk gir ingen mening for produksjonssystemer, men øvelsen med å designe for det avslører nøyaktig hvor mye vi er avhengige av infrastruktur vi tar for gitt.
Den egentlige lærdommen
Det er en leksjon her for utviklere som bygger moderne systemer, spesielt de som jobber med edge computing, mesh-nettverk eller sporadisk tilkobling:
Hver protokoll antar en underliggende transport med spesifikke egenskaper. Når disse egenskapene endrer seg, trenger du nye protokoller.
DNS over TCP/IP antar pålitelig, rask pakkLevering. DNS over Avian Carriers antar... vel, at pakkene dine til slutt vil ankomme, kanskje, trolig. DoAC-utkastet er ikke bare en vits — det er en påminnelse om at "alltid på, lav latens, høy pålitelighet" er en luksus, ikke en konstant.
For startups som bygger applikasjoner for fremvoksende markeder, grisgrendte strøk eller katastrofescenarier, er det viktig å forstå disse avveiningene. IETF brukte 30 år på å tenke gjennom hva som skjer når nettverket ditt er en flokk med duer. Det arbeidet kan være mer relevant enn du tror.
Har du noen gang kommet over en protokoll som fikk deg til å tvile på antakelsene dine om hvordan nettverking fungerer? Del din favoritt-absurde RFC i kommentarene. Og hvis du fant en taksidermert due med DNS-poster vedlagt, vennligst fortell hvordan det gikk.