DNSSEC: как проверяется подлинность DNS-ответов

DNS Security Extensions, или DNSSEC, добавляют к DNS-данным криптографическую аутентификацию. Они помогают валидирующему резолверу убедиться, что ответ относится к нужной зоне и не был изменён при передаче. DNSSEC не шифрует DNS-запросы, не скрывает запрашиваемый домен и не делает сайт безопасным. Он обеспечивает цепочку подписей и ключей, позволяющую резолверу проверить подписанные данные вплоть до доверенного корня. Если цепочка настроена правильно, у резолвера появляется более надёжное подтверждение подлинности ответа; если она нарушена, проверка может приводить к сбоям даже в самых обычных запросах.

Записи в цепочке DNSSEC

Подписанная зона публикует записи DNSKEY с открытыми ключами для проверки подписей. Записи RRSIG содержат подписи наборов записей, а записи DS в родительской зоне связывают ключ дочерней зоны с цепочкой доверия родителя. Данные NSEC или NSEC3 могут обеспечивать аутентифицированное подтверждение того, что имени или записи не существует. Как правило, операторы полагаются на DNS-провайдера или регистратора, которые создают и поддерживают эти значения, но ответственность может быть разделена: дочернюю зону подписывает DNS-хостинг, а родительская запись DS публикуется через регистратора. Несоответствие между ними — частая причина проблем с проверкой.

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

Как возникают сбои DNSSEC

К типичным случаям относятся: устаревшая запись DS, оставленная у регистратора после смены DNS-провайдера; публикация ключей, не соответствующих подписанной зоне; истёкшие подписи из-за прекращения подписывания; смена делегирования без согласования родительской и дочерней сторон. Внедрение DNSSEC или смену ключей нужно проводить по документированной процедуре провайдера и проверять через независимый валидирующий резолвер. Если DNSSEC отключается, устаревшие данные DS могут навредить сильнее, чем полное отсутствие записи DS, поскольку валидаторы продолжат ожидать цепочку, которую дочерняя зона больше не предоставляет. Воспринимайте регистратора и DNS-хостинг как связанные части одного процесса.

• Выясните, подписывает ли DNS-провайдер зону и управляет ли ротацией ключей.
• Убедитесь, что значение DS у регистратора соответствует актуальным инструкциям провайдера.
• Проверяйте через валидирующий резолвер после включения, отключения или переноса DNSSEC.
• Тщательно планируйте смену ключей и сохраняйте путь отката.
• Не путайте аутентификацию DNSSEC с шифрованием DNS-трафика.

Диагностика сбоя проверки

Если домен возвращает SERVFAIL у валидирующих резолверов, проверьте цепочку DNSSEC, прежде чем менять несвязанные записи A или MX. Убедитесь в DNSKEY и подписях авторитативной зоны, затем сравните их с DS, опубликованной родителем. Посмотрите сроки действия подписей и недавние изменения у провайдера. Обычная проверка «домен в IP» может сообщить, что разрешение не удалось, но не обязательно объяснит, какое звено DNSSEC нарушено; для более глубокого вопроса используйте диагностику с поддержкой DNSSEC. Ведите заметку об инциденте с указанием резолвера, результата валидации и времени запроса, чтобы провайдер мог разобрать воспроизводимый случай.

DNSSEC повышает достоверность данных, но операционная аккуратность по-прежнему важна. Он не защитит от компрометации аккаунта владельца домена и не исправит неверную запись: он лишь аутентифицирует опубликованные данные в соответствии с настроенными ключами. Базовый контекст: как работает DNS-разрешение и типы DNS-записей. Включайте DNSSEC, когда вы способны поддерживать цепочку и следить за ней при продлениях и переносах, а не считайте его разовым переключателем, корректность которого можно предполагать бессрочно.

Смену ключей нужно согласовывать

Смена ключей DNSSEC (key rollover) меняет криптографический материал, от которого зависят валидирующие резолверы. Точная безопасная последовательность зависит от провайдера подписи и от того, автоматическая смена или ручная. Следуйте документированному процессу, чтобы старые и новые ключи пересекались как положено, подписи оставались действительными, а родительские данные DS на нужном этапе соответствовали опубликованным ключам. Не копируйте значение DS со скриншота устаревшей панели и не удаляйте его только потому, что несвязанный запрос завершился тайм-аутом. После смены проверьте результат не менее чем через один валидирующий резолвер DNSSEC и сохраните журналы событий провайдера. Если проверка не проходит, зафиксируйте домен, резолвер, код ответа и время, затем проверьте подписи и связь с DS, прежде чем трогать записи приложений. Контролируемая смена с мониторингом куда безопаснее аварийных попыток чинить цепочку, когда браузеры и почтовые системы уже начали отказывать.