dxdt.blog: занимательный интернет-журнал

TLS-cертификаты для IP-адресов, которые собирается выпускать Let’s Encrypt, могут быть полезны и для решения задач внедрения DNS-over-TLS (DoT) на авторитативных серверах DNS. Аутентификационное имя DNS к узлу, поддерживающему DoT, привязать довольно сложно, а вот IP-адрес всегда есть. Другое дело, что DNS уже централизована дважды: через управление содержанием корневой зоны (это архитектурное требование DNS, позволяющее сохранять глобальность) и через управление корневым ключом DNSSEC (это архитектурное требование уже для глобальности DNSSEC, усиливающее позиции корня DNS). Если ещё и транспорт для DNS завести на центральный УЦ, то централизация усилится многократно. Конечно, возможно, это и является целью.

На тестовом сервере tls13.1d.pw сделал некоторые обновления: 1) детализировал вывод шифротекста ML-KEM-768, разбив блок на представления отдельных полиномов; 2) добавил поддержку SecP256r1MLKEM768 – это гибридная криптосистема с постквантовой стойкостью, состоящая из ECDH на кривой P-256 и ML-KEM-768.

Я не так давно писал про статистику соединений с постквантовыми криптосистемами на тестовом сервере, и в той записке обозначил, что SecP256r1MLKEM768 поддерживается сервером, но это оказалось преждевременным, так как в действительности сервер поддерживал ECDH на P-256 только в старом варианте, с Kyber768. А про вариант ECDH с ML-KEM я как-то забыл. Впрочем, на основное утверждение упомянутой записки о том, что с SecP256r1MLKEM768 (идентификатор 0x11EB) на сервер в начале января никто не приходил, этот момент никак не повлиял: понятно, что если никто не пытался подключиться с этой криптосистемой, то и соединения быть не могло, вне зависимости от поддержки сервером.

(Если кто-то из читающих не знает, то данный тестовый сервер TLS 1.3 это достаточно специальный инструмент, позволяющий подключиться по TLS 1.3, отправить HTTP-запрос и получить очень подробные сведения о соединении в ответ. Это можно проделать браузером, чтобы, например, увидеть, работает ли какой-то низкоуровневый элемент TLS, типа обмена ключами с постквантовой стойкостью.)

Кстати, забавно, что в SecP256r1MLKEM768 ключи и секреты объединяются в другом порядке, относительно X25519MLKEM768, описанной в том же черновике RFC. То есть, эти гибридные криптосистемы используют объединение значений, соответствующих работе двух криптосистем. Объединение – при помощи простой конкатенации байтов. Например, объединяется запись открытого ключа ECDH (65 байтов) и запись открытого ключа ML-KEM-768 (1184 байта): одни байты приписываются к другим и получается блок в 1249 байтов. Ничего необычного. Но вот для X25519 и ML-KEM, если смотреть слева направо, в сетевом порядке, то сперва идёт ключ ML-KEM, а потом – ключ X25519. Для ECDH и ML-KEM, определяемой в следующем же абзаце черновика, указан другой порядок: сперва параметр ECDH, а потом – ключ ML-KEM. То же самое с общими секретами. Зачем так делать? Загадка. Какая-то “популярная квантовая механика” на пустом месте. (Никакого криптографического смысла в этом нет и быть не может: криптосистемы, составляющие гибрид, работают независимо.)

Очень популярное заблуждение: DNS использует только UDP. Это заблуждение постоянно мешает на практике. Конечно, протокол UDP является основным протоколом обмена данными между клиентами и серверами в DNS. Это так. Однако UDP используется при наличии возможности, а DNS, как система, строго требует доступности серверов и по TCP. Причём, TCP является ничуть не менее “стандартным” протоколом для DNS. То есть, необходима поддержка и UDP, и TCP.

Хрестоматийный исторический пример использования TCP вместо UDP в DNS, это превышение максимального объёма данных, которые удаётся передать по UDP. Здесь часто упоминают 512 байтов, как предельное количество. Но, опять же, то и дело упускают контекст, к которому лимит в 512 байтов относится. Эти знаменитые 512 байтов, во-первых, происходят из принципов фрагментации пакетов в IP-сетях, – так-то в UDP можно передать гораздо больше, – да ещё и относятся, как ограничение, конкретно к классическому DNS: то есть, из-за 512 байтов в Интернете 13 логических корневых серверов DNS, например. Сетевые детали оставим для другой записки, а в этой важно отметить, что и лимит давно не 512 байтов, потому что есть расширение под общим названием EDNS, позволяющее задать другие границы данных ответа сервера, и возможность увеличения размера UDP-ответов пакета никак не отменяет требований по TCP.

