Как проверить glue-записи, если собственные NS не находятся

Если домен делегирован на собственные серверы вида ns1.example.com, но их адреса нельзя получить, сначала проверьте делегирование в родительской зоне. Для таких NS родитель обычно должен вернуть glue-записи A и/или AAAA — иначе возникает круг: чтобы найти DNS-сервер, резолверу нужно обратиться к зоне, которая доступна только через этот сервер.

Короткий порядок проверки: посмотрите ответ родительской зоны, сравните содержащиеся в нём адреса с реальными IP каждого NS, затем запросите SOA зоны напрямую у каждого сервера. Если glue отсутствует или устарел, исправлять нужно объект DNS-сервера у регистратора, а не только A-запись внутри своей зоны.

Когда glue-запись действительно нужна

Glue — это адрес DNS-сервера, который родительская зона передаёт вместе с делегированием. Она обязательна прежде всего тогда, когда имя сервера находится внутри делегируемого домена: например, зона example.com использует ns1.example.com.

Без адреса ns1.example.com резолвер не знает, куда отправить запрос за данными example.com. А получить этот адрес из самой зоны ещё нельзя, потому что её авторитетный сервер пока не найден.

Если домен использует внешние NS, например серверы DNS-провайдера в другом домене, циклической зависимости обычно нет. Создавать для них glue в панели своего регистратора не требуется: их адреса разрешаются через другую цепочку DNS.

Что подготовить до проверки

Зафиксируйте четыре значения:

• домен и его зона верхнего уровня;
• полный список NS, указанный у регистратора;
• текущие IPv4 и IPv6 каждого собственного NS;
• время проверки и вывод команд, чтобы отличить новое состояние от кэша.

В примерах ниже используются зарезервированные имена и адреса. Замените example.com, имена серверов и IP на свои значения.

Пошаговая диагностика делегирования

1. Посмотрите цепочку от корневых серверов

Начните с трассировки:

dig +trace example.com NS

Найдите ответ родительской зоны. Для домена второго уровня это обычно ответ серверов зоны верхнего уровня: они должны перечислить делегированные NS. В секции AUTHORITY будут имена серверов, а в ADDITIONAL — доступные A/AAAA для собственных NS.

Важно смотреть именно ответ родителя, а не результат обычного запроса через домашний или корпоративный резолвер: тот может вернуть закэшированные данные.

2. Запросите родительский сервер напрямую

Возьмите имя одного родительского сервера из dig +trace и выполните запрос без рекурсии:

dig @<родительский-NS> example.com NS +norecurse

Проверьте три вещи:

1. В AUTHORITY перечислены все ожидаемые NS.
2. Для каждого NS внутри example.com в ADDITIONAL есть актуальная A, AAAA или обе записи.
3. Ответ не помечен флагом TC, то есть не был обрезан.

Если ответ обрезан, повторите запрос по TCP:

dig +tcp @<родительский-NS> example.com NS +norecurse

Отсутствие адреса внешнего DNS-сервера в ADDITIONAL само по себе не ошибка. Критичен адрес сервера, имя которого находится внутри делегируемой зоны.

3. Сравните glue с адресами самих NS

Проверьте, куда сейчас разрешается имя каждого сервера:

dig A ns1.example.com
dig AAAA ns1.example.com
dig A ns2.example.com
dig AAAA ns2.example.com

Сопоставьте результат с адресами из ответа родительской зоны. Типичная неисправность возникает после переноса: A-запись в дочерней зоне уже указывает на новый сервер, а glue у регистратора всё ещё содержит старый IP.

Обычный рекурсивный ответ может скрыть расхождение из-за кэша. Для вывода о glue опирайтесь на прямой ответ родителя, а дочерние A/AAAA используйте для сравнения.

4. Проверьте каждый DNS-сервер по IP

Даже правильный glue бесполезен, если сервер не отвечает или не обслуживает нужную зону. Запросите SOA напрямую по каждому IP:

dig @192.0.2.53 example.com SOA +norecurse
dig +tcp @192.0.2.53 example.com SOA +norecurse

