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

Кстати, в продолжение предыдущей записки: в какой последовательности нужно отключать DNSSEC-записи? Прежде всего – нужно удалять DS-записи из вышестоящей зоны. Дело в том, что именно DS-запись, которая содержит отпечаток ключа, говорит валидирующим резолверам о том, что данная зона “делегирована безопасно”.

Это самый важный момент: делегирующие ответы, с NS-записями, в DNSSEC не подписываются – в этом нет никакого смысла, потому что доверие в DNSSEC формируется по цепочке ключей, а не по адресам/именам серверов. (Собственно, как и во всякой подобной криптографической схеме.) Поэтому подписываются в DNSSEC записи, указывающие на ключи. В случае делегирующего ответа – это DS-запись. Более того, так как необходимо обеспечить криптографическое удостоверение факта отсутствия DS-записи для заданного имени, удостоверяется и то, что конкретной, по имени, DS-записи нет.

Теперь перейдём к процессу отключения DNSSEC. Речь, естественно, о полноценной поддержке, когда DS-записи присутствуют по всей цепочке до корня DNS. Так вот, самая распространённая ошибка – удаление DNSSEC-записей в самой, целевой зоне, без удаления DS-записей в делегирующей зоне. Так делать нельзя потому, что, с точки зрения валидирующего резолвера, тут же развалится доверенное делегирование. Возникает вот какая конфигурация: в ходе рекурсивного опроса резолвер получает DS-запись из делегирующей зоны, и параметры этой записи удостоверены DNSSEC-подписями из делегирующей зоны (по всей цепочке делегирования); однако из целевой зоны резолвер не может получить соответствующего ключа DNSSEC (в DNSKEY-записи), поэтому резолвер определяет, что DNSSEC-цепочка нарушена и возвращает ошибку валидации адресной информации – зона перестаёт работать. При этом, для невалидирующего резолвера, всё “работает” – ведь такой резолвер ничего не знает ни про DS-записи, ни про DNSKEY, ни про подписи (RRSIG). Поскольку сейчас распространённые сервисы DNS-резолвинга валидируют DNSSEC, – например, так делают 1.1.1.1 и Google Public DNS, – то и зона, для которой “повисла DS-запись”, отваливается для многих и многих пользователей.

Поэтому, прежде чем удалять поддержку DNSSEC непосредственно в зоне, нужно удалить DS-запись из делегирующей зоны. Например, в случае example.net – это будет DS-запись в зоне .net. После успешного удаления – нужно подождать какой-то разумно-максимальный срок TTL. Скажем, сутки.

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

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

Адрес записки: https://dxdt.blog/2026/04/24/18030/