Коротко. DNSSEC — это криптографические подписи для DNS-записей. Он не шифрует запросы, а доказывает, что ответ пришёл от владельца зоны и не был подменён по дороге. Включается в два шага: зона подписывается на DNS-хостинге, а хеш ключа (DS-запись) публикуется у регистратора домена. Ошибка в любом из шагов роняет домен целиком: невалидный ответ резолвер не «пропускает с предупреждением», а отбрасывает.
Проблема: DNS без защиты
Стандартный DNS работает по UDP без шифрования и без аутентификации. Резолвер верит любому ответу, который выглядит как ответ на его запрос и приходит с нужного адреса и порта. Отсюда несколько классов атак.
Отравление кэша (DNS Cache Poisoning)
Злоумышленник шлёт рекурсивному резолверу поддельные ответы, угадывая идентификатор транзакции и порт. Если подделка успевает раньше настоящего ответа, резолвер кэширует чужой IP — и все его пользователи идут на подставной сервер до истечения TTL. Рандомизация порта усложнила атаку, но не сделала её невозможной.
Man-in-the-Middle
Атакующий в том же сегменте сети или на промежуточном узле перехватывает запрос и отвечает первым. Классический сценарий — публичный Wi-Fi и подмена ответа для домена банка или почты.
Перехват маршрута (BGP Hijacking)
На уровне маршрутизации трафик к авторитативным серверам зоны уводится через инфраструктуру атакующего. Формально «настоящий» сервер отвечает — но отвечает не тот. DNSSEC ловит и этот случай: подписи не сойдутся.
DNSSEC — это про подлинность, а не про приватность. Он не скрывает, какие домены вы запрашиваете: содержимое запроса видно провайдеру и всем на пути. Конфиденциальность даёт шифрование канала — DNS over HTTPS и DNS over TLS. Эти механизмы решают разные задачи и нормально работают вместе.
Что такое DNSSEC
DNSSEC (DNS Security Extensions) — набор расширений протокола, описанный в RFC 4033, 4034 и 4035. К обычным записям добавляются подписи, а к зоне — открытые ключи. Резолвер, умеющий проверять подписи, отвечает клиенту только тогда, когда цепочка проверок сошлась до корня.
Важное следствие для владельца домена: DNSSEC не имеет промежуточного состояния «подпись неверна, но покажем». Если валидация не прошла, валидирующий резолвер возвращает SERVFAIL, и для пользователя это выглядит как «сайта не существует». Поэтому неаккуратное включение или отключение опаснее, чем его отсутствие.
Как работает: цепочка доверия
DNSSEC строит непрерывную цепочку от корневой зоны до вашего домена. Каждый уровень ручается за ключ следующего:
- Корневая зона (.) — её открытый ключ (trust anchor) зашит в резолвере и обновляется вместе с ПО.
- Зона верхнего уровня (
.ru,.com,.рф) — подписана корнем; хранит DS-записи делегированных доменов. - Ваш домен — подписывает собственные записи: A, AAAA, MX, TXT и остальные.
Связующее звено между уровнями — DS-запись: хеш открытого ключа дочерней зоны, лежащий в родительской. Именно её вы добавляете у регистратора, и именно её рассинхронизация с реальным ключом — причина большинства аварий.
Записи DNSSEC
| Запись | Где лежит | Назначение |
|---|---|---|
DNSKEY | В вашей зоне | Открытые ключи зоны, которыми проверяются подписи |
RRSIG | В вашей зоне | Подпись набора записей: свои RRSIG есть у A-записей, у MX, у TXT — у каждого набора отдельно |
DS | В родительской зоне | Хеш вашего ключа подписи ключей; публикуется через регистратора |
NSEC / NSEC3 | В вашей зоне | Доказательство отсутствия записи, чтобы нельзя было подделать ответ «такого имени нет» |
CDS / CDNSKEY | В вашей зоне | Сигнал родительской зоне об обновлении DS без ручных действий; поддерживается не всеми реестрами и регистраторами |
Два ключа: KSK и ZSK
- KSK (Key Signing Key) — подписывает набор DNSKEY. Его хеш уходит в родительскую зону как DS. Меняется редко, потому что каждая смена требует обновления DS у регистратора.
- ZSK (Zone Signing Key) — подписывает обычные записи зоны. Меняется часто и полностью внутри зоны: родительскую зону трогать не нужно.
Такое разделение существует именно ради этого: частая ротация не требует походов к регистратору, а редкая смена «главного» ключа делается по отдельной процедуре.
Алгоритмы подписи
Практически весь современный рунет живёт на двух алгоритмах: RSA с SHA-256 и ECDSA на кривой P-256. Второй даёт заметно более короткие подписи при сопоставимой стойкости, а короткие подписи — это меньший размер ответа и меньше проблем с фрагментацией UDP. Если DNS-хостинг даёт выбор и вы не привязаны к унаследованной конфигурации, разумно выбирать ECDSA. Для DS-записи используйте дайджест SHA-256: SHA-1 считается устаревшим.
Как проходит валидация
Когда валидирующий резолвер получает ответ, он делает следующее:
- Запрашивает запись и сопутствующую ей RRSIG.
- Берёт DNSKEY зоны и проверяет, что подпись сделана этим ключом и не истекла.
- Сверяет хеш ключа с DS-записью из родительской зоны.
- Повторяет шаги для родителя, поднимаясь до корневого ключа.
- Если всё сошлось — отдаёт ответ клиенту и выставляет флаг
AD(Authenticated Data). - Если не сошлось — отдаёт
SERVFAIL. Не «ответ без флага», а именно отказ.
Флаг AD — самый быстрый способ понять, что валидация реально произошла, а не была пропущена. Он появляется в заголовке ответа резолвера, а не в самой зоне.
Как включить DNSSEC
Сценария три, и они различаются тем, кто хранит ключи.
Сценарий 1: DNS-хостинг подписывает, регистратор публикует DS
Самый частый вариант. Порядок действий принципиален:
- Включите подпись зоны в панели DNS-хостинга. Зона получит DNSKEY и RRSIG, но снаружи ничего не изменится — валидаторы пока не знают о ключах.
- Скопируйте DS-запись (или параметры для её сборки: keytag, алгоритм, тип дайджеста, сам дайджест).
- Добавьте DS у регистратора домена — обычно это отдельный раздел «DNSSEC» в карточке домена.
- Дождитесь появления DS в родительской зоне и проверьте цепочку.
Обратный порядок — сначала DS, потом подпись — гарантированно кладёт домен. Валидаторы уже требуют подпись, а зона её ещё не отдаёт. То же правило зеркально работает при отключении: там DS удаляется первым. Общее правило простое — DS появляется последним и исчезает первым.
Сценарий 2: панель управления хостингом «в один клик»
Если DNS обслуживает та же компания, что и хостинг, кнопка включения часто делает оба шага сама, потому что и зона, и домен под её управлением. Проверять результат всё равно нужно: автоматизация делает шаг «опубликовать DS», но не гарантирует, что реестр его принял.
Сценарий 3: собственный авторитативный сервер
На своём сервере зона подписывается локально. В современных версиях BIND проще всего отдать это встроенной автоматике подписи и ротации, а не собирать ключи руками:
# named.conf: включить автоматическое сопровождение подписей
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
dnssec-policy default;
inline-signing yes;
};
# проверить, что зона подписалась и подписи актуальны
rndc dnssec -status example.com
# получить DS для передачи регистратору
dnssec-dsfromkey -a SHA-256 /var/lib/bind/Kexample.com.+013+12345.keyКлючевое требование к своему подписанту — надёжное расписание. Подписи имеют срок действия, и если процесс переподписи остановится, домен «протухнет» без единого изменения в зоне.
Как проверить DNSSEC
Проверять нужно три разные вещи, и путать их не стоит: есть ли подписи в зоне, есть ли DS у родителя, и сходится ли цепочка целиком.
# 1) Есть ли ключи и подписи в самой зоне
dig example.com DNSKEY +dnssec +multiline
dig example.com A +dnssec | grep -i rrsig
# 2) Опубликован ли DS в родительской зоне
dig example.com DS +short
# 3) Сходится ли цепочка целиком (флаг ad в заголовке ответа)
dig @1.1.1.1 example.com A +dnssec | grep -E 'flags:|status:'
# 4) Проверка «это точно DNSSEC?»: с отключённой валидацией
dig @1.1.1.1 example.com A +cd +shortЧетвёртая команда — главный диагностический приём. Флаг +cd (checking disabled) велит резолверу не проверять подписи. Если обычный запрос даёт SERVFAIL, а с +cd ответ приходит нормально — проблема именно в DNSSEC, а не в доступности серверов зоны. Это отделяет «сломанная подпись» от «сервер не отвечает» за одну команду; общий алгоритм разбора недоступности разобран в материале про DNS, который не резолвится.
Если в системе есть delv из состава BIND, он показывает результат валидации человеческим языком:
delv @1.1.1.1 example.com A +rtrace
# в выводе: "fully validated" — цепочка сошласьБез командной строки состав записей зоны, включая DNSKEY и DS, показывает проверка DNS-записей, а разницу в ответах разных резолверов после изменений — проверка распространения DNS. Что означают отдельные типы записей, разобрано в справочнике типов DNS-записей, а как с ними работать на практике — в руководстве по работе с записями.
Как правильно отключить DNSSEC
Отключение ломает домены чаще, чем включение, потому что интуитивный порядок действий — неправильный. Убрать подписи первыми нельзя: пока DS лежит в родительской зоне, каждый валидирующий резолвер обязан требовать подпись, а её уже нет. Домен пропадает для существенной доли пользователей мгновенно.
- Удалите DS-запись у регистратора. С этого момента новые запросы перестают требовать подписи.
- Дождитесь истечения TTL DS-записи в родительской зоне. Это часы, а не минуты: пока запись живёт в кэшах резолверов, требование подписи сохраняется. Ориентируйтесь на сутки — заведомо с запасом.
- Только теперь снимайте подпись зоны на DNS-хостинге.
Тот же порядок действует при переезде на другой DNS-хостинг: сначала снять DS, дождаться TTL, сменить NS, включить подпись заново и опубликовать новый DS. Ошибка «сменили NS, забыли про DS» — самая массовая авария DNSSEC; подробности процесса смены серверов имён — в материале про смену DNS-сервера, а сколько ждать распространения — в разборе распространения DNS.
Типичные поломки и как их читать
| Симптом | Причина | Что делать |
|---|---|---|
| Домен открывается у одних, не открывается у других | Провайдеры с валидирующими резолверами отбрасывают ответ, остальные — нет | Проверить запрос с +cd: если так работает, дело в подписи |
SERVFAIL сразу после смены DNS-хостинга | Старая DS-запись указывает на ключ, которого больше нет | Удалить DS у регистратора; вернуть его после подписи новой зоной |
| Домен «упал» без единого изменения | Истёк срок действия RRSIG: подписант остановился или сломался | Проверить состояние подписи на DNS-хостинге, перезапустить переподпись |
| DS добавлен, но цепочка не сходится | Не тот keytag, алгоритм или тип дайджеста при ручном вводе | Сверить параметры DS с DNSKEY зоны и пересоздать запись |
| Ответы обрезаются или запросы уходят в TCP | Подписи увеличили размер ответа; посредник режет большие UDP-пакеты | Проверить прохождение больших ответов и EDNS; при выборе алгоритма предпочесть ECDSA |
Всё работает, но флага AD нет | Резолвер не валидирует — это не поломка вашего домена | Проверить у публичного валидирующего резолвера |
Отдельно стоит запомнить неприятное свойство таких аварий: они не видны с рабочего места, если ваш резолвер не валидирует. Домен для вас открывается, а часть аудитории его не видит. Поэтому проверять DNSSEC нужно с валидирующего резолвера и снаружи своей сети — и лучше не вручную, а мониторингом, который поймает истечение подписей раньше пользователей; подходы описаны в материале про мониторинг DNS.
Ротация ключей
Ключи меняют по расписанию, и обе процедуры устроены так, чтобы в любой момент времени существовал ключ, которому резолвер уже доверяет.
- Смена ZSK — новый ключ сначала публикуется в зоне рядом со старым, затем начинает подписывать, и только потом старый удаляется. Родительскую зону это не затрагивает.
- Смена KSK — сложнее: пока в родительской зоне не появится новый DS и не истечёт TTL старого, удалять прежний ключ нельзя. Практически всегда какое-то время в родительской зоне живут обе DS-записи.
Если DNS-хостинг умеет автоматическую ротацию и поддерживает публикацию CDS, лучше положиться на неё: ручная смена KSK — самая частая причина «домен внезапно исчез» из всех операций с DNSSEC.
Зоны .ru и .рф, регистраторы и хостинги
Российские зоны верхнего уровня подписаны, а регистраторы принимают DS-записи через личный кабинет домена. Практические нюансы, которые стоит проверить до включения:
- Поддерживает ли ваш DNS-хостинг подпись зоны вообще — это отдельная функция, а не часть любого DNS-хостинга.
- Есть ли в интерфейсе регистратора раздел DNSSEC и какой формат он просит: готовую DS-запись целиком или отдельные поля.
- Автоматизирует ли связка «хостинг + регистратор» обновление DS. Если нет, ротацию KSK придётся сопровождать вручную.
- Что произойдёт при переносе домена к другому регистратору: DS-запись должна переехать вместе с ним, иначе цепочка порвётся.
Выбор DNS-хостинга и его влияние на устойчивость разобраны в материалах про типы DNS-серверов и anycast-DNS.
Ограничения DNSSEC
- Не шифрует запросы. Кто и какие домены спрашивал, видно на пути. Это задача DoH и DoT.
- Увеличивает размер ответов. Подписи и ключи занимают место, из-за чего чаще происходит переход на TCP и возможны проблемы с оборудованием, которое режет большие UDP-пакеты.
- NSEC позволяет перечислить зону. Полный список имён зоны — не секрет по замыслу протокола, но раскрывать его редко хочется; для этого существует NSEC3 с хешированием имён.
- Повышает цену ошибки. До DNSSEC ошибка в записи ломала одну запись; с DNSSEC ошибка в ключе ломает домен целиком.
- Не защищает от подмены содержимого сайта. DNSSEC гарантирует, что вы получили правильный IP-адрес, а не то, что на этом адресе законный сервер с валидным сертификатом — это зона ответственности TLS, проверить которую можно на странице проверки SSL.
DNSSEC вместе с DoH и DoT
Эти механизмы не заменяют друг друга и закрывают разные участки пути:
- DNSSEC — подлинность данных от авторитативного сервера до резолвера, независимо от канала.
- DoH и DoT — шифрование участка «клиент — резолвер», то есть приватность от провайдера и от соседа по Wi-Fi.
Полная картина выглядит так: зона подписана DNSSEC, клиент ходит к валидирующему резолверу по зашифрованному каналу. Тогда ответ и подлинный, и не виден посторонним. Подробности транспорта — в материале про DNS over HTTPS.
Частые вопросы
Нужен ли DNSSEC обычному сайту?
Он полезен любому домену, но критичен там, где подмена адреса даёт немедленную выгоду атакующему: почта, платежи, личные кабинеты, административные панели. Для витрины-визитки это разумная гигиена, а не обязательное требование. Взвешивайте не только выгоду, но и цену ошибки: домен без сопровождения, где никто не заметит истёкшие подписи, безопаснее оставить неподписанным.
Замедляет ли DNSSEC работу сайта?
Дополнительные проверки стоят резолверу времени, но результат кэшируется, и на фоне остальных этапов загрузки страницы вклад мал. Заметный эффект возможен в другом месте: ответы становятся больше, и если сеть плохо пропускает крупные UDP-пакеты, появляются повторные запросы по TCP. Это лечится выбором алгоритма с короткими подписями и корректным EDNS.
Как отключить DNSSEC, если домен уже недоступен?
Удалите DS-запись у регистратора — это снимает требование подписи. Восстановление не мгновенное: пока старая DS-запись живёт в кэшах резолверов, часть пользователей продолжит получать отказ. Никакими действиями на своей стороне этот кэш не сбросить, поэтому ждать придётся до истечения TTL.
Что делать при переезде на другой DNS-хостинг?
Снять DS, дождаться истечения его TTL, перевести NS-записи, включить подпись на новом хостинге и опубликовать новый DS. Совмещать смену NS с активной DS-записью нельзя, если новый хостинг не импортировал те же ключи.
Почему домен открывается у меня, но не у клиента?
Почти всегда потому, что резолвер клиента валидирует подписи, а ваш — нет. Проверьте домен через публичный валидирующий резолвер и сравните ответы с флагом +cd и без него: разница означает проблему именно с DNSSEC.
Защищает ли DNSSEC от фишинговых доменов-двойников?
Нет. Он подтверждает, что ответ для запрошенного имени подлинный, но ничего не говорит о том, что имя принадлежит той организации, о которой думает пользователь. Домен-двойник может быть подписан не хуже вашего.
Чеклист внедрения DNSSEC
- DNS-хостинг поддерживает подпись зоны, а регистратор — публикацию DS.
- Порядок включения соблюдён: сначала подпись зоны, потом DS у регистратора.
- Алгоритм выбран современный, дайджест DS — SHA-256.
- Цепочка проверена снаружи: DNSKEY и RRSIG в зоне, DS у родителя, флаг
ADв ответе валидирующего резолвера. - Проверка с
+cdвнесена в план диагностики — она отделяет проблемы подписи от недоступности. - Известно, кто и по какому расписанию переподписывает зону, и что произойдёт при остановке этого процесса.
- Ротация KSK описана заранее: кто обновляет DS у регистратора и в каком порядке.
- Мониторинг ловит истечение подписей и отказ резолвера до того, как это заметят пользователи.
- Порядок отключения зафиксирован: DS, ожидание TTL, снятие подписи — и никак иначе.