Это всё весьма упрощенное описание. За DNS скрывается очень сложная технология, непосредственно использующая множество весьма и весьма нетривиальных особенностей в своих протоколах. Очень большой ошибкой будет посчитать, что DNS – это “запрос-ответ” про “IP-адрес”. Это только “понятийное ядро” DNS на самом базовом уровне возможно описать как элементарный протокол “запрос-ответ”. При изучении же деталей придётся быстро столкнуться с неожиданными артефактами. Например, с тем, что в DNS есть сжатие строк в DNS-сообщениях, куча хитрых статусов и флагов. Реально работающая система изобилует неожиданными “краевыми случаями”. Вот, кстати, один из примеров: рандомизация регистра символов в DNS. И это, заметьте, тут ещё ничего не сказано про DNSSEC.

В общем, вернёмся к TCP/UDP. Верная интерпретация такая: если DNS-ответ имеется, но не получается доставить его полностью по UDP, то система должна использовать TCP. Следовательно, должен быть TCP-доступ. И вовсе не только между авторитативными серверами для трансфера зоны.

К сожалению, сплошь и рядом продолжают фильтровать и отключать TCP-доступ даже к авторитативным серверам DNS, мотивируя это тем, что, мол, “DNS работает по UDP”, а поэтому прочий доступ нужно закрыть “для безопасности” (хотя, казалось бы, при чём здесь метод “порты закрыл – сервер в безопасности”?). Это неправильно и плохо: резолверы могут штатно подключаться к DNS-серверам по TCP, если им не удаётся работать по UDP, а в DNS описан типовой механизм (Truncated bit), позволяющий сообщить клиенту (резолверу), что нужно переключиться на TCP. Но это только возможный способ. Резолвер, вполне штатно, может самостоятельно перейти на TCP, если этого требует контекст запроса и сетевая конфигурация. Так что DNS работает и по TCP тоже.

Немного занятной и техничной практики DNS. Если взять зону kommersant.ru, то нетрудно выяснить, что с этой зоной что-то сильно не так. Вот “покрасневший” скриншот из отчёта открытого сервиса audit.statdom.ru:

Почему тут указаны только “адреса”, которые отмечены как недоступные? Во-первых, это не адреса, а имена хостов (хостнеймы), которые выглядят похожими на IP-адреса, но намётанный глаз сразу обнаружит подвох: всё выдаёт крайняя справа точка, отделяющая корневой домен; это так называемый FQDN – Fully Qualified Domain Name (“полное имя домена”). Во-вторых, серверы имён, обозначенные таким образом, доступны быть не могут, поскольку в глобальной DNS нет имени первого уровня “20.” (две цифры – 2 и 0).

Между тем, если попробовать зайти на соответствующий апексу зоны веб-сайт kommersant.ru браузером, то, скорее всего, сайт откроется. Получается, что всё работает? Нет, далеко не всё. Но это лишь очередное подтверждение того, что DNS, как сервис и совокупность технологий, в сочетании с вебом, обладает очень высокой степенью устойчивости к ошибкам настройки (кроме, конечно, DNSSEC).

Посмотрим, как же настроена зона kommersant.ru на момент написания данной записки. В домене верхнего уровня RU зона делегрована на два сервера имён (NS) с именами ns.kommersant.ru. и ns5.kommersant.ru., что, скажем, подтверждается следующим фрагментом скриншота того же отчёта:

Поскольку это так называемые “субординатные” имена NS, – то есть, находящиеся в той же зоне, которая делегируется, – серверы зоны RU возвращают соответствующие glue-записи (в отчёте они не показаны). Glue-записи содержат IP-адреса для имён делегирования (ns.kommersant.ru. и ns5.kommersant.ru.). В DNS, glue-записи необходимы для того, чтобы исключить возможность бесконечной рекурсии. Представьте, что зона test.ru делегирована на ns.test.ru. Как же определить IP-адрес ns.test.ru? Ведь для его определения нужно знать адреса NS-ов зоны test.ru, а чтобы их знать, нужно опросить зону test.ru. Как найти адреса? Верный ответ – никак не найти, если бы только не было glue-записей, которые-то и приносят нужные адреса сразу.