Адрес 192.0.2.53 приведён только как пример — подставьте реальный IP. Повторите проверку для каждого IPv4 и IPv6.

Если запрос по IP возвращает авторитетный SOA, а обычное разрешение домена ломается и в родительском ответе нет адреса собственного NS, причина действительно похожа на missing glue. Если по IP нет ответа, сначала проверяйте запущен ли DNS-сервис, загружена ли зона, открыт ли порт 53 по UDP и TCP и не блокирует ли трафик firewall.

5. Сверьте родительскую и дочернюю стороны

У делегирования две стороны:

• родитель хранит NS и glue;
• дочерняя зона хранит свой NS-набор и адреса хостов.

Имена NS у родителя и в самой зоне должны согласовываться. Адреса glue должны вести на серверы, которые действительно авторитетно отвечают за домен. Разный набор NS, старый IP или сервер без загруженной зоны дают разные симптомы, поэтому одной проверки A-записи недостаточно.

Где исправлять glue

В панели регистратора ищите сущность с названием «DNS-сервер», «хост», «дочерний сервер», «host object» или «glue record». Сначала убедитесь, что новый DNS-сервис уже отвечает на новом IP, затем измените адрес объекта NS и проверьте делегирование.

Не удаляйте старый сервер сразу после изменения. Родительские и рекурсивные серверы могут хранить прежние данные до истечения TTL, поэтому на переходный период старый и новый адреса должны оставаться работоспособными, если это допускает схема переноса.

После обновления повторите прямой запрос к родительским NS и трассировку. Затем проверьте домен через несколько независимых рекурсивных резолверов и из другой сети: один успешный ответ ещё не доказывает, что все пользователи уже видят новую цепочку.

Как читать результат

| Наблюдение | Вероятная причина | Следующий шаг | |---|---|---| | Собственный NS указан, но его адреса нет у родителя | Glue не создан или не опубликован | Зарегистрировать адрес хоста NS у регистратора | | У родителя старый IP, в дочерней зоне новый | Устаревший glue | Обновить объект NS у регистратора, временно сохранить старый сервер | | Glue верный, но SOA по IP не отвечает | DNS-сервис, сеть или firewall | Проверить порт 53 UDP/TCP и загрузку зоны | | NS по IP отвечает, но неавторитетно | Нужная зона не подключена к серверу | Исправить конфигурацию авторитетного DNS | | У родителя и в зоне разные NS | Несогласованное делегирование | Привести наборы NS к одной рабочей схеме | | Ошибка остаётся только у части пользователей | Кэш или частичная сетевая недоступность | Сравнить ответы разных резолверов и дождаться TTL |

Частые ошибки

• Менять только A/AAAA внутри дочерней зоны. Это не обновляет glue у родителя.
• Пытаться добавить glue для любого внешнего NS. Сначала определите, находится ли имя сервера внутри делегируемого домена.
• Проверять только один из двух NS. Делегирование может выглядеть рабочим, пока запрос не попадёт на второй сервер.
• Тестировать только UDP. Полноценный авторитетный DNS должен корректно обслуживать и TCP-запросы.
• Делать вывод по одному закэшированному ответу. Для диагностики нужен прямой запрос к родительской зоне.

Если домен после исправления всё ещё возвращает SERVFAIL, продолжите диагностику по инструкции «DNS SERVFAIL: почему сайт не открывается и что проверить». При недавней смене записей также полезна статья «DNS-записи не обновляются: почему сайт открывается не у всех».

Что делать после восстановления DNS

Разовая проверка подтверждает состояние только в момент запроса. После исправления можно настроить Web-Puls, чтобы регулярно проверять доступность сайта и быстрее заметить повторный сбой.

Если у вас нет доступа к объектам NS у регистратора или нужно безопасно провести перенос без разрыва делегирования, отправьте заявку на профессиональную поддержку: укажите домен, время появления ошибки и уже проверенные NS, но не прикладывайте пароли и ключи.