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

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. Впрочем, каких-то огромных практических рисков на этом направлении не просматривается.

Адрес записки: https://dxdt.ru/2023/12/18/11944/