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

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

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

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

Проверяем не только записи, но и контекст: совпадают ли NS в parent и child, доступны ли сами серверы по A/AAAA, нет ли циклического делегирования, не уехали ли unsigned/SERVFAIL из-за DS/DNSSEC несостыковки. Стабильность DNS — это фундамент, а не опция. Один неверный NS у регистратора способен маскироваться под «интернет иногда тормозит» очень долго.

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