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

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

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

Типовые причины инцидентов:
— NS в родительской зоне не совпадает с авторитетными серверами дочерней зоны.
— Glue-записи отсутствуют или указывают на невалидный адрес.
— В дочерней зоне нет SOA/NS на нужном уровне, а делегирование указывает на несуществующий apex.
— Подзона случайно продолжает обслуживаться и родителем, и дочерью; дальше начинается конфликт источников истины.

При разборе смотрим не только на ответ, но и на цепочку: parent NS, child NS, glue, SOA, TTL и кэш резолвера. Отдельно проверяем, нет ли циклической ссылки на сам делегируемый домен, и не протух ли старый NS у части резолверов. Стабильность DNS — это фундамент, а не опция.

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