DNS через почтовых голубей: самый абсурдный стек протоколов, который вы когда-либо полюбите

Начну с признания: я потратил неприлично много времени на чтение черновика IETF под названием «DNS over Avian Carriers (DoAC)» — и ни капли об этом не жалею.

Для тех, кто не в курсе, IETF — это организация, которая отвечает за технические стандарты современного интернета. Их документы обычно плотные, методичные и до неприличия серьёзные. Так что когда натыкаешься на черновик, который всерьёз предлагает использовать почтовых голубей для разрешения доменных имён — на это обращаешь внимание. Не потому что это практично, а потому что за этим скрывается нечто по-настоящему интересное о том, как мы вообще думаем о сетевых протоколах.

Протокол, который забыли обновить

История началась в 1990 году с RFC 1149, который представил IP over Avian Carriers (IPoAC). Да, IETF опубликовала формальную спецификацию для передачи IP-датаграмм через почтовых голубей. Документ включает оценки потерь пакетов («примерно 55% без веса»), расчёты задержек и сравнения пропускной способности. В 2001 году вышло обновление — RFC 2549 (поддержка QoS для голубиной связи), а в 2011 — RFC 6214 (совместимость с IPv6).

Это были не шутки. Это были полноценные экспериментальные протоколы с рабочими реализациями и реальными испытаниями. Университеты и хакерские группы действительно разворачивали голубиные сети для обучения и развлечения.

Но вот проблема: три десятилетия этот стек протоколов имел огромный пробел. Можно было отправлять IP-пакеты через голубя, но нельзя было разрешать доменные имена. Без DNS каждый адресат приходилось зашивать в голубя в виде IP-адреса. Представьте, что добавление нового сервера требует физического переобучения ваших голубей.

DoAC: DNS для пернатых

Черновик DoAC пытается решить эту задачу с характерной технической серьёзностью. Он определяет:

• Форматы сообщений для DNS-запросов и ответов, которые можно прикрепить к голубю
• Ресурсную запись AA (Avian Authority) для публикации адресов голубятни
• Поведение при повторной передаче с учётом непредсказуемости авиадоставки
• Процедуру начальной загрузки, включая «Голубя последней надежды» для обнаружения резолвера

Внимание к деталям здесь искренне впечатляет. Раздел 5.2 обсуждает «Обнаружение резолвера без предварительного состояния» — ваш первый голубь не знает, где искать DNS-сервер, потому что у него нет DNS для поиска. Решение? Заранее настроенный аварийный голубь.

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

Там, где DoAC по-настоящему блистает, — это анализ угроз. Черновик идентифицирует:

• Атаки «Ястреб-посередине», когда хищник перехватывает ваш запрос на полпути
• Спуфинг голубей и предложенное решение — аутентификация по оперению
• Захват голубятни, когда атакующий берёт под контроль пункт назначения
• Атаки «Отказ от полёта» (DoF) — по сути DDoS, но для птиц
• Голодная кошка как угроза физического уровня (название говорит само за себя)
• Повтор атаки через чучело голубя (кто-то отправляет мёртвого голубя с устаревшими кэшированными ответами)

Я бы реально заплатил деньги, чтобы увидеть, как red team пытается реализовать хотя бы часть этих векторов атак.

Что это на самом деле нам говорит

Вот что интересно в абсурдных технических документах: они часто оказываются поучительнее разумных. DoAC заставляет столкнуться с предположениями, о которых ты даже не задумывался.

Когда вы используете DNS сегодня, вы неявно доверяете:

• Резолверам вашего провайдера, что они не врут вам
• Что пакеты не будут перехвачены или изменены
• Что серверы будут доступны, когда они нужны
• Что физическая инфраструктура не выйдет из строя катастрофически

DoAC делает всё это неявное доверие явным — и нелепым. Голубиная сеть не имеет смысла для продакшена, но сама попытка её спроектировать показывает, как много мы зависим от инфраструктуры, которую принимаем как должное.

Настоящий вывод

Для разработчиков, строящих современные системы — особенно на edge computing, mesh-сетях или при нестабильном подключении — здесь есть конкретный урок:

Каждый протокол опирается на транспорт с определёнными свойствами. Когда эти свойства меняются, нужны новые протоколы.

DNS через TCP/IP предполагает надёжную быструю доставку пакетов. DNS через почтовых голубей предполагает... ну, что пакеты в конце концов долетят, наверное, возможно. Черновик DoAC — это не просто шутка. Это напоминание о том, что «всегда онлайн, низкая задержка, высокая надёжность» — это роскошь, а не константа.

Для стартапов, которые строят приложения для развивающихся рынков, сельских районов или сценариев стихийных бедствий, понимание этих компромиссов критически важно. IETF тридцать лет думала о том, что происходит, когда ваша сеть — это стая голубей. Эта работа может оказаться актуальнее, чем вы думаете.

Вы когда-нибудь сталкивались с протоколом, который заставил вас усомниться в своих представлениях о работе сетей? Поделитесь своим любимым абсурдным RFC в комментариях. И если вы нашли чучело голубя с прикреплёнными DNS-записями — пожалуйста, расскажите, как прошло.