Почему здесь вообще возникает такая проблема с аресами/именами? Потому, что в качестве значения DNS-записи NS могут быть указаны только имена хостов. Но соединение и обмен данными в глобальном Интернете происходят по IP. То есть, для отправки запросов и получения ответов нужны именно IP-адреса. Можно ли всё же указать IP-адреса в NS-записях? Нет, нельзя. Причина в том, что значения записей в DNS не могут подразумевать какой бы то ни было протокол обмена данными. Это очень важный и логичный момент: DNS превратилась бы в непонятную путаницу, если бы какие-то дополнительные сведения об установлении соединения “подразумевались” бы: в той же NS-записи – получаем то адрес, то хостнейм, то “какие-то минусы”, то “здесь админы рыбу заворачивали”. Заметьте, сюда ещё накладывается и тот занимательный факт, что вообще невозможно вне контекста отличить запись IPv4-адреса от хостнейма. В практике DNS есть много случаев, когда тот или иной протокол доступа, да ещё и с параметрами, прямо указывается, но корректно это делается только при помощи префиксов в самом имени, например: _443._tcp.name.test.ru. (обратите внимание: предыдущая DNS-строка – не хостнейм!).

Итак, NS-запись должна содержать имя хоста, соответствующее серверу имён. Для разрешения возможных циклов – предусмотрены glue-записи.

Однако доверенным источником полного списка серверов имён для зоны является не делегирующий сервер, не glue-записи, а ответ авторитативного сервера зоны на запрос NS. По этой причине сервис тестирования DNS-узлов получает список этих узлов с авторитативного сервера. Ну, или пытается получить. Серверы, указанные для kommersant.ru в списке делегирования, на запрос NS возвращают те самые “подложные” хостнеймы, сформированные из IP-адресов четвёртой версии. То есть, так указано в файле зоны. Указано неверно. Распространённая ошибка. Видимо, ничего не поделать. Отличить тут адрес от хостнейма программное обеспечение не может, поэтому DNS-сервер будет отвечать тем, что ему написано. А написаны, как уже указано выше, заведомо “неразрешимые” имена (нет, это не IP-адреса; IP-адреса нельзя указывать в NS-записях, поэтому резолвер никак и не может понять, что это, якобы, “IP-адреса”, потому что это хостнеймы).

Почему же работает веб-сайт? Вот почему. Для большинства сценариев доступа к вебу нужен IP-адрес, который передаётся в A-записи DNS. По IP-адресам из glue-записей для обсуждающейся зоны kommersant.ru отвечают серверы имён, которые возвращают A-записи, содержащие корректный и доступный IP-адрес, который указывает на веб-узел. И тут многое зависит от рекурсивного резолвера. Если этот резолвер использует непосредственно адреса из glue-записей для того, чтобы запросить A-записи, то всё сработает. Но glue-записи небезопасно кэшировать – кэшировать следовало бы хотя бы минимально проверенные значения NS, которые требуется достать с авторитативных серверов. Если резолвер попробует получить список NS корректным способом, то он обнаружит дефектные записи, после чего попробует отправить ещё несколько запросов и, скорее всего, всё же найдёт A-запись, чтобы вернуть её клиенту. То есть, резолвер, обычно, настроен так, чтобы хоть что-то достать из DNS (не всегда это правильный выбор, поскольку регулярно служит фундаментом для целевых атак). Так что, спрашивая и переспрашивая, игнорируя и как-то исправляя ошибки в зоне, но резолвер, в большинстве случаев, сможет найти IP-адрес, чтобы потом по этому адресу попробовал подключиться браузер, если только способ достать данный IP-адрес существует. Что же касается других функций DNS – ну, они в данной зоне просто недоступны (тем более, что упомянутые серверы имён не поддерживают современный EDNS-доступ вообще).

Вот. У подобной некорректной настройки DNS есть ещё много неприятных побочных эффектов, связанных с надёжностью и безопасностью. А ведь существует ещё и QNAME Minimization.

