ProNotes

DNSSEC‑валидация — это проверка криптографических подписей DNS‑записей рекурсивным резолвером по цепочке доверия от корня до запрашиваемого домена, с целью отсеять подменённые или повреждённые ответы. Основная сложность — не столько криптография, сколько ошибки в цепочке (DNSKEY/DS/RRSIG), кей‑ролловеры и смешанные среды с невалидирующими резолверами.[1][2][3][4][5][6]

## Базовый процесс валидации

- Рекурсивный резолвер имеет доверенный **trust anchor** — публичный ключ корня (DNSKEY root), который администратор или ПО обновляет по RFC 5011.[2][3][5]
- При запросе, скажем, A для example.com, резолвер:
  - спрашивает корень, получает NS для .com и DS для .com, валидирует DS/.com‑DNSKEY против ключа корня;  
  - спрашивает .com, получает NS и DS для example.com, валидирует DNSKEY example.com по DS из .com;  
  - спрашивает авторитативный сервер example.com, получает RRset (A), RRSIG(A) и DNSKEY (ZSK/KSK) и проверяет подпись RRSIG(A) публичным ZSK.[3][1][2]
- Если все подписи и DS‑цепочка сходятся до trust anchor — ответ считается **Secure** и отдаётся клиенту; при несоответствии — **SERVFAIL** и для имени формируется состояние **Bogus**.[7][5][2]

## Ключи, записи и цепочка доверия

- В зоне обычно два типа ключей:
  - **ZSK** (Zone Signing Key) подписывает все RRset в зоне;  
  - **KSK** (Key Signing Key) подписывает только RRset DNSKEY и чья хэш‑форма публикуется как DS у родителя.[8][3]
- Для валидации резолверу нужны:
  - RRset + RRSIG(RRset);  
  - DNSKEY (как минимум публичный ZSK и KSK) + RRSIG(DNSKEY);  
  - DS в родительской зоне + RRSIG(DS).[9][1][3]
- Для отрицательных ответов (NXDOMAIN/NODATA) используются NSEC/NSEC3 + их RRSIG, чтобы доказать отсутствие записи без возможности «дошить» поддельные ответы.[4][3]

## Типовые проблемы

- **Несогласованность DNSKEY/DS**:  
  - DS в родителе не соответствует текущему KSK (например, не обновили DS после key‑rollover) → для домена всё становится Bogus.[6][4]
  - Кэш на промежуточных резолверах содержит старый DNSKEY, а RRSIG уже подписан новым ключом → временные отказы.[6]
- **Проблемы с RRSIG**:  
  - истёкший срок действия подписи (expiration), неправильно настроенный time, ошибка генерации → валидация падает, ответы Bogus.[4][6]
  - отсутствие RRSIG для защищаемой записи или подпись неверным ключом.[4][6]
- **NSEC/NSEC3 глюки**:  
  - неверно собранные цепочки NSEC/NSEC3 или отсутствие подписей на отрицательные ответы → валидатор не может «красиво» доказать отсутствие записи и помечает ответ как Bogus.[6][4]
- **Смешанные резолверы у клиента**:  
  - часть резолверов валидирует, часть нет; при SERVFAIL клиент переходит к следующему резолверу и получает невалидированный (или поддельный) ответ, что убивает смысл DNSSEC.[10][5]

## Инженерные решения и best‑practices

- **Аккуратные key‑rollover’ы**:  
  - использовать стандартизованные процедуры KSK/ZSK‑ролловера с overlap‑периодами (старый и новый ключи опубликованы и валидны одновременно);  
  - контролировать, что DS обновился у родителя и распространён по TLD перед удалением старого KSK.[2][6]
- **Мониторинг и тесты**:  
  - постоянные проверки «цепочки доверия» (DNSKEY↔DS, актуальность RRSIG, корректность NSEC/NSEC3);  
  - онлайн‑тесты для валидации (DNSSEC‑resolver‑test, специальные тестовые домены) и alert’ы по ошибкам «Did not match a DS to a DNSKEY», «expired RRSIG» и т.п.[10][4][6]
- **Кэширование и TTL**:  
  - осознанно выбирать TTL для DNSKEY/DS/RRSIG, чтобы минимизировать окна, когда разные резолверы видят разные версии ключей;  
  - избегать слишком длинных TTL при частой смене ключей.[5][6]
- **Инфраструктурный дизайн**:  
  - все резолверы в организации должны валидировать DNSSEC и быть синхронизированы по времени (NTP как обязательное условие);  
  - при override’ах (split‑DNS, локальные зоны) не ломать DNSSEC для внешних доменов: не подменять ответы с RRSIG, которые резолвер ожидает валидировать.[11][12][13]

## Что важно учитывать на практике

- Валидирующий резолвер **не защищает** от подмены, если:  
  - домен не подписан DNSSEC (нет DS/DNSKEY);  
  - клиент использует одновременно валидирующие и невалидирующие резолверы.[12][5][10]
- С инженерной точки зрения основная «боль» — это не включить DNSSEC, а потом без простоев жить с ротацией ключей, сменой регистраторов/NS и отладкой странных SERVFAIL‑ов.[14][15][6]

Если нужно, можно разобрать конкретный кейс — например, как правильно делать rollover KSK/ZSK для вашей зоны на BIND/PowerDNS или как настраивать валидирующий резолвер (unbound/BIND) с логированием причин провала валидации.

[1](https://www.cloudflare.com/learning/dns/dnssec/how-dnssec-works/)
[2](https://www.catchpoint.com/dns-monitoring/dnssec-validation)
[3](https://bunny.net/academy/dns/what-is-dnssec-and-how-does-it-work/)
[4](https://support.site24x7.com/portal/en/kb/articles/dnssec-validation)
[5](https://blog.apnic.net/2023/10/31/how-we-measure-dnssec-validation/)
[6](https://www.osti.gov/servlets/purl/1110294)
[7](https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-validator-requirements-07.html)
[8](https://www.ibm.com/think/topics/dnssec)
[9](https://dnsinstitute.com/documentation/dnssec-guide/ch03s03.html)
[10](https://wander.science/projects/dns/dnssec-resolver-test/)
[11](https://learn.microsoft.com/en-us/windows-server/networking/dns/validate-dnssec-responses)
[12](https://www.imperva.com/learn/application-security/dnssec/)
[13](https://support.box.com/hc/en-us/articles/24942482402579-Troubleshooting-DNSSEC-Validation)
[14](https://community.spiceworks.com/t/dnssec-validation-for-remote-responses-enabled-short-term-resolving-failures/734898)
[15](https://bind9.readthedocs.io/en/v9.18.15/dnssec-guide.html)
[16](https://bluecatnetworks.com/blog/breaking-down-dnssec-how-does-it-work/)
[17](https://www.dns-oarc.net/oarc/services/odvr)
[18](https://www.youtube.com/watch?v=4qlIim15xwM)
[19](https://clouddocs.f5.com/training/community/dns/html/class2/module5/module5.html)
[20](https://www.reddit.com/r/dns/comments/1euakl0/what_are_the_pain_points_in_dnssec_that_prevent/)