DNS via brevduva: Protokollet som får dig att ifrågasätta allt du trodde du visste

Ska jag vara ärlig? Jag har ägnat alldeles för många timmar åt att läsa ett IETF-utkast som handlar om DNS via brevduvor. Och jag ångrar det inte.

För er som inte känner till IETF: det är den organisation som tar fram de tekniska standarderna som håller internet ihop. Deras dokument brukar vara torra, metodiska och gravallvarliga. Så när man stöter på ett utkast som på fullaste allvar föreslår att använda brevduvor för att slå upp domännamn – ja, då stannar man upp. Inte för att det är praktiskt, utan för att det avslöjar något fascinerande om hur vi tänker kring nätverksprotokoll.

Historien börjar 1990

Det hela startade med RFC 1149, ett dokument som introducerade konceptet IP via brevduvor. Låter det skruktigt? Visst, absolut. Men IETF publicerade det ändå – komplett med uppskattningar av paketförluster ("ungefär 55 procent"), beräkningar av svarstider och jämförelser av kapacitet.

Och det stannade inte där. 2001 kom RFC 2549 med stöd för tjänstekvalitet för brevduvebaserade nätverk. 2011 följde RFC 6214 som säkerställde kompatibilitet med IPv6.

Det här var inga påskämt. Det var legitima experimentella protokoll med fungerande implementationer och tester i verkligheten. Universitet och hackerspännare världen över har faktiskt byggt brevduvebaserade nätverk för utbildning och nöjes skull.

Hålret i protokollet

Men i trettio år fanns det ett ordentligt hål i stacken. Du kunde skicka IP-paket via brevduva, ja. Men du kunde inte slå upp domännamn. Utan DNS måste varje destination vara förkodad som en IP-adress direkt på fågeln.

Föreställ dig samtalet med nätverksoperatörerna: "Vi behöver lägga till en ny server." "Okej, då måste vi fysiskt omträna brevduvorna."

Absurt? Definitivt. Men också pedagogiskt.

DoAC: Lösningen som tar udden av problemet

DoAC-utkastet (DNS over Avian Carriers) försöker lösa just detta – med samma teknikiska seriositet som vilket protokoll som helst.

Dokumentet definierar:

• Meddelandeformat för DNS-frågor och svar som kan fästas på brevduvor
• AA-posten (Avian Authority) för publicering av loftadresser
• Återsändningsbeteende som tar hänsyn till den oförutsägbara naturen hos luftburen leverans
• Uppstartsprocedurer inklusive "Sista utvägs-budfågeln" för initial resolver-upptäckt

Särskilt intressant är avsnittet om "Resolver Discovery Without Prior State" – alltså hur din första brevduva ska veta var DNS-servern finns om den inte kan slå upp den med DNS. Lösningen? En förkonfigurerad nödbrevduva.

Säkerhet som låter som en naturserie

Här blir DoAC riktigt underhållande. Säkerhetsanalysen innehåller hot som:

• Hök-i-mitten-attacker där ett rovdjur snappat upp din fråga på halva vägen
• Brevduveförfalskning och den föreslagna lösningen "befjädringsbaserad autentisering"
• Loftkapning där en angripare tar kontrollen över din destination
• Flygförbudsattacker (DoF) – i princip en DDoS, fast för fåglar
• Den hungriga katten som fysiskt hot (ja, precis som det låter)
• Replay-attacker via uppstoppad brevduva (någon skickar en död fågel med gamla cachade svar)

Jag skulle faktiskt betala för att se ett red team försöka genomföra några av dessa attackvektorer.

Vad detta egentligen lär oss

Absurda tekniska dokument är ofta mer lärorika än väl genomtänkta sådana. DoAC tvingar dig att konfrontera antaganden du aldrig visste att du gjorde.

När du använder DNS idag litar du implicit på:

• Att din ISPs resolvers inte ljuger för dig
• Att paketen inte stoppas eller ändras på vägen
• Att servrarna finns tillgängliga när du behöver dem
• Att den fysiska infrastrukturen inte går sönder katastrofalt

DoAC gör alla dessa implicita tillit explicit – och löjligt. Ett brevduvenätverk är meningslöst för produktionssystem, men övningen att designa för det avslöjar exakt hur mycket vi förlitar oss på infrastruktur vi tar för given.

Den riktiga poängen

Här är en läxa för alla som bygger moderna system, särskilt de som jobbar med edge computing, mesh-nätverk eller intermittent uppkoppling:

Varje protokoll förutsätter en underliggande transport med specifika egenskaper. När de egenskaperna förändras behöver du nya protokoll.

DNS över TCP/IP förutsätter tillförlitlig, snabb paketleverans. DNS via brevduvor förutsätter... ja, att paketen så småningom anländer, troligtvis, kanske.

DoAC-utkastet är inte bara ett skämt – det är en påminnelse om att "alltid påslagen, låg latens, hög tillförlitlighet" är en lyx, inte en självklarhet.

För startups som bygger för tillväxtmarknader, landsbygden eller katastrofscenarier: förstå dessa avvägningar. IETF har spenderat trettio år på att fundera på vad som händer när ditt nätverk är en flock brevduvor. Det arbetet kanske är mer relevant än du tror.

Har du stött på ett protokoll som fått dig att ifrågasätta hur nätverksfunkar? Dela din favorit absurda RFC i kommentarerna. Och om du hittar en uppstoppad brevduva med DNS-poster – ho ho ho, hör av dig.