Неверное делегирование DNS ломает зону тихо: как читать инцидент без гаданий

Неверное делегирование DNS ломает зону тихо: как читать инцидент без гаданий

Давайте разберем флоу запроса. При делегировании родительская зона отдает NS для дочерней, а резолвер потом идет уже к ним. Если в этой цепочке есть рассинхрон, пользователь видит не «ошибку DNS», а таймаут, NXDOMAIN или странный флаппинг между авторитативами.

Типовые причины инцидентов:
— NS в родителе и в дочерней зоне не совпадают;
— glue-записи отсутствуют или указывают на старые адреса;
— один из серверов не содержит актуальную зону;
— подписи DNSSEC не сходятся с делегированием, и валидация режет ответы.
Посмотрим, что говорит по этому поводу RFC: делегирование должно быть консистентным на уровне имен, адресов и ответов.

При разборе инцидента сначала проверяют три точки: родительскую зону, саму дочернюю зону и путь до авторитативов. Если NS возвращаются разные, а один сервер молчит, это не «плавающая сеть», а сломанная схема управления зоной. Проверим влияние на RTT и консистентность зон: лишние запросы на fallback и повторные попытки быстро превращают локальную ошибку в массовую деградацию.

Практика простая: фиксируйте делегирование через единый источник правды, сверяйте NS/glue перед публикацией и автоматизируйте проверки непротиворечивости. Исключаем Human Error через автоматизацию: Стабильность DNS — это фундамент, а не опция.