DNS galambposta felett: A legbizarrabb protokoll-stack, amit valaha imádni fogsz

Kezdjük egy vallomással: irracionálisan sok időmet töltöttem az IETF egyik tervezetének olvasásával, ami a "DNS over Avian Carriers" (DoAC) címet viseli. És egy cseppet sem bánom.

Akik nem ismerik: az IETF az a szervezet, amely a modern internet technikai szabványait készíti. A dokumentumaik jellemzően sűrűek, módszeresek és halálosan komolyak. Szóval amikor az ember találkozik egy olyan tervezettel, ami komolyan felveti, hogy postagalambokkal oldjuk meg a hostname-feloldást, azonnal odafigyel – nem azért, mert praktikus, hanem mert valami elképesztően érdekeset árul el arról, hogyan gondolkodunk a hálózati protokollokról.

A protokoll-stack, amit az idő elfelejtett

A történet 1990-ben kezdődött az RFC 1149-cel, ami az IP over Avian Carriers (IPoAC) bevezetéséről szól. Igen, az IETF hivatalosan publikált egy specifikációt arra, hogyan lehet IP csomagokat galambokon keresztül küldeni. A dokumentum packet loss becsléseket tartalmaz ("körülbelül 55% súlyozatlan"), késleltetési számításokat és throughput összehasonlításokat. 2001-ben frissítették RFC 2549-cel (QoS támogatás avian carrier-ekhez), majd 2011-ben RFC 6214-gyel (IPv6 kompatibilitás).

Ezek nem poénok voltak – teljes értékű, kísérleti protokollok voltak, működő implementációkkal és valós tesztekkel. Egyetemek és hacker csoportok ténylegesen használtak galamb-alapú hálózatokat szórakozásra és tanulásra.

De itt jön a probléma: harminc éven át ez a protokoll-stack egy hatalmas űrt hagyott. IP csomagokat küldhettél galambon, de domain nevet nem tudtál feloldani. DNS nélkül minden célpontot közvetlenül IP címként kellett "felültetni" a madárra. Képzeld el, hogy a hálózati csapatodnak kell magyaráznod: új szerver hozzáadásához fizikailag újra kell treníroznod a galambjaidat.

DoAC: DNS a madaraknak

A DoAC tervezet ezt igyekszik megoldani, mindenre kiterjedő technikai komolysággal. A következőket definiálja:

• Üzenetformátumok DNS query-khez és válaszokhoz, amelyek galambokhoz rögzíthetők
• Az AA (Avian Authority) Resource Record a lakóhelyek címének publikálására
• Újraküldési viselkedés figyelembe véve az avian delivery kiszámíthatatlan természetét
• Bootstrap eljárások, beleértve a "Last Resort Pigeon"-t a kezdeti resolver felfedezésére

A részletekre fordított figyelem tényleg lenyűgöző. Az 5.2-es szekció tárgyalja a "Resolver Discovery Without Prior State"-t, elismerve, hogy az első galambod nem tudja, hol talál DNS szervert, mert nincs DNS, ami megmondaná neki. A megoldás? Előre konfigurált vészhelyzeti galamb.

Biztonsági megfontolások, amik úgy hangzanak, mint egy természetfilm

Ahol a DoAC igazán remekel, az a biztonsági elemzés. A tervezet azonosítja a fenyegetéseket, többek között:

• Hawk-in-the-Middle támadások, ahol egy ragadozó madár interceptálja a query-d a repülés közben
• Galamb-spoofing és a javasolt megoldás: "Tollazat-alapú autentikáció"
• Lakóhely-eltérítés, ahol egy támadó átveszi az irányítást a célpont felett
• Denial of Flight támadások (DoF) – lényegében DDoS, csak madarakra
• A Éhes Macska mint Fizikai Réteg Fenyegetés (magáért beszél)
• Replay támadások kitömtött galambon keresztül (valaki egy régi, cached válaszokkal teli elhullott galambot küld vissza)

Kétségtelenül fizetnék azért, hogy lássam, ahogy egy red team megpróbálja ezeket a támadási vektorokat kipróbálni.

Mit tanít ez nekünk valójában

Az abszurd technikai dokumentumokról tudni kell: gyakran informatívabbak, mint az értelmesak. A DoAC arra kényszerít, hogy szembenéz azokkal a feltételezésekkel, amiket észre sem vettél, hogy meghoztál.

Amikor ma használod a DNS-t, implicit módon megbízol:

• Az ISP-d resolverei nem hazudnak neked
• A csomagok nem lesznek elfogva vagy módosítva
• A szerverek elérhetők lesznek, amikor kell
• A fizikai infrastruktúra nem fails catastrophically

A DoAC mindezeket az implicit bizalmakat explicit módon abszurddá teszi. Egy galambhálózat nem éri meg a production rendszerekhez, de a tervezése elárulja, mennyire függünk az infrastruktúrától, amit理所当然-nak veszünk.

A lényeg

Van egy lecke a fejlesztőknek, különösen azoknak, akik edge computing-gal, mesh network-ekkel vagy intermittáló kapcsolattal dolgoznak:

Minden protokoll feltételez egy mögöttes transportot specifikus tulajdonságokkal. Amikor ezek a tulajdonságok megváltoznak, új protokollokra van szükség.

DNS over TCP/IP feltételezi a megbízható, gyors packet delivery-t. DNS over Avian Carriers feltételezi... nos, hogy a csomagjaid végül megérkeznek, valószínűleg, talán. A DoAC tervezet nem csak egy vicc – emlékeztető, hogy az "always-on, low-latency, high-reliability" luxus, nem állandó.

Startupoknak, amelyek fejlődő piacokra, vidéki területekre vagy katasztrófahelyzetekre építenek, fontos megérteni ezeket a trade-off-okat. Az IETF 30 évet töltött azzal, hogy végiggondolja, mi történik, ha a hálózatod egy galambcsapat. Ez a munka relevánsabb lehet, mint gondolnád.

Találkoztál már protokollal, ami elgondolkodtatott azzal kapcsolatban, hogyan működik a networking? Oszd meg a kedvenc abszurd RFC-det kommentben. És ha találtál egy DNS rekordokkal teli kitömtött galambot, kérlek, írd meg, hogy sikerült.