Перенос домена на другие DNS-серверы может выглядеть успешным во всех панелях управления, но сайт при этом останется недоступным. Домен активен, новые авторитативные DNS-серверы возвращают правильный адрес, а настройки веб-сервера не менялись. Однако резолверы, проверяющие DNSSEC, отвечают SERVFAIL. Причина часто кроется в делегировании DNSSEC: родительская зона по-прежнему доверяет ключу, которым подписывал записи прежний DNS-провайдер.
В случае, который лег в основу этого разбора, обычные DNS-запросы завершались ошибкой, а те же запросы без проверки DNSSEC успешно возвращали ответ. Родительская зона продолжала публиковать старую DS-запись, хотя новая авторитативная зона изначально не была подписана. Публикация подходящего ключа и подписание новой зоны восстановили проверяемые DNSSEC ответы на протестированных резолверах. Главный вывод не в том, что DNSSEC нужно отключать. Смена DNS-серверов и перенос цепочки доверия DNSSEC — две разные операции.
Почему правильная A-запись не спасает от SERVFAIL
DNS отвечает на два разных вопроса. Запись A сообщает резолверу, какой IPv4-адрес соответствует доменному имени. DNSSEC позволяет проверить, можно ли доверять полученному ответу. Правильный IP-адрес сам по себе не гарантирует, что цепочка доверия DNSSEC в порядке.
Для подписанного домена цепочка доверия идёт от доверенной родительской зоны через запись DS (Delegation Signer) к ключу DNSKEY в дочерней зоне. Дочерняя зона публикует подписи RRSIG для своих DNS-данных. Запись DS содержит хеш, по которому определяется доверенный ключ DNSKEY. Это не A-запись, не копия закрытого ключа и не обычный параметр редактора файла зоны.
После смены авторитативных DNS-серверов родительская зона может продолжать публиковать DS-запись, связанную с прежним ключом подписи. Если в новой зоне нет соответствующего DNSKEY и подписей, резолвер с проверкой DNSSEC не сможет выстроить цепочку доверия. Обычно он считает такой ответ недостоверным и возвращает SERVFAIL, а не непроверенный адрес.
Это не то же самое, что сбой HTTP: запрос может вообще не дойти до веб-сервера. И дело не в просроченном TLS-сертификате. DNSSEC проверяет подлинность DNS-данных, а HTTPS защищает последующее соединение браузера с сервером.
Как отличить ошибку DNSSEC от отсутствующей DNS-записи
Самый показательный тест — дважды запросить одну и ту же запись у одного и того же резолвера. Сначала выполните обычный запрос и посмотрите не только на ответ, но и на статус:
dig example.com A +noall +comments +answerЗатем повторите запрос с установленным битом CD (DNSSEC Checking Disabled):
dig example.com A +cdflag +noall +comments +answerВо время описанной проблемы обычный запрос возвращал SERVFAIL, а запрос с битом CD — ожидаемую A-запись. Такая разница убедительно указывала на сбой проверки DNSSEC, а не на отсутствие DNS-записи или недоступность приложения. Параметр +cdflag просит поддерживающий его рекурсивный резолвер не выполнять обычную проверку DNSSEC для конкретного запроса. Это диагностический приём, а не способ исправить ошибку в браузере или отключить DNSSEC для посетителей.
Не делайте выводы только по пустому выводу +short. В таком формате и отсутствие ответа, и ошибка SERVFAIL могут выглядеть одинаково — как пустая строка. При диагностике оставляйте +comments, чтобы видеть status: SERVFAIL или status: NOERROR.
Одно лишь сравнение запросов с битом CD и без него не показывает, какой именно элемент DNSSEC сломался. Оно только подсказывает направление дальнейшей проверки. У резолвера также может возникнуть временная ошибка при обращении к вышестоящему серверу, поэтому при необходимости повторите тест и изучите делегирование в родительской зоне.
Проверяйте DS-запись в родительской зоне, а не только в редакторе DNS
Проверьте DS-записи домена:
dig example.com DS +noall +comments +answerЧтобы подробнее проследить цепочку делегирования, выполните запрос непосредственно по иерархии DNS:
dig +trace example.com DSКонкретный авторитативный сервер родительской зоны зависит от домена верхнего уровня. Важно, какой набор DS-записей (RRset) публикует родительская зона, а не только то, что показывает панель DNS-хостинга. При переносе домена к другому регистратору NS-серверы могут остаться прежними, а сменить NS-серверы можно и без переноса домена. В обоих случаях DS-записи родительской зоны должны соответствовать активной авторитативной зоне.
У DS-записи четыре значимых поля: идентификатор ключа (key tag), алгоритм, тип хеша и сам хеш. Идентификатор ключа удобен для диагностики, но совпадение одного только этого значения ещё не доказывает, что DNSKEY подходит. Алгоритм и хеш тоже должны соответствовать ключу, который действительно отдаёт авторитативная зона.
В рассмотренном случае ситуация была однозначной: родительская зона продолжала публиковать прежние данные доверия DNSSEC, а интерфейс нового авторитативного DNS сообщал, что подписание отключено. A-записи существовали и возвращались при обходе проверки DNSSEC. Изменение настроек приложения или повторное редактирование той же A-записи не устранило бы это несоответствие.
Два способа восстановить работу при неправильном делегировании DNSSEC
Есть две корректные стратегии восстановления. Обе устраняют одно и то же несоответствие в цепочке доверия, но последствия для работы DNS различаются. Выберите подходящий вариант осознанно, а не переключайтесь между ними наугад.
Вариант 1. Удалить устаревшую DS-запись и временно оставить зону неподписанной
Попросите текущего регистратора удалить устаревшую DS-запись из родительской зоны либо сделайте это через поддерживаемый им интерфейс управления DNSSEC. Когда родительская зона перестанет объявлять защищённое делегирование, проверяющие резолверы смогут считать неподписанную дочернюю зону незащищённой, а не недостоверной. DNS снова будет работать, но аутентификация домена через DNSSEC временно исчезнет.
Часто это более простой аварийный вариант, если у вас есть надёжный способ изменить набор DS-записей в родительской зоне. Не меняйте текущую конфигурацию подписания, пока старые DS-записи не истекут в кешах рекурсивных резолверов. Одного факта удаления DS в панели недостаточно: независимо проверьте запись в родительской зоне и учитывайте её TTL. Работа HTTPS от настроек DNSSEC не зависит. Временный переход к неподписанной зоне также описан в RFC 8078.
Вариант 2. Подписать новую зону и опубликовать соответствующую DS-запись
Другой путь — включить DNSSEC у нового провайдера авторитативного DNS, сгенерировать ключевой материал DNSKEY, подписать зону и опубликовать соответствующую DS-запись в родительской зоне. Тогда проверяющий резолвер сможет построить доверенную цепочку до нового DNSKEY и проверить подпись A-записи.
Именно этот способ сработал в описанном случае. Панель управления DNS сообщила, что создала ключи, подписала зону и опубликовала новую DS-запись. Последующий запрос к родительской зоне показал сразу две DS-записи: новую и старую. Рекурсивные резолверы с проверкой DNSSEC снова начали возвращать ожидаемую A-запись. Более поздний тест также вернул NOERROR с флагом ad — признаком того, что данный резолвер подтвердил подлинность ответа.
Порядок действий важен: публикация DS поможет только в том случае, если соответствующий DNSKEY и действительные подписи уже доступны на авторитативных DNS-серверах. Надпись «published» в панели не заменяет независимую проверку. Из-за кеширования DS, DNSKEY, RRSIG и NS разные резолверы могут начать работать корректно в разное время.
Почему две DS-записи не обязательно мешают работе сайта
Неожиданным оказалось то, что в родительской зоне одновременно находились устаревшая и новая, действительная DS-запись, но проверка DNSSEC всё равно проходила успешно. Противоречия здесь нет. Набор DS-записей может содержать несколько значений — так часто бывает при смене ключей. Валидатору не требуется, чтобы каждая DS-запись указывала на пригодный для использования ключ. Достаточно хотя бы одной корректной цепочки проверки через подходящую DS-запись к DNSKEY и действительным подписям. RFC 6840 уточняет, что валидаторы должны принимать единственную корректную цепочку.
Это не значит, что устаревшие ключи стоит оставлять навсегда. Старая DS-запись усложняет администрирование, и после проверки новой цепочки её следует удалить. Но это плановая очистка конфигурации, а не повод снова рисковать и сбрасывать настройки DNSSEC, когда проверяемые ответы уже успешно возвращаются.
В панелях управления есть особенно опасная ловушка: действие с названием «emergency unpublish DS» может удалить все DS-записи, включая новую рабочую. Точно так же отключение подписания зоны при сохранении опубликованной DS-записи способно немедленно повторить аварию. Ни одно из этих действий не равнозначно точечному удалению конкретной устаревшей DS-записи. Если панель не позволяет выбрать отдельную запись, запросите адресное изменение через регистратора, а не полный сброс.
Как безопасно сменить авторитативные DNS-серверы
Безопасный порядок действий зависит от того, могут ли старый и новый DNS-провайдеры согласовать работу с ключами. Для обычного переноса с временным переходом на неподписанную зону последовательность будет такой:
- Сначала подготовьте зону у нового провайдера. Перенесите необходимые записи A, AAAA, CNAME, MX, TXT и другие важные записи. До изменения делегирования проверьте новые авторитативные DNS-серверы прямыми запросами.
- Проверьте DNSSEC в родительской зоне. Выясните, есть ли DS-записи и кто может их изменить. Сделайте это, даже если вы никогда не включали DNSSEC вручную: некоторые DNS-провайдеры подписывают зоны автоматически.
- Удалите старую DS-запись, пока прежняя подписанная зона ещё работает. Убедитесь, что изменение видно на авторитативных серверах родительской зоны, а затем дождитесь истечения срока кеширования ранее полученных DS-записей. Ориентируйтесь на наблюдаемые значения TTL, а не на универсальное количество минут.
- Измените делегирование NS-серверов. Не отключайте старый авторитативный DNS, пока кешированные NS-делегирования могут указывать на него. Учитывайте TTL NS-записей в родительской зоне и проверяйте, к каким серверам на самом деле обращаются разные резолверы.
- Решите, нужно ли снова включать DNSSEC. Если новая зона должна остаться неподписанной, не публикуйте DS. Если она должна быть подписана, сначала убедитесь, что новые DNSKEY и подписи действительно доступны и корректны, и только затем публикуйте соответствующую DS-запись. Согласуйте это с периодом, когда в кеше ещё могут оставаться старые NS-записи, чтобы не получить новую ошибку проверки.
- Проверьте результат независимо. Посмотрите DS-записи в родительской зоне, DNSKEY на авторитативных серверах, обычные ответы рекурсивных резолверов и результат проверки подлинности на резолверах с DNSSEC-валидацией.
Если защита DNSSEC должна сохраняться непрерывно, лучше заранее согласовать смену ключей или переход с несколькими подписывающими сторонами. Для этого оба DNS-провайдера должны поддерживать нужную схему работы с ключами и подписями. Простое копирование хеша старой DS-записи к новому провайдеру не является корректной сменой ключей.
Краткая проверка после переноса DNS
После любых изменений DNSSEC проверяйте не только сами DNS-записи, но и то, что резолверы принимают подтверждение их подлинности:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerДля проверки аутентифицированного ответа используйте рекурсивный резолвер с DNSSEC-валидацией. Статус NOERROR вместе с ожидаемой A-записью означает, что имя успешно разрешилось. Дополнительный флаг ad показывает, что резолвер подтвердил подлинность ответа согласно своей политике DNSSEC. Отсутствие флага ad само по себе не доказывает наличие проблемы: резолверы отличаются возможностями, правилами проверки и обработкой флагов запроса. Если во время сбоя запросы DNSKEY через проверяющий резолвер не проходят, дополнительно запросите данные напрямую у действующего авторитативного DNS-сервиса.
Не останавливайтесь на одном успешном ответе одного резолвера. В разных кешах какое-то время могут оставаться разные делегирования и ключи. Обновите также все открытые обращения в техподдержку: старая просьба удалить все DS-записи становится опасной после публикации новой рабочей DS-записи. В уточнении прямо укажите, что действующий ключ необходимо сохранить, а при необходимости удалить только устаревшую запись.
Проблема возникла не из-за неправильного адреса веб-сервера. Изменилось место, откуда приходили DNS-ответы, но при этом не были заранее согласованы данные доверия, по которым резолверы решали, каким ответам верить. Поэтому перед каждой сменой NS-серверов стоит задать главный вопрос: Какие DS-записи опубликованы в родительской зоне и смогут ли DNSKEY и подписи новой зоны их удовлетворить?