Зачем проверять DNS-зону перед запуском
Проверка DNS-зоны — это не формальность, а способ увидеть зону глазами резолвера, а не панели управления. Панель хостинга показывает то, что записано в базе, а dig показывает то, что реально отдают авторитативные серверы. Расхождение между этими двумя картинами — самая частая причина «сайт не открывается» и «письма не доходят» через сутки после смены настроек.
Проверку стоит делать в трёх случаях: сразу после изменения записей, после переезда на новые NS-серверы и перед публикацией любого нового домена в проде.
Команда dig: как читать ответ сервера
Базовый синтаксис: dig ИМЯ ТИП. Чтобы получить A-запись домена, выполните:
dig example.com A +shortФлаг +short убирает служебный вывод и оставляет только IP-адреса. Для полной картины с TTL, флагами и секцией AUTHORITY уберите его:
dig example.com MXВ ответе важны три блока: ANSWER SECTION — сами записи, AUTHORITY SECTION — какие NS-серверы считаются источником, и строка flags: qr rd ra; — если в ней нет ra (recursion available), значит сервер не резолвит рекурсивно и вы, скорее всего, спросили не тот сервер.
Чтобы спросить конкретный сервер напрямую, минуя кэш локального резолвера, укажите его через @:
dig @8.8.8.8 example.com AКак проверить делегирование и NS-серверы
Отдельная проверка нужна для самого делегирования — то есть для того, что родительская зона (реестр домена) знает о ваших NS-серверах. Команда:
dig example.com NS +traceФлаг +trace проходит путь от корневых серверов до авторитативных, показывая каждый шаг делегирования. Если на каком-то этапе список NS расходится с тем, что вы видите в панели регистратора, — это и есть источник проблемы: реестр домена ещё хранит старые сервера, или наоборот, зона на новых серверах ещё не поднята. Это особенно важно после делегирования поддомена на отдельные NS.
Сравните ответ на уровне родительской зоны и на уровне самих авторитативных серверов:
dig example.com NS @a.gtld-servers.net
dig example.com NS @ns1.example.comЕсли списки не совпадают — синхронизация ещё не завершена, ждите или проверяйте регистратора.
dnsviz: визуальная проверка DNSSEC-цепочки
Для DNSSEC одного dig мало — цепочку доверия удобнее смотреть в dnsviz. Онлайн-версия строит граф зоны и подсвечивает разрывы: отсутствующий DS-запись в родительской зоне, просроченную подпись RRSIG или несовпадение алгоритма. Локально запустить проверку можно так:
pip install dnsviz
dnsviz probe example.com | dnsviz printКрасные узлы на графе — это конкретные ошибки цепочки: от них и нужно отталкиваться при диагностике, а не гадать заново.
Типовые ошибки при проверке зоны
Большинство проблем укладываются в несколько повторяющихся сценариев:
| Симптом в dig | Вероятная причина |
|---|---|
| SERVFAIL на все запросы | Сломана DNSSEC-цепочка или зона не отвечает |
| NXDOMAIN при существующем домене | Опечатка в имени или зона ещё не опубликована |
| Разные ответы от разных NS | Записи не синхронизированы между серверами |
| Нет секции ANSWER, только AUTHORITY | Запрошен не тот тип записи или делегирование сломано |
Чек-лист перед публикацией домена
- Проверьте A, AAAA и MX через
dig +short— значения совпадают с панелью. - Сверьте NS через
dig NS +trace— родитель и авторитативные серверы согласованы. - Если включён DNSSEC, прогоните домен через dnsviz и закройте все красные узлы.
- Опросите минимум два публичных резолвера (например, 8.8.8.8 и 1.1.1.1), чтобы исключить локальный кэш.
- Повторите проверку через 30–60 минут после изменений — часть данных живёт в TTL кэше.