DNSSEC: цепочка доверия и сбой валидации

Ваша DNS-запись выглядит корректно во всех авторитативных инструментах. Но 30% пользователей не могут открыть ваш сайт — они видят DNS_PROBE_FINISHED_NXDOMAIN. Остальные 70% работают нормально. Разница не в провайдере; разница в том, валидирует ли их резолвер DNSSEC. На прошлой неделе вы ротировали KSK и забыли обновить DS-запись у родительского регистратора. Цепочка оборвалась.

Что делает DNSSEC и чего не делает

DNSSEC аутентифицирует DNS-ответы: он доказывает, что A-запись для bank.example пришла от легитимного авторитативного сервера и не была подделана в пути. Он не шифрует DNS-сообщения — перехватчик по-прежнему видит, какой домен вы запрашивали; этим занимаются DoH и DoT. DNSSEC валидирует данные; шифрование скрывает запросы.

Роли ключей: ZSK и KSK

Каждая подписанная зона публикует два типа ключей:

• ZSK (Zone Signing Key) — подписывает фактические RRset-данные (A-, MX-, TXT-записи и т. д.). Ротируется часто (на практике каждые 1–3 месяца).
• KSK (Key Signing Key) — подписывает только DNSKEY RRset, который публикует ZSK. Ротируется редко (каждые 1–3 года). Его хэш публикуется в родительской зоне как запись DS (Delegation Signer).

Разделение существует затем, чтобы ротация ZSK была дешёвой (без обновления у родителя), а ротация KSK — требующая координации с родителем — происходила редко.

Цепочка доверия

Каждый валидирующий резолвер хранит один жёстко заданный якорь доверия: отпечаток KSK корневой зоны. Валидация идёт сверху вниз:

1. Резолвер держит отпечаток KSK корня как якорь доверия.
2. Корень публикует DNSKEY (KSK корня + ZSK корня). Резолвер проверяет, что KSK корня совпадает с якорем доверия.
3. ZSK корня подписывает DS-запись для .com. Резолвер верифицирует DS .com с помощью ZSK корня.
4. .com публикует DNSKEY (KSK и ZSK .com). Резолвер проверяет, что KSK .com совпадает с хэшем из DS шага 3.
5. ZSK .com подписывает DS-запись для example.com. И так далее, вплоть до листовой зоны.
6. ZSK листовой зоны подписывает A-запись. RRSIG идёт с ответом.
7. Если каждый шаг верифицируется → пометить ответ AD (Authentic Data). Если любой шаг падает → пометить BOGUS → вернуть SERVFAIL.

Режим отказа при ротации KSK

Самый распространённый инцидент DNSSEC:

1. Оператор генерирует новый KSK в дочерней зоне.
2. Оператор обновляет DNSKEY в дочерней зоне — новый KSK теперь подписывает DNSKEY RRset.
3. Оператор забывает обновить DS-запись у родительского регистратора.
4. Результат: DS у родителя содержит хэш старого KSK; RRSIG в дочерней зоне создан новым KSK.
5. Валидирующие резолверы получают DNSKEY дочерней зоны, верифицируют RRSIG — он валиден с новым KSK — но затем проверяют DS у родителя и обнаруживают, что хэш не совпадает. Цепочка оборвана → BOGUS → SERVFAIL.

Только резолверы, валидирующие DNSSEC (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9), возвращают SERVFAIL. Невалидирующие резолверы провайдеров отдают неподписанный ответ в обычном режиме. Это разделяет трафик: примерно 30–40% глобальных пользователей (те, кто на валидирующих резолверах) не могут открыть сайт; остальные — могут.

$ dig @1.1.1.1 +dnssec api.bank.example
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41832
;; flags: qr rd ra; QUERY: 1, ANSWER: 0

$ dig @8.8.8.8 +dnssec api.bank.example
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8821

$ dig @1.1.1.1 +cd api.bank.example     # +cd = checking disabled
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1284
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1
api.bank.example.   60   IN   A   203.0.113.42

NSEC vs NSEC3: отрицание существования

DNSSEC должен также доказывать, что имя не существует — иначе атакующий мог бы удалить запись и заявить «нет A-записи для bank.example». Механизм:

• NSEC: цепочка имён зоны в алфавитном порядке. «Между alpha.example.com и zebra.example.com ничего нет.» Легко верифицировать, но позволяет атакующему обходить все NSEC-записи и перечислять всю зону.
• NSEC3 (RFC 5155): хеширует имена с солью перед включением в цепочку. Соседние элементы в цепочке — хеш-соседи, а не алфавитные. Предотвращает тривиальное перечисление зоны; атака с таблицами радужных хешей всё ещё возможна, но затратна.
• NSEC5 (предложен/экспериментален): использует верифицируемые случайные функции; широко не развёрнут.

Операционная рекомендация: используйте NSEC3 для зон, где перечисление критично (корпоративные интрасети, поддомены клиентов); NSEC подходит для публичных зон, содержимое которых и так известно.

Требование CA/Browser Forum 2026

Ballot SC-085v2 CA/Browser Forum (вступил в силу 15 марта 2026 года) обязывает все публично доверенные центры сертификации валидировать DNSSEC при его наличии во время Domain Control Validation и проверок CAA. Если у вашего домена неправильно настроена цепочка DNSSEC — просроченные подписи, сломанная делегация, неверный DS — CA откажет в выдаче или продлении TLS-сертификата до исправления цепочки. Это не обязывает активировать DNSSEC; зоны, которые никогда не были подписаны, не затрагиваются. Но домены, подписавшие свои зоны, теперь обязаны поддерживать цепочку в рабочем состоянии, иначе потеряют возможность получать новые сертификаты.