DNS през пощенски гълъби: Най-абсурдният протокол, който някога ще обикнеш

Да си призная нещо: прекарах доста смущаващо много часове в четене на IETF чернова със заглавието "DNS over Avian Carriers (DoAC)" и изобщо не съжалявам.

За тези, които не са имали това удоволствие, IETF е организацията, отговорна за техническите стандарти, захранващи съвременния интернет. Документите им обикновено са плътни, методични и дълбоко сериозни. Така че когато попаднеш на чернова, която сериозно предлага използването на гълъби за пренасочване на хост имена, обръщаш внимание — не защото е практично, а защото разкрива нещо fascinating за това как мислим за мрежовите протоколи.

Протоколният стек, който времето забрави

Историята започва през 1990 с RFC 1149, който въведе IP over Avian Carriers (IPoAC). Да, IETF публикува формална спецификация за пренасяне на IP датаграми чрез пощенски гълъби. Документът включва оценки за загуба на пакети ("приблизително 55% непретеглена"), изчисления на латентност и сравнения на пропускателна способност. През 2001 е актуализиран с RFC 2549 (поддръжка на Quality of Service за avian carriers) и отново през 2011 с RFC 6214 (съвместимост с IPv6).

Тези неща не бяха шеги — бяха легитимни експериментални протоколи, пълни с работещи имплементации и тестове в реални условия. Университети и хакерски групи наистина са разгръщали гълъбини мрежи за забавление и образование.

Ето какъв е проблемът обаче: в продължение на три десетилетия този протоколен стек имаше огромна дупка. Можеше да изпращаш IP пакети чрез гълъб, но не можеше да resolve-ваш domain names. Без DNS, всяка дестинация трябваше да бъде хардуерно кодирана като IP адрес върху птицата. Представи си да обясняваш на мрежовите си оператори, че добавянето на нов сървър изисква физическо претрениране на гълъбите ти.

Влиза DoAC: DNS за птиците

Черновата DoAC се опитва да реши този проблем с характерната си техническа сериозност. Тя дефинира:

• Формати на съобщения за DNS заявки и отговори, които могат да се прикрепят към гълъби
• AA (Avian Authority) Resource Record за публикуване на адреси на гълъбарници
• Поведение при препредаване, отчитащо непредсказуемата природа на avian доставката
• Процедури за bootstrapping, включително "Pigeon of Last Resort" за първоначално откриване на resolver

Вниманието към детайла е наистина впечатляващо. Секция 5.2 обсъжда "Resolver Discovery Without Prior State", признавайки, че първият ти гълъб не може да знае къде да намери DNS сървър, защото няма DNS, за да го потърси. Решението? Предварително конфигуриран спешен гълъб.

Съображения за сигурност, които звучат като документален филм за природата

Там, където DoAC наистина блести, е в анализа си на сигурността. Черновата идентифицира заплахи, включително:

• Hawk-in-the-Middle атаки, при които граблива птица прихваща заявката ти по средата на полета
• Pigeon spoofing и предложеното решение "Plumage-Based Authentication"
• Loft hijacking, при който атакуващ поема контрола над дестинацията ти
• Denial of Flight атаки (DoF) — по същество DDoS, но за птици
• Гладната котка като заплаха на физическия слой (самообясняващо се)
• Replay атаки чрез таксидермиран carrier (някой изпраща мъртъв гълъб със стари cached отговори)

Бих платил реални пари да видя red team да тества някои от тези вектори на атака.

Какво всъщност ни казва това

Ето нещото за абсурдните технически документи: те често са по-поучителни от смислените. DoAC те кара да се изправиш лице в лице с предположения, за които не си знаел, че правиш.

Когато използваш DNS днес, имплицитно се доверяваш на:

• Resolver-ите на твоя ISP няма да те лъжат
• Пакетите няма да бъдат прихванати или променени
• Сървърите ще са налични, когато имаш нужда от тях
• Физическата инфраструктура не ще дефектира катастрофално

DoAC прави всички тези имплицитни доверия експлицитни — и нелепи. Гълъбината мрежа няма смисъл за production системи, но упражнението да я проектираш разкрива точно колко много зависим от инфраструктура, която приемаш за даденост.

Истинският извод

Има урок тук за разработчиците, изграждащи модерни системи, особено тези, работещи с edge computing, mesh мрежи или прекъсваща свързаност:

Всеки протокол предполага базов транспорт със специфични свойства. Когато тези свойства се променят, ти трябват нови протоколи.

DNS през TCP/IP предполага надеждна, бърза доставка на пакети. DNS през Avian Carriers предполага... ами, че пакетите ти най-накрая ще пристигнат, вероятно, може би. Черновата DoAC не е просто шега — тя е напомняне, че "винаги включен, ниска латентност, висока надеждност" е лукс, не константа.

За стартъпи, изграждащи приложения за нововъзникващи пазари, селски райони или сценарии при бедствия, разбирането на тези компромиси има значение. IETF прекара 30 години в обмисляне какво се случва, когато мрежата ти е ято гълъби. Тази работа може да се окаже по-уместна, отколкото си мислиш.

Някога попадал ли си на протокол, който те накара да се усъмниш в предположенията си за това как работи мрежирането? Сподели любимия си абсурден RFC в коментарите. И ако си намерил таксидермиран гълъб с прикачени DNS записи, моля те, сподели какво се получи.