Что такое DNSSEC и как работает проверка подписей

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

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

Основные записи DNSSEC

Механизм легче понять по ролям записей:

• DNSKEY публикует открытые ключи зоны.
• RRSIG содержит подпись конкретного набора записей одного имени и типа.
• DS в родительской зоне связывает делегирование дочерней зоны с её ключом.
• NSEC или NSEC3 позволяют криптографически подтверждать отсутствие имени или типа записи.

Подписывается не «домен целиком» одной строкой, а RRset: набор записей одинакового имени, класса и типа. Поэтому у набора A и набора MX будут отдельные подписи. У RRSIG есть временные границы действия; неверные часы или пропущенное обновление подписей могут сделать данные недействительными.

Открытые ключи и подписи нормально публиковать в DNS. Закрытый ключ должен оставаться под контролем оператора зоны. Его раскрытие позволяет создавать ложные подписи до безопасной смены ключевого материала и цепочки.

Как строится цепочка доверия

Валидатор начинает с заранее доверенной точки, обычно ключа корневой зоны. Подпись родительской зоны позволяет проверить её данные, запись DS связывает родителя с DNSKEY дочерней зоны, а ключ дочерней зоны проверяет её подписи. Цепочка повторяется до нужного имени.

Именно поэтому включение DNSSEC состоит как минимум из двух согласованных операций: подписать собственную зону и разместить корректный DS у родителя через регистратора или иной интерфейс делегирования. Если зона подписана, но DS не опубликован, валидатор обычно рассматривает делегирование как небезопасное, а не как подтверждённое. Если DS опубликован, но не соответствует действующему ключу, данные становятся bogus и валидирующие резолверы их отвергают.

Это важное эксплуатационное свойство: неправильно настроенный DNSSEC способен сделать корректные по содержанию записи недоступными для пользователей валидирующих резолверов.

Как проверить DNSSEC

Через проверку DNS посмотрите DNSKEY, DS и RRSIG, а также обычную запись, из-за которой возникла проблема. Для командной диагностики можно запросить DNSSEC-данные через dig:

dig example.com A +dnssec
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec

Ключ +dnssec устанавливает в запросе признак готовности получить DNSSEC-записи. Он не превращает любой используемый сервер в валидатор и не гарантирует локальную проверку подписи. Флаг ad в ответе имеет смысл только с учётом доверия к рекурсивному серверу и каналу до него: сервер сообщает, что считает данные аутентифицированными.

Утилита delv, если она установлена и настроена с подходящей точкой доверия, выполняет валидацию и показывает её результат:

delv example.com A

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

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

Допустим, зона обслуживается DNS-провайдером, а домен зарегистрирован у другой компании.

1. Уточните у DNS-провайдера поддерживаемый процесс включения и смены ключей. Не создавайте параллельные ключи вручную, если сервис управляет ими автоматически.
2. Включите подписание зоны и дождитесь публикации DNSKEY и подписей на всех авторитетных серверах.
3. Получите точные параметры DS из панели DNS-провайдера. Не перепечатывайте длинный digest по памяти.
4. Передайте DS родительской зоне через регистратора.
5. После публикации проверьте цепочку несколькими валидирующими средствами и контролируйте срок действия подписей.
6. Зафиксируйте процедуру переноса DNS. Нельзя просто удалить старые ключи или NS, пока новая цепочка не подготовлена с учётом TTL и кешей.

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

Ошибки и диагностика

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

Распространённые ошибки:

• считать любую запись RRSIG доказательством рабочей цепочки;
• публиковать DS до появления соответствующего DNSKEY на всех авторитетных серверах;
• удалить старый ключ слишком рано при rollover;
• забыть обновить DS при переносе к другому DNS-провайдеру;
• путать DNSSEC с шифрованием DNS или HTTPS;
• проверять только невалидирующим локальным резолвером;
• игнорировать время начала и окончания действия подписей;
• выполнять аварийные изменения сразу во всех звеньях без снимка текущих записей.

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

Частые вопросы

Шифрует ли DNSSEC DNS-запросы?

Нет. DNSSEC добавляет данные для проверки происхождения и целостности ответа, но сам по себе не скрывает имя запроса или содержимое DNS-ответа. Конфиденциальность DNS-транспорта решают отдельные механизмы.

Доказывает ли наличие RRSIG, что DNSSEC работает?

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

Что произойдёт при ошибке DNSSEC?

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