DNS Camel
Вообще-то, всё началось с e-mail и принятого для него формата записи адресов, который и лёг в основу DNS.
Всё было совсем безобидно – изначально появились два RFC, написанных Полом Моцкапетрисом (Paul Mockapetris), с описанием общей концепции и начальной спецификации протокола DNS объёмом в сотню страниц.
Начиная с конца 90-х годов начался лавинообразный рост количества документов, регламентирующих технологии DNS.
Проблемы начались с массового внедрения DNSSEC (DNS Security Extensions) (2000-е), интернационализации доменов (IDN) и других расширений, которые сделали протокол менее управляемым. Это начало вызывать некоторую настороженность.
В 2000 году на пленарной части IETF Рэнди Буш (Randy Bush) в свойственной ему манере выступил с докладом «DNS сегодня. Не перегрузили ли мы старую лошадь?» и сравнил в конце DNS с верблюдом. Затем последовала основательная работа Пола Викси (Paul Vixie) в ACM «DNS Complexity» в 2007 году и Джон Кленсин попытался описать, как всегда, всё и сразу в RFC8324 «DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look».
Но психологическим прорывом стал блестящий доклад Бёрта Хьюберта (Bert Hubert) в 2018 на IETF в Лондоне – «DNS Camel, или Сколько функций мы можем добавить к этому протоколу, прежде чем он поломается?»
Так, к 2018 году, по оценке Бёрта Хьюберта, существовало около 185 RFC, связанных с DNS, общим объёмом 2781 страница текста. По состоянию на 2025 год число RFC и объём материалов, связанных с DNS, увеличилось на треть.
Это число продолжает расти с развитием протокола, появлением новых требований к безопасности, масштабируемости и функциональности. Темпы роста новых документов и предложений по модернизации DNS составляют не менее 10-12 в год. Такой объём делает изучение и реализацию стандартов чрезвычайно трудоёмкими.
Количество специалистов, способных глубоко понимать DNS, сокращается. Сложность системы отталкивает новичков, а новые проекты прекратили развитие из-за сложности поддержки новых стандартов.
Это выступление и последующие статьи того же автора к нему были как крик души Бёрта обо всём наболевшем. Среди основных тезисов Хуберта были следующие:
– отрыв от нужд операторов, которые в абсолютном большинстве далеки от процессов стандартизации. Стандартизация развивается самими стандартизаторами – а именно относительно небольшой группой сверхквалифицированных разработчиков и экспертов из нескольких компаний. Тем более, что создание драфта и его публикация в виде RFC высоко оцениваются в резюме. Это существенно для построения карьеры. Многие работодатели высоко оценивают наличие таких результатов;
– рост количества текстов о стандартах DNS далеко не случаен, он основан на работе группы активных разработчиков стандартов, желающих внедрить их, а также с отсутствием сдерживающей обратной связи от операторов и других потребителей.
DNS — один из самых «перегруженных» стандартов в Интернете. Каждый новый RFC добавляет сложность, угрожая устойчивости системы. Для предотвращения дальнейшей «перегрузки верблюда» Бёрт предложил следующие меры:
– прекратить бездумно писать новые RFC;
– вводить новые стандарты только после создания и тестирования нескольких рабочих реализаций, чтобы избежать теоретических решений без практической пользы;
– переписать существующие RFC, объединив ключевые документы, такие как RFC 1034, 1035 и 2181, в современные и упрощённые версии, сократив объём документации;
– избавиться от неиспользуемых RFC;
– вложиться в создание обучающих ресурсов.
Почему же DNS продолжал и продолжает обрастать «заплатками»? Немного о ключевых группах дополнений в DNS – что же за груз несет верблюд?
Выделю несколько направлений расширения DNS, которые наиболее сильно повлияли на усложнение реализаций.
В начале 2000-х была поставлена задача внедрения интернационализованных доменных имён (IDN), которые содержат символы национальных алфавитов. Для кодировки используется Unicode, а для хранения в DNS как ASCII-строк используется транскрипция Punycode. До двух десятков только RFC связаны с этим.
Но с внедрением IDN до сих пор есть проблемы.
Так, концепция Universal Acceptance (UA) определяет, что все доменные имена, включая новые домены верхнего уровня (TLD), IDN и адреса электронной почты, должны рассматриваться одинаково и могут использоваться всеми приложениями, устройствами и системами, подключёнными к Интернету. Задача была сформулирована где-то 20 лет назад, но конца этому процессу не видно.
С конца 90-х годов, но особенно после 9/11 началась усиленная «торговля страхом» – опасения рисков в области безопасности. Это повлияло и на работы в области DNS.
Наиболее ярким примером является Domain Name System Security Extensions (DNSSEC). Протокол обеспечивает криптографическую аутентификацию данных, аутентифицированное отрицание существования и целостность данных, но не доступность или конфиденциальность.
Проблема, для решения которой изначально был предложен протокол (DNS cache poisoning), известна с начала 90-х и была просто искусственно реанимирована. На этапе внедрения мне так и не удалось добиться от инициаторов примеров случаев именно таких атак.
Изначально DNSSEC лоббировался силовыми агентствами и министерствами США, в дальнейшем был использован ИКАНН для усиления контроля за корневой зоной DNS. В результате внедрения поддержание своих (альтернативных/независимых) корневых зон стало крайне затруднено без утраты части функциональности.
Об удобстве эксплуатации и о том, насколько эти протоколы соответствуют реальной практике, речи изначально тоже не шло. По-прежнему требуется доработка спецификаций.
На базе DNSSEC создали ещё один довесок – DANE (DNS-based Authentication of Named Entities) – протокол, позволяющий использовать цифровые сертификаты X.509 в привязке к доменным именам. По сути, DANE был разработан по инициативе энтузиастов/лоббистов DNSSEС с идеей придумать что-нибудь полезное (компенсировать затраты) и стимулировать (повесить пряник) операторов и реестры. Эта попытка создать альтернативу системе CA (Certificate Authorities) в целом не удалась. Появление бесплатного LetsEncrypt CA дало реальную практическую альтернативу, при этом затраты на верификацию через DNSSEC существенно выше, что по-прежнему не стимулирует внедрение.
Нельзя не отметить ещё одну модную тему – борьбу со спамом, в основу которой положили блокировку по DNS в почтовых серверах: Domain-based Message Authentication, Reporting and Conformance (DMARC), Sender Policy Framework (SPF)/DomainKeys Identified Mail (DKIM).
Немного формального об этих стандартах, о появлении которых вспоминают чаще всего только при проблемах с доставкой почты, что меня никогда не радовало.
DMARC — это протокол аутентификации электронной почты. Он разработан, чтобы дать владельцам доменов электронной почты возможность защитить свой домен от несанкционированного использования, обычно известного как подмена электронной почты. Цель и основной результат внедрения DMARC — защитить домен от использования в атаках по компрометации деловой электронной почты, для фишинговых электронных писем и мошенничества с электронной почтой.
DMARC расширяет два механизма аутентификации электронной почты, SPF и DKIM.
SPF – метод аутентификации электронной почты, который должен гарантировать, что отправляющий почтовый сервер авторизован для отправки почты с домена отправителя электронной почты.
DKIM – ещё один метод аутентификации электронной почты, предназначенный для обнаружения поддельных адресов отправителей в электронной почте.
И, конечно, не без влияния разоблачений Сноудена, а также всё шире использующейся блокировки по доменным именам, были разработаны и внедряются дополнительные технологии для защиты от перехвата информации, а именно, DNS over TLS (DoT) и DNS over HTTPS (DoH).
DoT – сетевой протокол безопасности для шифрования и упаковки запросов и ответов DNS через протокол Transport Layer Security (TLS). Целью его является повышение конфиденциальности и безопасности пользователя путём предотвращения подслушивания и подмены данных DNS посредством атак типа «человек посередине».
DoH – протокол для выполнения удалённого разрешения DNS через протокол HTTPS. Задачей также является защита от перехвата и манипулирования данными DNS.
Малоизвестно, что бурное разрастание стандартов DNS с практическим игнорированием других технологий в случае с IP-протоколом не позволили реализовывать полную его функциональность в использовании/расширении адресного пространства.
Допускаю, что вместо бесконечных «заплаток» DNS, возможно, нужен более радикальный подход – такой, как разработка и внедрение децентрализованных решений: например, системы именования на основе блокчейна, которые могли бы заменить традиционный DNS или дополнить его, что более вероятно.
Нельзя сказать, что ничего не делалось по предложениям Бёрта.
Немногое, что приходит на ум, – это попытки со стороны OCTO (Office of Chief Technology Officer) ICANN, который выделил минимальные ресурсы в лице Пола Хоффмана и сделал попытку агрегировать RFC, связанные с DNSSEC, в единый RFC 9364 (он же Best Current Practice – BCP 237).
Но никаких действенных попыток свести вместе RFC, связанные с другими областями DNS, пока так и не предпринималось.
Единичные скептики, к которым относится Пол, сомневаются в мнении Бёрта и заявляют, что прошло шесть лет, а всё осталось как прежде и ничего не случилось. В принципе, и другие стандарты Интернета обросли подробностями и усложнились, но только в случае с DNS настолько обеспокоились о судьбе протокола.
Редкий случай, когда я склонен согласиться с Полом и смотрю на ситуацию с DNS оптимистичнее Бёрта и скорее солидарен с подходами Дейва Миллза (Dave Mills): «Интернет нельзя спроектировать – он должен расти и видоизменяться, опираясь на любые доступные технологии».
И для меня тоже DNS напоминает не перегруженного мула или верблюда с переламывающимся хребтом, а скорее всеядного вечно голодного монстра, которого ещё держат на поводке…
Image for illustration only. Created by Freepic.com.
