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

Немного занимательной математики и глобальной 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 сейчас верные.

Официальное сообщение КЦ .RU/.РФ о вчерашней проблеме с DNSSEC: “возникшая коллизия ключей, в причинах которой в настоящее время продолжают разбираться специалисты Технического центра интернет (ТЦИ) и MSK-IX, привела к временной недоступности зоны .RU для части интернет-пользователей”.

Одна из ключевых особенностей DNSSEC в том, что подписываются и данные об отсутствии делегирующих DNSSEC-записей (DS-записи) для зон, находящихся уровнем ниже. Поэтому, если у вас валидирующий резолвер, то проблема с подписями в DNSSEC может затронуть и те зоны, в которых DNSSEC нет. (Кстати, а особенность DNS – в том, что это всеобъемлющая для Интернета (и не только) технология, которую мало кто замечает, пока всё работает.)

В логах веб-сервера dxdt.ru тысячи записей о GET-запросах от некоторого ClaudeBot, как указано в User-Agent. Больше в User-Agent ничего не указано, хотя правила хорошего тона предполагают, как минимум, ссылку на страницу с описанием того, “что это, зачем и как оно приходит” – в HTTP это нетрудно сделать. Конечно, в User-Agent каждый может написать что вздумает, но данный ClaudeBot ещё и приходит за одними и теми же страницами (которые не изменялись), постоянно переключая IP-адреса. А IP-адреса там из пула AWS (амазоновский сервис), поэтому даже и обратная зона мало о чем говорит (ну, кроме того, что это AWS). Непонятно, имеют ли следы в логах, оставленные данным ботом, какое-то отношение к деятельности одноимённого продукта очередной AI/ИИ-компании, решения которой для российских пользователей заблокированы, но забавно уже то, что имя используется совпадающее; тем более, что на сайте компании не удалось найти ничего о том, как их боты оформляют свои запросы.

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

На сервисе audit.statdom.ru, в части тестирования настроек MX, добавился вывод сведений о совпадающих IP-адресах для разных имён MX-ов и чуть более развёрнутые сведения о TLS-сертификате почтового сервера (имя CN удостоверяющего центра).

Что касается разных имён для одинаковых IP-адресов, то тут речь вот о чём: предположим, что в зоне указано три имени MX – mx1.test.ru, mx2.test.ru, mx3.test.ru, но двум из этих имён соответствует общий адрес, например, mx1.test.ru имеет адреса 10.11.22.33, 10.22.33.44, а mx2.test.ru – 10.11.22.33, 10.55.55.55 (совпали 10.11.22.33). Это не то чтобы типовой случай, но регулярно встречается. Например, такое есть у Gmail. Причины тут могут быть разные, редко – это просто ошибка, а чаще – проекция представления администраторов и DevOps о методах балансировки (случай крупных сервисов) и защиты от нежелательных сообщений.

Кстати, с точки зрения сканера, конфигурация с повторяющимися IP создаёт некоторые занимательные затруднения для анализа TLS в случае STARTTLS. Дело в том, что ответы почтовых серверов кешируются, чтобы не надоедать “почтовикам” повторными запросами. Повторные запросы без попыток доставки сообщений – это, в мире администрирования почтовых серверов, самое страшное, что только может быть, так что робот к роботу тут должен подходить только с должным пиететом, расшаркиваясь и выжидая положенное время (посмотрите, кстати, на один из самых занимательных статистических отчётов по почтовым серверам Рунета – время ожидания ответа). Кешировать имеет смысл только по IP-адресу, потому что именно по IP-адресу устанавливается соединение. Так что, когда одинаковый адрес используется с разными именами, приходить повторно сканер не будет, но, вообще говоря, это означает, что сканер не сможет и получить сертификаты для разных имён, которые сервер, – гипотетически, – мог бы передать в ответ на не менее разные значения SNI (имя хоста в TLS).

DNSSEC предоставляет механизм удостоверения адресной информации в DNS, что требует подтверждения факта отсутствия ответа на запрос. Собственно, это особенность не столько DNSSEC, сколько любой подобной криптографической системы: необходима возможность криптографического подтверждения, что какие-то записи действительно отсутствуют, потому что иначе активный аткующий может просто удалить из DNS-ответов записи, обеспечивающие безопасное делегирование (DS-записи), тем самым сымитировав отсутствие DNSSEC в атакуемой зоне. Отсутствию записей и имён в терминах DNS соответствует NXDOMAIN (нет имени) и NODATA (нет данных записи запрошенного типа). NXDOMAIN – это когда спросили имя test.example.com, а его в зоне example.com нет. NODATA – спросили TXT-запись для test.ru, имя test.ru есть, но ему не соответствует TXT-записи (NODATA это ANSWER:0 со статусом NOERROR, если в терминах BIND).

Так вот, DNSSEC работает с электронными подписями, однако подписать пустое множество здесь нельзя (хотя бы потому, что все пустые множества одинаковые, а это означает, что подобную подпись можно будет скопировать и применять в контексте отсутствия любой записи). Так что типовая реализация DNSSEC как бы подписывает конкретные “дыры”, но для этого заключает их в некоторую внешнюю конструкцию.

