Если сайт то открывается, то нет после изменения DNS, сначала запросите SOA и критичные записи отдельно у каждого авторитетного NS. Разные SOA serial обычно показывают, что серверы обслуживают разные версии зоны; одинаковый serial при разных ответах указывает на более глубокую рассинхронизацию конфигурации или данных.
Проверка через один обычный DNS-резолвер недостаточна: он может вернуть закэшированный ответ только от одной версии зоны. Нужен прямой опрос всех NS без рекурсии с фиксацией времени, кода ответа, флага авторитетности и самих записей.
Почему авторитетные DNS-серверы расходятся
Чаще всего изменение попало не во все копии зоны. Вторичный сервер мог не получить обновление, зона на одном узле могла не загрузиться, а в делегировании у регистратора мог остаться старый NS.
Есть и менее очевидный вариант: разные панели или DNS-провайдеры управляют разными наборами записей. Тогда владелец меняет A-запись в одном месте, но часть запросов продолжает попадать на другой авторитетный сервер.
Случайная проверка может не обнаружить проблему. Рекурсивные резолверы выбирают NS самостоятельно, поэтому два пользователя способны получить разные ответы на одно имя.
Как сравнить все NS по шагам
1. Получите список серверов из делегирования
Начните с обычного запроса и трассировки:
dig NS example.ru
dig +trace NS example.ruВыпишите все NS, которые сообщает родительская зона, и сравните их со списком в панели DNS. Если у регистратора указан сервер, которого уже нет в рабочей схеме, он всё равно может получать запросы.
Проверяйте не только имена NS, но и возможность разрешить их адреса. Для собственных серверов внутри делегируемого домена отдельно контролируют glue-записи у родительской зоны.
2. Запросите SOA у каждого сервера напрямую
Для каждого NS выполните отдельный запрос без рекурсии:
dig +norecurse SOA example.ru @ns1.provider.example
dig +norecurse SOA example.ru @ns2.provider.exampleСравните четыре признака:
- код ответа, например NOERROR, SERVFAIL или REFUSED;
- наличие флага aa — ответ должен быть авторитетным;
- имя зоны и поля SOA;
- значение serial.
SOA serial — версия зоны, а не гарантированная календарная дата. По RFC 1982 это 32-битное последовательное число со специальными правилами сравнения, поэтому после перехода через границу диапазона простое правило «большее число новее» может дать неверный вывод.
Кратковременное различие возможно во время распространения обновления между авторитетными серверами. Если расхождение сохраняется дольше ожидаемого для вашей DNS-схемы, проверьте журналы передачи зоны, состояние вторичных серверов и панель провайдера.
3. Сравните записи, влияющие на сайт
Одинакового SOA недостаточно. Запросите одну и ту же запись у каждого NS:
dig +norecurse A www.example.ru @ns1.provider.example
dig +norecurse A www.example.ru @ns2.provider.example
dig +norecurse AAAA www.example.ru @ns1.provider.example
dig +norecurse CNAME www.example.ru @ns1.provider.exampleПовторите проверку для имени без www, почтовых MX, важных TXT и других записей, которые менялись. Сравнивайте тип, значение и TTL. Если используется CNAME, отдельно проверьте сам CNAME и конечное имя: ошибка может находиться уже в другой зоне.
Не ограничивайтесь выводом IP-адреса. Один NS может вернуть NXDOMAIN, другой — старый адрес, а третий — новый CNAME; для посетителей это три разных сценария отказа.
Как интерпретировать результат
| Наблюдение | Вероятное направление проверки | |---|---| | Разные serial и разные записи | Один из серверов ещё обслуживает прежнюю версию зоны | | Одинаковый serial, но записи различаются | Источники данных не синхронизированы или serial не обновили при изменении | | Один NS отвечает SERVFAIL, REFUSED или без aa | Зона не загружена, сервер не авторитетен либо запросы ограничены | | Сервер есть у родителя, но отсутствует в рабочей панели | Делегирование и текущая DNS-схема расходятся | | Все авторитетные ответы одинаковы, а пользователи видят старые данные | Проверьте TTL, кэш рекурсивного резолвера, локальный кэш и время изменения |
Таблица помогает выбрать ветку, но не доказывает первопричину сама по себе. Например, управляемый DNS может хранить зону в распределённой базе, а не передавать её классическим AXFR; способ синхронизации нужно уточнять у провайдера.
Безопасный порядок исправления
- Зафиксируйте текущие ответы всех NS и время проверки.
- Определите, какая версия зоны должна быть рабочей.
- Проверьте источник данных, загрузку зоны и синхронизацию каждого сервера.
- Внесите исправление через авторитетную панель или конфигурацию; не правьте узлы по одному без понятного источника истины.
- Убедитесь, что serial изменился корректно и все NS отдают одинаковые критичные записи.
- Снова сравните делегирование у родителя и NS внутри зоны.
- Только после проверки удаляйте устаревший сервер из делегирования.
Не пытайтесь скрыть рассинхронизацию уменьшением TTL. Низкий TTL ускоряет обновление кэшей, но не заставляет авторитетные серверы обслуживать одну и ту же версию зоны.
Что ещё может мешать проверке
При DNSSEC одинаковые записи на NS ещё не гарантируют успешную валидацию: отдельно проверяют цепочку доверия и подписи. Если серверы работают через anycast, запросы из одной сети могут попасть только на один узел; при плавающем сбое полезно повторить сравнение из независимой сети или передать провайдеру точное время и полный вывод запросов.
После выравнивания зоны имеет смысл контролировать публичную доступность сайта в Web-Puls. Такой контроль помогает заметить повторный сбой по фактическому ответу сайта, но не заменяет прямой поадресный опрос каждого авторитетного NS.
Если ответы продолжают расходиться и непонятно, где находится источник истины, отправьте заявку на профессиональную поддержку. Укажите домен, время и часовой пояс проверки, список NS и обезличенный вывод SOA/A/AAAA; пароли, токены и доступ к панели в описании не нужны.