(Недавно я описывал другую занятную ошибку настройки DNS, из “дикой природы”, наблюдающуюся в куда более популярной зоне vk.com. Представьте, кстати, куда все эти интернеты прикатятся, если DNSSEC, – несравнимо более требовательная к уровню аккуратности технология, – вдруг получит максимальное распространение.)

(Update, 30.01.2026: в январе 2026 года настройки DNS для зоны kommersant.ru поменяли, и описанный выше эффект наблюдаться перестал; что, конечно, не отменяет важности описанных в этой заметке технических моментов.)

В массовом TLS для веба криптосистемы с постквантовой стойкостью уже имеются, но есть ещё немало направлений, где такие криптосистемы нужны (если учитывать “угрозу квантовых компьютеров”, конечно). И во многих случаях требуются не криптосистемы согласования симметричного секрета, как в случае внедрения ML-KEM для TLS, а криптосистемы подписи. Можно, например, посмотреть в сторону DNS и DNSSEC, пусть последняя и не очень-то распространена, но там требуется именно электронная подпись. В DNS всегда приветствовались короткие пакеты данных, без излишнего раздутия. В предлагаемых сейчас постквантовых криптосистемах, традиционно, ключи и/или подписи – очень большие. Как это будет упаковываться в DNS – пока что не очень понятно: десять, предположим, килобайт на подписи с ключами – для DNS это слишком много.

Вообще, уже из распространённого предположения, что симметричные шифры сохраняют достаточную стойкость перед “квантовыми атаками”, можно сделать вывод, что возможны и короткие подписи, – то есть, что-то асимметричное, – главное, чтобы такие криптосистемы оказались ещё и эффективными: проверка 256-битной подписи, занимающая один час, тоже не особенно хороший вариант.

Длины ключей/подписей в текущем состоянии постквантовой криптографии и “квантовых вычислений” тема довольно странная: с одной стороны, как оно могло бы преобразовываться на “квантовом компьютере” не ясно, но если исходить из того, что для RSA нужна тысяча “квантовых элементов” компьютера на один бит ключа, то и для RSA можно просто добавить несколько килобит, получив практическую постквантовую стойкость – в конце концов, стойкость к обычным атакам для RSA развивалась именно так: 512-битный ключ сейчас можно факторизовать достаточно быстро для того, чтобы практическую разрядность передвинули к 2048 битам. С другой стороны, нет никаких гарантий того, что для задач, лежащих в основе уже стандартизованных постквантовых систем, тоже не найдут эффективных квантовых алгоритмов.

Поэтому, кстати, довольно странно читать в популярных статьях и новостных сообщениях по этой теме, что “сложность решения задач не отличается для обычных и квантовых компьютеров”. Ведь вовсе и не предполагается, что квантовые компьютеры что-то там вычисляют, так что вообще странно сравнивать сложность для “обычных и квантовых” компьютеров, поскольку там разные модели. При этом: и для классических атак (на “обычном компьютере”) на постквантовые криптосистемы возможны улучшения, и всякий квантовый алгоритм можно выполнить на классическом компьютере, и ту же задачу факторизации “нетрудно” очень быстро решать для произвольных больших чисел, если только вычислитель обладает быстрой памятью в объёме факториала от обрабатываемого числа (“небольшая” особенность, да).

Естественно, длина ключей постквантовых подписей диктуется и скоростью работы на практических компьютерах, и требованиями стойкости к атакам на этих практических классических компьютерах: улучшат такие атаки – разрядность (в том или ином виде) придётся увеличивать, вне зависимости от того, появились уже подходящие квантовые компьютеры или нет (собственно, посмотрите на тот же ML-KEM – бывший Kyber, – там уже сейчас несколько вариантов с разной классической стойкостью).

Но вернёмся к DNS и TLS. Можно предположить, что если “огромные постквантовые ключи” в данную систему не влезут, а уменьшить длину ключей не получится, то, скорее всего, из этого выйдет лишь ещё одна причина для повсеместного перехода на очередной вариант “DNS-over-TLS”: мол, там постквантовая стойкость уже есть, а то, что задача решается совсем другая – аутентификация узлов, а не защита подлинности данных, – ну так придётся как-то скорректировать модель угроз и привыкать “к новым подходам”. Впрочем, возможны и какие-то не использующие TLS, но существенно более интерактивные, варианты на замену DNS, поскольку именно интерактивность позволяет встроить более компактные схемы проверки подлинности данных. Речь тут про схемы, когда и конкретный запрос формируется с учётом некоторого ключа, и ответ приходит – тоже с учётом состава сессионных ключей из запроса и долгих ключей “из DNSSEC”. Возможны, скажем, варианты алгоритма Диффи-Хеллмана (постквантового, конечно). Поэтому, если темпы внедрения постквантовой криптографии не ослабеют, то можно ожидать новой, “интерактивной DNS”.

