DNSSEC для домена: как включить и не получить SERVFAIL

DNSSEC позволяет проверяющему резолверу убедиться, что DNS-данные действительно опубликованы владельцем зоны и не изменены в пути. Для этого зона подписывается закрытым ключом, а родительская зона хранит ссылку на доверенный ключ дочернего домена.

Главный эксплуатационный риск — не сама криптография, а несогласованность. Если родитель обещает подписанную зону, а подпись отсутствует или ключ не совпадает, валидирующий резолвер вернёт SERVFAIL и сайт станет недоступен для его пользователей.

Какую угрозу закрывает DNSSEC

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

Он обеспечивает аутентификацию источника данных и контроль целостности. Также подписанная зона может доказуемо сообщить, что имени или типа записи не существует. Резолвер проверяет подпись и возвращает данные только при успешной цепочке доверия.

DNSSEC не шифрует сам запрос и не скрывает, какой домен ищет пользователь. Он не проверяет содержимое сайта и не заменяет TLS. Поддельная страница на законном IP, уязвимость приложения или украденный аккаунт регистратора остаются отдельными рисками.

Цепочка доверия идёт от родительской зоны

Подписанная зона публикует DNSKEY — открытые ключи — и RRSIG — подписи наборов записей. Закрытая часть ключа остаётся у оператора зоны и используется для создания подписей.

Чтобы резолвер доверял ключу example.com, родительская зона публикует DS. Эта запись содержит криптографический отпечаток ключа дочерней зоны. Для домена второго уровня DS передаётся реестру через регистратора или его интерфейс DNSSEC.

Резолвер начинает с заранее доверенного ключа корня, проверяет подпись верхнеуровневой зоны, затем DS домена и подпись его данных. Разрыв на любом звене делает ответ недостоверным для валидатора.

Не путайте DS и DNSKEY. DNSKEY находится в подписываемой дочерней зоне. DS находится у родителя. Копировать нужно значения, которые DNS-провайдер подготовил для конкретного ключа и алгоритма.

Убедитесь, что вся цепочка поддерживает DNSSEC

Перед включением проверьте три стороны:

• доменная зона верхнего уровня поддерживает DNSSEC;
• регистратор позволяет передать DS или автоматически синхронизирует его;
• авторитетный DNS-провайдер подписывает зону и управляет ключами.

Если хотя бы одной части нет, полноценная цепочка для домена не появится. Отдельная подпись зоны без DS называется островом доверия и обычно не проверяется публичными резолверами автоматически.

Узнайте, кто выполняет ротацию ключей и обновляет подписи до истечения. Управляемый DNS часто скрывает эту работу за переключателем, но порядок смены провайдера и отключения всё равно должен быть документирован.

Включайте подпись до публикации DS

При первом включении порядок такой:

1. сохраните текущую зону и проверьте её обычные ответы;
2. включите DNSSEC у авторитетного DNS-провайдера;
3. убедитесь, что все NS публикуют согласованные DNSKEY и RRSIG;
4. получите DS-параметры именно из панели этого провайдера;
5. передайте DS через регистратора;
6. после появления DS у родителя проверьте цепочку валидирующим инструментом;
7. откройте сайт и почту через несколько резолверов.

До шага с DS ошибки подписи не должны сделать домен недоступным для обычной публичной проверки, потому что родитель ещё не объявил цепочку. После публикации валидаторы начнут требовать корректный результат.

Не вводите отпечаток вручную по памяти и не выбирайте другой алгоритм «похожего» ключа. Поля key tag, algorithm, digest type и digest образуют единый DS и должны точно соответствовать данным DNS-провайдера.

SERVFAIL после включения требует проверки цепочки

SERVFAIL не означает, что записи отсутствуют. Резолвер сообщает, что не смог получить приемлемый ответ. При DNSSEC частая причина — неверная подпись, просроченный RRSIG, несовпадающий DS или недоступный авторитетный сервер.

Сравните обычный запрос и запрос с проверкой DNSSEC у нескольких инструментов. Посмотрите DS в родительской зоне, DNSKEY и RRSIG у каждого авторитетного NS. Если отпечаток не относится к текущему ключу, исправляйте связь у регистратора по процедуре поставщика.

Не лечите ошибку сменой A-записи: адрес сайта не исправляет криптографическую цепочку. Также не очищайте бесконечно локальный кеш, если авторитетные данные уже несогласованы.

Смена DNS-провайдера требует отдельного плана

Новый провайдер создаёт свои ключи. Если просто поменять NS, оставив DS старого ключа, валидаторы увидят новую зону, которую родитель не подтверждает. Такой перенос способен отключить домен даже при правильных A и MX.

Используйте документированную процедуру multi-signer или временно снимайте цепочку в правильном порядке. Для простого перехода часто сначала удаляют старый DS у родителя, дожидаются окончания его кеширования, затем меняют NS и после проверки новой подписанной зоны публикуют новый DS. Конкретный порядок согласуйте с обоими DNS-провайдерами, потому что их автоматизация различается.

Старую зону и ключи не отключайте, пока старое делегирование или DS могут оставаться в кеше. Общие правила переноса NS описаны в статье о делегировании домена.

Отключайте DNSSEC от родителя к дочерней зоне

Чтобы снять защиту без разрыва, сначала удалите DS у регистратора. Дождитесь, пока старый DS перестанет возвращаться из родительской зоны и кешей. Только после этого выключайте подпись на авторитетных серверах.

Обратный порядок опасен: родитель продолжает обещать проверяемую дочернюю зону, но та уже не предоставляет нужные подписи. В результате валидирующие резолверы отклоняют ответы.

После любой операции проверьте A/AAAA, MX и другие критичные записи, а затем сайт по HTTPS и приём почты. Команды для сравнения источника и кешей описаны в руководстве по dig и nslookup. Защита аккаунта регистратора остаётся обязательной: злоумышленник с доступом к DS и NS может изменить саму цепочку.

Источники

• RFC 4033: DNS Security Introduction and Requirements
• RFC 4034: Resource Records for the DNS Security Extensions
• RFC 4035: Protocol Modifications for DNS Security Extensions
• ICANN: DNSSEC — What Is It and Why Is It Important?