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

Немного занятной и техничной практики 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 остаётся туманным.

Интересно, что Google Public DNS (8.8.8.8) при взаимодействии с зоной dnssec.pw, которую я на днях снабдил ключами с одинаковыми тегами, продолжает возвращать неконсистентные результаты, если спрашивать об отсутствующих в зоне записях. Например, при запросе TXT-записей в dnssec.pw теперь нередко приходят ответы со статусом SERVFAIL, “RRSIG with malformed signature…” – написано в пояснении. Однако есть и ответы со статусом NOERROR (примерно, половина, как ни странно), где, впрочем, пояснение тоже указывает на “RRSIG with malformed signature…”.

Возможно, конечно, что в данном сервисе на разных экземплярах узлов разное программное обеспечение, но есть и другое, несколько более занятное, объяснение: может так быть, что сервис ограничивает количество попыток проверки подписи для каждой итерации. В зоне четыре ключа ZSK, подпись RRSIG на NSEC – одна, на SOA – две. Соответственно, если у резолвера установлено некоторое предельное количество ошибок проверки подписи, то, когда предел достигнут, резолвер прекращает попытки перебора ключей и возвращает SERVFAIL. Если же ключ удалось угадать за меньшее количество попыток, то возвращается NOERROR. Подсчёт строк с сообщениями “RRSIG with malformed signature” в ответах – укладывается в эту гипотезу, но чтобы судить точнее – нужно собрать дополнительную статистику.

Немного занимательной математики и глобальной DNS.

Насколько велика вероятность, что в доменах первого уровня глобальной DNS совпадут теги разных ключей DNSSEC? Нередко приходится слышать, что так как тег 16-битный, то и вероятность, примерно, 1/65535 (за вычетом особенностей алгоритма вычисления значения тега и пр.). Это не верно. Если рассматривать совпадения внутри набора ключей DNS, то получаем хрестоматийный пример парадокса дней рождения: нам не важно, чтобы повторилось конкретное, заданное значение тега, напротив – требуется совпадение любого значения внутри любой пары, а это совсем другая история, поскольку количество всевозможных пар велико даже в небольших наборах ключей. Поэтому вероятность совпадения тегов DNSSEC-ключей, на практике, очень велика. Иногда ключи просто обязательно совпадут по тегам. Например, в списке доменов первого уровня (корневой зоны DNS) сейчас 1452 имени, то есть, можно составить 1053426 пар (больше миллиона). А это количество (практически) гарантирует, что будут совпадения тегов ключей.

И действительно, если собрать DNSKEY-записи из доменов первого уровня, то окажется, что значений повторяющихся тегов, – то есть, значений, которые встречаются для разных ключей в разных зонах, – сильно больше сотни: у меня получилось 129 таких тегов. Обратите, кстати, внимание, что некоторые ключи разных зон TLD имеют одинаковые теги потому, что это просто одинаковые ключи. Такие повторы отбрасывались. Потому что корректно – сравнивать именно сами значения ключей (как и в прочих случаях использования тегов). Например, различные DNSSEC-ключи с одинаковыми тегами опубликованы в зонах cab и today, в зонах agency, weber и temasek, и во многих других.

(Дополнение: естественно, выше предполагается, что ключи для различных зон генерируются независимо, случайным образом.)

DNSSEC-подписи, удостоверяющие адресную информацию, размещаются в RRSIG-записях. Ссылка на открытый ключ, нужный для проверки подписи, в RRSIG записывается в виде 16-битного тега (KeyTag), который вычисляется по достаточно простому алгоритму от данных ключа. Соответственно, ключи публикуются в DNSKEY-записях. Можно ли специально подобрать несколько валидных ключей так, чтобы у них были одинаковые теги? Очевидно – можно (ключей много больше, чем тегов). И подбор совсем нетрудно сделать. Более того – даже сохранятся валидные подписи и, условная, “корректность” зоны с точки зрения DNSSEC. “Корректность” тут в кавычках потому, что, вообще говоря, несколько ключей с одинаковыми тегами не должны бы присутствовать в DNS-зоне, поскольку это нарушает логику ссылок из RRSIG. И хорошо бы в таком случае выводить ошибку валидации, но возможен более мягкий подход, который и используется.

Посмотрите, в качестве примера, на DNS-зону dnssec.pw – там я разместил несколько ключей (ZSK – Zone Signing Key), которые имеют одинаковые теги со значением 12345. Два ключа из четырёх ZSK задействованы в подписывании записей, а поскольку подписи можно проверять методом перебора ключей, то и RRSIG – валидируются, если валидатор резолвера справляется с ситуацией. Пятый ключ – это KSK, точка входа. Схема показана на картинке (ниже), которую сформировал весьма полезный сервис DNSViz. Повторяющиеся идентификаторы (id = 12345) выглядят занятно, однако количество вершин графа соответствует количеству ключей, а рёбра – соответствуют структуре подписей. Так что DNSViz не сломался:

Другой, не менее полезный, сервис для анализа DNSSEC – DNSSEC Analyzer – проверки для данной зоны тоже выполняет корректно, но в таблице результатов совпадающие идентификаторы могут запутать несколько больше, чем на графе GraphViz:

Валидирующие резолверы должны справляться с подобной конфигурацией ключей, однако Google Public DNS (8.8.8.8) возвращает в статусе информацию о “некорректном формате RRSIG”, но ответ всё равно снабжается флагом AD (Authentic Data), обозначающим, что проверка подлинности DNSSEC прошла успешно – впрочем, это соответствует действительности: подписи и цепочка в зоне dnssec.pw сейчас верные.