Например, для NXDOMAIN “подписываются” два ближайших имени, между которыми оказалось бы запрашиваемое, если все имена в зоне упорядочить. Известно, что эта реализация позволяет третьей стороне проиндексировать имена, существующие в зоне, поскольку ответ на запрос со специально составленным несуществующим именем позволяет видеть соседние существующие имена – это называется DNSSEC zone walking (индексация зоны), и предоставляет хрестоматийный материал для обучения студентов направления “Информационная безопасность”, но не более. Строго говоря, есть два основных варианта решения проблемы “подписывания дыр”: они называются NSEC и NSEC3, а последний предоставляет больше защиты от индексации зоны, однако сейчас это всё лишь иллюстративные детали, поскольку вообще странно считать, будто заведомо публичные записи в зоне должны быть защищены таким странным способом от “обнаружения” – см., впрочем, про “принцип Керкгоффса“. Предложены способы, предотвращающие индексацию зоны путём “подставных” ответов, содержащих специально сгенерированные имена.

Для NODATA подписывается перечень существующих записей для запрошенного имени, а логика близка к NXDOMAIN, но на практике реализовать можно более удобным способом (см. ниже). Сопроводительная информация о границах “дыр” передаётся в записях NSEC (или NSEC3, но в этой заметке рассматривается только NSEC – дальше будет понятно, почему).

При полностью динамической работе DNS на стороне авторитативного сервера всякое противодействие индексации зоны требует динамических подписей. Однако в таком случае обработка NXDOMAIN быстро превращается в проблему, поскольку требуются дополнительные вычисления. Особенно, если в зоне много имён. Грубо говоря, если у вас есть миллион записей с именами хостов в некоторой базе данных, то уже для обнаружения соседних имён придётся строить какой-то индекс и так далее. Если же состав записей постоянно изменяется, а ответ зависит и от видимых характеристик клиента, и от текущего состояния большей системы на стороне сервера, то вычисление NXDOMAIN может вылететь в копеечку (в том числе, из-за большого размера ответа с подписями). Оригинальное решение тут первыми применили в Cloudflare, ещё в 2016 году. Решение основано на модификации логики обслуживания DNSSEC – предлагается, фактически, исключить понятие отсутствующего имени или отсутствующей записи, что позволит генерировать виртуальные подписи на лету (но, обратите внимание, это не отменяет кэширования сгенерированных ответов).

Иными словами – сервер выдаёт “нечестные” ответы. Например, сервер не отвечает резолверу со статусом NXDOMAIN вообще, а вместо этого использует вариант NODATA: на запрос о реально не существующем в зоне имени сервер отвечает, что есть имя, состоящее из префикса \000., приписываемого к запрошенному имени, то есть, это как бы граница (которой в реальной зоне нет), а ответ поэтому содержит одну NSEC-запись; подпись же вычисляется на лету. Для случая “настоящего” NODATA – всё работает аналогично: сервер отвечает, что есть все мыслимые ресурсные записи, кроме той, которую запросил резолвер. Например, если резолвер спрашивает A-запись, то авторитативный ответ будет содержать указание в NSEC на существование NS, SOA, TXT, LOC, SRV и прочих DNS-записей, но не A-записи. Это тоже позволяет генерировать ответы динамически. То есть, авторитативный сервер “обманывает” резолвер, но делает это для того, чтобы экономить вычислительные ресурсы (поэтому механизм называется black lie – вместо white lie, однако это детали литературной терминологии).

Всё это несложно сейчас увидеть снаружи на примере Cloudflare: попробуйте взять dig и проверить самостоятельно на той или иной зоне, поддерживающей DNSSEC на авторитативных серверах Cloudflare. Такая реализация не только позволяет работать с динамической DNS, но и экономит место в ответах (другой существенный способ экономии – ECDSA, которую только и использует Cloudflare, так как ECDSA-подписи короче RSA).

Насколько такой метод универсален и эффективен? Для больших, постоянно изменяющихся наборов DNS-данных, эффективен, однако требует программного решения собственной разработки. При этом, если DNS-зона не особенно часто изменяется, то смысла в динамическом вычислении подписей меньше. Для многих зон обычным является изменение содержания DNS-записей, скажем, раз в месяц (или даже раз в год). С другой стороны, динамическая “подмена” NXDOMAIN может защитить от индексации зоны.

Вычисление подписи на лету означает, что секретный ключ и реализация алгоритма подписи применяются гораздо чаще, чем при “статическом” варианте. Однако это вопрос модели угроз. Так, для атак, использующих побочные каналы утечки, требуется, чтобы можно было вызывать реализацию криптосистемы много раз (естественно, за разумный промежуток времени). Существенным подспорьем тут будет возможность получать подписи на данных известного атакующему состава и в выбранном формате – это, отчасти, как раз и позволяет реализация подмены NXDOMAIN на NODATA. Впрочем, каких-то огромных практических рисков на этом направлении не просматривается.