В TLS для веба важны имена. Например, при подключении по TLS для HTTPS серверу нужно отправить клиенту TLS-сертификат сервера. Если серверных сертификатов несколько, то сервер должен как-то выбрать подходящий по имени. Тут речь не про промежуточные сертификаты, которые добавляются в набор (bundle), а именно про оконечные сертификаты. Если TLS-cертификат не соответствует имени, которое ожидает клиент-браузер, то сессия не будет корректной на стороне клиента. Данный момент, вместе с желанием держать много виртуальных хостов на одном IP-адресе и под одним веб-сервером, является постоянным источником ошибок администрирования.

Посмотрим, что вообще происходит в ходе обработки HTTPS-сеанса и как сервер может определить соответствие имён. В начале TLS-сессии клиент (браузер) обычно передаёт имя сервера в специальном блоке данных – SNI (Server Name Indication). Сервер видит это имя и может использовать его для поиска нужного сертификата и нужного виртуального хоста. Однако клиент определяет имя из своих собственных соображений.

Типовой вариант: в контекст TLS-сессии имя узла SNI приходит из запроса пользователя через DNS. Почему “через DNS”? Потому что браузер должен был найти IP-адрес, к которому он подключается по TCP. При прочих равных, браузер получил IP-адрес из DNS по имени хоста из URL, заданного пользователем. Это действительно важный момент, который, почему-то, инженеры DevOps регулярно выкидывают из области рассмотрения, посчитав “элементарным”. Однако, во-первых, если пользователь ввёл имя, которое не удалось “разрезолвить” в IP-адрес, то и штатного TLS-соединения не случится, хоть бы такое имя и было указано в сертификате (такое вполне возможно). Это, предположим, “элементарная часть”, которая, тем не менее, никак не отменяет возможности указания в SNI имени без DNS-адреса, то есть, без A-, AAAA-записей. Во-вторых, кто угодно может настроить какое угодно допустимое DNS-имя так, чтобы оно показывало на заданный IP-адрес сервера, а потом отправить ссылки с этими именем хоста ничего не подозревающим пользователям. В этом случае, пользователь, штатно набрав это самое “какое угодно” имя хоста, успешно направит браузер на заданный сервер, но браузер обратится туда с “неожиданным” именем в SNI. Если это имя вдруг совпадёт с указанным в предоставленном по умолчанию валидном TLS-сертификате с успешным подтверждением, то браузер даже не выдаст предупреждения, а в сертификате может быть очень много разных имён. (Но, во многих случаях, можно смело считать валидный серверный TLS-сертификат с верным именем достаточной мерой защиты от “ложных” хостов для HTTPS. Особенно, если веб-сервер основного имени хоста доступен по выделенному IP-адресу.)

Основной вывод предыдущего абзаца такой: сервер ориентируется на SNI, но нельзя считать, что SNI, присланное клиентом, как-то привязано к серверным настройкам, соответствует DNS, “защищено сертификатом” и вообще укладывается в формат и ожидания, отражённые в конфигурационном файле веб-сервера. И SNI вообще может отсутствовать. (Кроме того, тут не рассматривается случай, когда данные SNI скрываются от третьей стороны – метод ECH и пр.) На стороне веб-сервера бывает возможность отклонить TLS-соединение, использующее “неожиданное” имя хоста.

На начальном этапе соединения, до получения HTTP-запроса, сервер видит только имя из сеанса TLS. Но это не означает, что и сами HTTP-запросы будут адресованы этому же имени хоста – в HTTP-запрос тоже можно вписать что угодно, TLS никак семантику HTTP не фиксирует. Конечно, ситуация не является типичной для браузеров, но она вполне возможна. Это тоже нужно учитывать при обработке разных внутренних переменных на серверной стороне: контекст TLS, контекст HTTP – разные контексты.

