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

  • Рекурсивный резолвер имеет доверенный 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/)

[file-name 000310_2026-01-02_07-29-49.txt]