Неверное делегирование DNS ломает зону тише, чем любой таймаут на апстриме

Неверное делегирование DNS ломает зону тише, чем любой таймаут на апстриме

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

Типовые причины инцидентов:
— NS указан, но glue для него не опубликован или устарел.
— Делегирование ведет на сервер, который не авторитетен для дочерней зоны.
— Один из NS не отвечает, а второй не покрывает весь трафик по RTT и географии.
— Parent и child живут в разных конфигурациях после ручного изменения.

При разборе смотрим не только на логи авторитативных серверов, но и на цепочку целиком: parent zone, child zone, glue records, SOA/NS-согласованность, ответ на trace. Полезно проверять, одинаково ли видят делегирование внешние резолверы и ваш monitoring. И да, «починить потом» здесь обычно означает оставить нестабильность в проде на неопределенный срок.

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