Описание предназначения системы доменных имён Интернета (DNS) нередко сводится к упоминанию про сопоставление “символьного имени” (имя хоста) и “цифрового адреса” (IP-адрес). Но это лишь одна из самых часто используемых функций, которые реализует DNS. Общее же, полное представление о DNS нужно составлять по другой модели: DNS – это глобальная, распределённая база данных, использующая концепцию “ключ-значение”, с иерархическим индексом имён ключей, дополнительной типизацией записей и управляемым кэшированием. В случае поиска IP-адресов для веб-узлов в качестве ключа используется имя узла (хостнейм, доменное имя), а в качестве искомого значения – IP-адрес (или несколько адресов), при этом используется тип записи – A-запись.

То есть, для определения IP-адреса test.ru в глобальной DNS производится поиск “документа” по ключу “test.ru” с извлечением из этого “документа” A-записи, в которой содержится IPv4-адрес. A-записи – это малая часть. В DNS хранятся данные многих типов, например: AAAA – адреса IPv6, MX – имена почтовых серверов, SSHFP – отпечатки хост-ключей SSH и др. При этом, хоть A-записи и очень важны для работы самой DNS, они не являются основными. Основные записи, в смысле иерархии, это SOA-записи (определение основных параметров доменной зоны) и NS-записи (определение списка серверов имён).

DNS позволяет выполнять обратное преобразование – IP-адрес в символьное имя. Но для этого всё равно используется схема “ключ-значение”, где в качестве ключа выступает DNS-имя так называемой обратной зоны, которое формируется из октетов (байтовых элементов) IP-адреса. Это имя располагается в технической зоне .ARPA. То есть, никакого “обратного” поиска “ключа” по “значению” – в DNS нет, но есть прямой поиск записей в специально сконструированных обратных зонах по значению имени, взятому в качестве ключа. Пример обратной зоны: 1.1.1.1.in-addr.arpa – соответствует IPv4-адресу 1.1.1.1 (сервис Cloudflare one.one.one.one).

Если обратную зону в DNS не внести, то и определить через DNS соответствие IP-адреса символьному имени только по IP-адресу и штатным способом – не выйдет. (Но, конечно, можно просканировать все доступные доменные зоны по всем доступным ключам (именам) на предмет A-записей и, таким образом, найти имена, соответствующие данному IP в прямой записи; этих имён может быть очень много.)

Поиск записей в DNS производят программы-резолверы, которые опрашивают DNS-серверы в соответствии с иерархией ключей (DNS-имён): так, tls.dxdt.ru – это имя третьего уровня, находящееся внутри dxdt.ru, а dxdt.ru – второго уровня внутри .ru, а ru – первого уровня внутри корневого домена, имя которого состоит из пустой строки и, при использовании полной записи, тоже отделяется точкой справа, вот так: tls.dxdt.ru. – здесь корневой домен идёт после крайней правой точки. Совокупность программ и протоколов, используемых для поиска в DNS, тоже нередко обозначается буквами D, N и S, но здесь S – это сервис (service), то есть, речь уже идёт про сервис доменных имён.

Основой работы DNS как сервиса является кэширование данных на разных уровнях, в основном, кэширование обеспечивают программы-резолверы. Кэширование решает две основных задачи: это исключение излишней нагрузки и сохранение доступности при кратковременных отказах. Для обеспечения работы сервиса, записям, публикуемым в DNS, сопоставляются различные технические параметры, самый важный из них – это TTL (Time To Live), значение которого позволяет определять динамические параметры кэширования.

При штатной работе, DNS действует именно как база данных: из неё извлекаются далеко не только IP-адреса узлов, про которые так часто пишут, но и списки имён серверов, значения ключей и подписей DNSSEC, значения TXT-записей. Так как DNS является в Интернете всеобъемлющей системой, то и DNS-записи, отличные от A- и AAAA-записей, постоянно используются. Так, TXT-записи, позволяющие опубликовать под заданным именем текстовую строку, повсеместно используются для подтверждения тех или иных прав по управлению доменной зоной, например, при выпуске TLS-сертификатов или при публикации “почтовых” ключей DKIM.

В конце 2022 года я добавил в DNS для dxdt.ru HTTPS-запись, которая тогда была описана в черновике RFC. В ноябре 2023 года черновик стал RFC 9460, где определяется способ публикации в DNS дополнительной информации о параметрах подключения к сервисам, связанным с данным именем. Например, это могут быть параметры для TLS/HTTPS, в том числе, ключи (см. ECH). Особенность использования DNS тут в том, что параметры можно получить до подключения, это, в свою очередь, позволяет устанавливать скрытые подключения.

