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

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

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

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

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

Исключаем Human Error через автоматизацию: валидируйте делегирование до публикации, а после изменения прогоняйте контрольный запрос с внешних резолверов и прямой опрос NS. Если цепочка рвется на любом участке, инцидент уже сидит в конфигурации, а не в сети.