Кстати, если посмотреть в DNS-зону cloudflare.com (это, понятно, Cloudflare) на предмет политики DMARC, то там в поле rua указан почтовый адрес в cyber.dhs.gov:

$ dig -t TXT _dmarc.cloudflare.com +short
"v=DMARC1; p=reject; pct=100; rua=[...]mailto:reports@dmarc.cyber.dhs.gov"

Что это означает? Имя cyber.dhs.gov – это в Штатах агентство CISA (Cybersecurity and Infrastructure Security Agency), относящееся к DHS, то есть, к министерству внутренней безопасности (Department of Homeland Security). Опция rua в строке DMARC обозначает адрес (адреса), по которому принимающие почтовые серверы могут отправлять отчёты об обработке почтовых сообщений (допускаются разные протоколы для доставки, но обязательный – mailto, электронная почта). Так что, запись означает, что сборщик отчётов DMARC CISA может сразу принимать сведения о получении почты с адресами в домене cloudflare.com. Это не обязательно сообщения, действительно отправленные почтовой системой Cloudflare – может быть и нежелательная рассылка с “подспуфленным” адресом: для обнаружения таких писем как раз нужны DMARC и DKIM.

Немного про административную структуру, связанную с доменами верхнего уровня. Про эту структуру сейчас почему-то забывают, сосредотачиваясь на регистраторах, с которыми взаимодействует обычный пользователь. Однако, в современных интернет-реалиях, эта административная стурктура довольно важна. Домены верхнего уровня здесь – это имена зон, указанные в корневой зоне общепринятой (пока что) системы доменных имён (DNS): .COM, .NET, .RU, .PW, .BAR и др., их сейчас очень много, заметно больше 1500. Корневой зоной всё ещё управляет IANA под эгидой ICANN, но сейчас речь о другом. А именно: практически у всякого домена верхнего уровня есть обособленный администратор, технический контакт и оператор реестра. И это всё могут быть совсем разные организации. (Тут встречаются исключения, конечно, но весьма редкие: “потерявшиеся” зоны, “спорные” зоны, тестовые домены и так далее – эти случаи не рассматриваем.)

Администратор – определяет, как именно управляется домен верхнего уровня: устанавливает правила и т.д. Администратор же выбирает оператора реестра. А вот реестр – это такая специальная база данных, связанная с технической частью DNS, которая содержит сведения о регистрациях имён (в том числе, сведения о регистрантах/администраторах) и, поэтому, служит источником сведений для настроек доменов в качестве пространства сетевых имён внутри доменной зоны.

Административные и технические роли в доменах верхнего уровня могут пересекаться неожиданным образом. Например, что общего у доменов .PW и .BAR? Администраторы – разные. Технические контакты – разные. Даже класс домена отличается: .PW – это домен ccTLD (национальный), а .BAR – это New gTLD (домены, добавленные в DNS силами ICANN в рамках процесса “массового расширения”). Поэтому далеко не всякий продвинутый интернет-пользователь знает, что за этими разными доменами стоит один и тот же провайдер сервисов реестра: компания CentralNic (это, впрочем, и не скрывается).

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

Что это всё означает? Это означает, что если оператор реестра того или иного домена верхнего уровня станет что-то блокировать (по указанию администратора домена или без такого указания), то он может заблокировать передачу регистраций с конкретными данными регистрантов (администраторов доменов уровнем ниже). И регистратор с этим не может ничего сделать. Собственно, регистратора могут просто отключить от реестра, а доменные имена, которые через него зарегистрированы, передать другому регистратору, снять с делегирования (то есть, они не будут доступны в DNS) и перевести в статус “заблокированных”, переделегировать произвольным образом, или просто удалить – вариантов тут масса.

Пояснение: главное тут даже не отключение регистратора, а то, что реестр может блокировать доменные имена на основании их свойств – например, по геопривязке данных администратора, – вне зависимости от регистратора-источника.

Кстати, что ещё касается регистраторов и, в частности, GoDaddy. Доменные зоны, а точнее – имена хостов в этих зонах, – часто используются косвенно, в составе тех или иных технических систем. Про это могут забыть даже администраторы и DevOps. Тут могут быть имена авторитативных серверов DNS (NS), имена для почтовых серверов, технические зоны для CDN и прочих систем распределения нагрузки. Потеря подобного имени может привести не только к недоступности ресурсов, но и к той или иной подмене адресации (потому что имя могут перехватить). При этом, GoDaddy мог выступать провайдером DNS-хостинга, что означает появление задач по корректному переносу самой доменной зоны. Так что проблемы у администраторов и DevOps, конечно, могут быть. Особенно, если учитывать, что изменение регистратора доменного имени, даже при содействии отдающей стороны, может занять время: нужно получать коды подтверждения, снимать/устанавливать разные флаги, вести дополнительную переписку. У GoDaddy, например, не самая надёжная и понятная панель управления – часто при переносе имён происходят какие-то загадочные сбои, не отправляются письма.

(И, опять же, не стоит забывать про реестры.)