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

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

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

Типовые следы инцидента:
— в parent зона делегирована на NS, которых нет в child;
— в child нет совпадающих NS-записей;
— glue в родителе указывает на устаревшие адреса;
— один из authoritative-серверов недоступен, а балансировка доверена удаче.

Проверка всегда начинается с трассировки цепочки делегирования: parent → child → authoritative answer. Смотрим на RTT, повторные попытки и различие между ответами разных рекурсоров. Если один резолвер стабильно видит зону, а другой — NXDOMAIN или SERVFAIL, это почти всегда не «магия кеша», а рассинхрон делегирования. Стабильность DNS — это фундамент, а не опция.

Исключаем Human Error через автоматизацию: перед публикацией NS/glue валидируйте совпадение parent и child, проверяйте доступность всех authoritative-хостов и запрещайте ручные правки без контрольного прогона. Один несогласованный делегат способен превратить нормальную зону в распределенный источник шума.