DNSSEC ломают не ключи, а плохой план перехода между зонами

DNSSEC ломают не ключи, а плохой план перехода между зонами

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

Перед включением подписи проверьте три вещи:
— есть ли поддержка валидаторов у потребителей;
— как проходит обновление ключей и реколлапс подписи;
— что происходит при потере части записей или ошибке синхронизации между мастер и слейв.
Именно на этом этапе обычно рождаются «костыли» из отключенных валидаторов и ручных правок, которые потом трудно распутать.

Внедрение лучше делать поэтапно: сначала включить подпись на тестовой зоне, затем на дочерних, после чего аккуратно публиковать DS у родителя. Важен контроль TTL, времени жизни сигнатур и окна для rollover. Если автоматизация не умеет проверять RRSIG, DNSKEY и цепочку trust anchor, она лишь ускоряет ошибку.

Отдельно следите за NSEC/NSEC3 и размером ответов: DNSSEC увеличивает нагрузку на UDP-фрагментацию и может менять поведение резолверов. Проверим влияние на RTT и консистентность зон.

Стабильность DNS — это фундамент, а не опция. Вводите DNSSEC так, чтобы откат был так же формализован, как и включение: тогда инцидент не превратится в археологию из логов и ручных исключений.