Кстати, насчёт того, было ли известно о различных векторах DoS-атак, которые с собой приносит DNSSEC (это касательно свежих CVE с коллизиями ключей и подписей). Я, ради интереса, посмотрел, что я писал в книге “Доменные войны II”, вышедшей ещё в 2011 году, и там на странице 269 сказано следующее:

“Уже понятно, что DNSSEC создаст новые возможности для атак типа “отказ в обслуживании” (DoS), ведь криптографические процедуры защищённой DNS гораздо более ресурсоемки, в вычислительном смысле. Злоумышленники при помощи отправки системам, поддерживающим DNSSEC, “дефектных” наборов данных смогут с большей, относительно “классической” DNS, легкостью занять все вычислительные ресурсы компьютера проверкой “бессмысленных” адресных данных.”

Это, конечно, достаточно общее рассуждение, но оно отражает ситуацию. Добавлю, тем не менее, что про совпадение тегов и, соответственно, про дополнительную “комбинаторную нагрузку” алгоритмов проверки DNSSEC-подписей, известно давно (это есть и в RFC, и в статье по ссылке выше – не новость), да и не все реализации стараются проверять все комбинации ключей. Другое дело, что специалистов, достаточно глубоко разбирающихся в соответствующих областях, – а также и во многих смежных областях, что тут необходимо, – в мире очень мало, что бы там ни писали СМИ и ни говорили на конференциях, и упомянутые специалисты, обычно, заняты чем-то другим, поскольку конкретные решения в этих областях не только мало кому понятны, но ещё и мало кого интересуют: это же не шумный подход в стиле “истина рождается в споре”. Так что моменты конкретных демонстраций атак на известных направлениях наступают в своё время, а в том, что некоторый класс атак был возможен два десятка лет – нет ничего удивительного. Таких классов и направлений в интернетах ещё много.

Естественно, это никоим образом не отменяет актуальности конкретных современных атак на конкретные современные системы.

Опубликована исходная работа, описывающая создание DoS-атак на резолверы при помощи специально сконструированных зон с коллизиями (совпадениями) идентификаторов ключей. Совпадение – это именно тот случай, который я недавно описывал на примере конкретной зоны. Там, конечно, не только совпадающие идентификаторы/теги используются, но они имеют определяющее значение, поскольку заставляют валидирующий резолвер перебирать большое количество ключей. Цитата:

Evaluating KeySigTrap, we set up a zonefile with 582 colliding DNSSEC keys and 340 signatures.

Это CVE-2023-50387.

(via)

У DNSSEC свои особенности. Так, эта технология вносит в древовидную структуру глобальной DNS хрупкость. Дело в том, что “обычная” DNS мало восприимчива к дефектам и ошибкам в реализации, а вот DNS с DNSSEC, из-за свойств используемой криптографии, напротив – очень сильно восприимчива. И древовидная структура тут только усиливает всякую проблему: авария в одной вершине дерева может привести к обрушению кучи ветвей.

DNSSEC, в имеющейся реализации, усиливает централизацию глобальной DNS, так как единство корня оказывается скреплено ещё и криптографическими ключами. На закате очередного “цивилизационного” этапа, в условиях наступления Нового Средневековья, такая централизация не обязательно составляет преимущество. Современные профильные концепции подразумевают управление доверием на уровне приложений для конечных пользователей и провайдеров сервисов для этих приложений: вот ключ сервера, а вот – ключ приложения, по этим ключам они узнают друг друга, транспорт, промежуточные узлы – это всё не так важно, когда Интернет нарезан на виртуальные интернеты, а тем более не важна степень централизации упомянутого транспорта.

С сугубо прикладной точки зрения, DNS с DNSSEC – это глубокая, непонятная технология: пользователь даже не имеет возможности кликнуть по кнопке “Всё равно продолжить”, поскольку, в случае сбоя, до контекста такой кнопки дело не доходит – сломался не сам привычный механизм, а пропало действие древнего, 16-битного, заклинания, вводившего в окружающую действительность законы работы механизма.

Будущее DNSSEC остаётся туманным.