DNS delegation и glue records: как проверить цепочку NS через dig +trace

Зачем разбираться в glue records и делегировании

Когда домен «не открывается», а в панели всё выглядит правильно, причина часто не в A/AAAA, а в делегировании: родительская зона (TLD/реестр) указывает на неверные NS, не хватает glue, или один из NS отвечает «не за эту зону» (классическая lame delegation).

Обычные запросы через рекурсивный резолвер скрывают детали: кеш, повторные попытки, выбор «лучшего» NS. А вот dig +trace показывает цепочку делегирования от корня до авторитетного сервера и помогает понять, на каком шаге всё ломается.

Ниже — практический разбор: что такое parent/child зоны, когда glue обязателен, как увидеть glue в ответах, как проверить согласованность NS и как диагностировать lame delegation.

Быстрый словарь: parent zone, child zone, NS и glue

Parent zone — родительская зона. Для example.com родитель — com. Именно в parent зоне хранится делегирование: на какие NS отправлять запросы к домену.

Child zone — дочерняя зона, сама зона example.com, которую обслуживают авторитетные NS.

NS — записи, которые указывают, какие nameserver’ы авторитетны для зоны. Они встречаются в двух местах:

• в parent зоне — делегирование (куда идти за ответом по зоне);
• внутри child зоны — «самоописание» зоны (обычно тот же набор NS).

Glue records — дополнительные A/AAAA для nameserver’ов, опубликованные в parent зоне рядом с делегированием. Они нужны, чтобы разорвать циклическую зависимость при разрешении имён NS.

Ключевая мысль: NS указывает на имя хоста, а не на IP. Чтобы обратиться к NS по имени, резолвер должен сначала узнать его IP. Если IP можно получить только из ещё не разрешившейся зоны, возникает «курица и яйцо» — и здесь нужен glue.

Если вы часто меняете NS при миграциях, полезно держать под рукой короткий чеклист и отдельные проверки для parent/child. Отдельно обратите внимание на нюансы vanity NS и «внутридоменных» NS в статье как проверять glue и vanity NS.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

И ещё один практический момент: проблемы делегирования часто всплывают во время переноса сайта/сервера. Если вы планируете перенос DNS-сервиса или переезд на новые IP, держите в голове сценарии «устаревший glue» и «старые NS в делегировании» — это самые частые причины плавающей доступности.

Когда glue обязателен (и когда он не нужен)

Glue нужен тогда, когда nameserver находится внутри делегируемого домена (in-bailiwick). Простой пример: зона example.com обслуживается на ns1.example.com и ns2.example.com.

Чтобы узнать IP ns1.example.com, резолвер должен спросить DNS для example.com. Но чтобы спросить DNS для example.com, ему уже нужен IP ns1.example.com. Цикл. Glue (A/AAAA для ns1.example.com и ns2.example.com в parent зоне com) позволяет «стартовать»: резолвер берёт IP из parent и уже по нему обращается к авторитетному серверу.

Если NS находится вне домена (например, ns1.provider.net), glue обычно не требуется: IP этого NS можно получить, разрешив provider.net независимо.

Важный нюанс: «лишний» glue может сыграть злую шутку при смене IP NS. Реальный NS уже переехал, а старый glue всё ещё кешируется и ведёт часть клиентов на старый адрес. Поэтому при миграции IP обязательно проверяйте, что обновили не только записи в зоне, но и host records (glue) у регистратора.

Чем glue отличается от обычной A/AAAA в зоне

Частая ошибка: «я же создал A-запись для ns1 в DNS-зоне, значит glue есть». Нет. A/AAAA в child зоне — это данные child. А glue — это данные parent зоны, опубликованные рядом с делегированием.

Практическое следствие: если вы меняете IP ns1.example.com и ns2.example.com, проверьте два места:

• в child зоне: A/AAAA для ns1/ns2;
• в parent зоне: glue A/AAAA (через настройки «host records / child nameservers / дочерние серверы» у регистратора).

Это часто два разных интерфейса: DNS-провайдер управляет зоной, а регистратор — делегированием и glue в реестре. Если домен вы регистрируете и обслуживаете у одного провайдера, проще держать всё в одном месте: регистрация доменов обычно включает и управление делегированием и host records из панели.

Типовые симптомы проблем делегирования

1) Нет glue при in-bailiwick NS

Симптом: часть клиентов (или все) не могут разрешить домен, dig показывает SERVFAIL, в браузере — «не удалось найти адрес DNS». В dig +trace цепочка упирается в делегирование и дальше не может получить IP NS.

2) Glue есть, но IP устарел

Симптом: домен «то работает, то нет», потому что один из NS доступен по старому IP, другой — по новому, либо разные резолверы кешируют разные состояния. Часто проявляется после миграции или переезда NS на другой сервер.

3) Несогласованные NS: parent и child зоны не совпадают

Симптом: валидаторы ругаются на рассинхрон NS. Технически домен может «как-то работать», но устойчивость ниже: резолверы выбирают разные NS и получают разные ответы или таймауты.

4) Lame delegation

lame delegation — это ситуация, когда в parent зоне NS объявлен авторитетным для child зоны, но по факту сервер ведёт себя некорректно.

Чаще всего это выглядит так:

• сервер не является авторитетным (нет корректного SOA/NS для зоны);
• сервер отвечает REFUSED;
• сервер возвращает данные другой зоны (ошибка конфигурации).

Симптом: резолверы тратят время на «пустые» обращения, ловят таймауты, а домен держится «на честном слове» из-за второго живого NS.

dig +trace: что делает и как читать вывод

dig +trace выполняет итеративное разрешение: сначала спрашивает корневые серверы, затем NS зоны TLD, затем авторитетные NS домена. В отличие от рекурсивного резолвера — без кеша и «автовыбора» от провайдера.

Базовая команда:

dig +trace example.com

Полезные варианты:

dig +trace www.example.com A

dig +trace example.com NS

dig +trace example.com SOA

dig +trace example.com AAAA

Как читать результат по шагам:

1. В начале будет корневая зона: вы увидите подсказку (делегирование) к NS зоны TLD.
2. Далее ответ от TLD (например, com): там находится делегирование для example.com и, при необходимости, glue A/AAAA для NS.
3. После этого dig идёт на один из NS домена и получает финальные записи (A/AAAA/CNAME) или SOA/NS.

Как увидеть glue и проверить, что он корректный

Glue появляется в секции ADDITIONAL ответа от parent зоны. В dig +trace это будет видно на шаге TLD.

Если хотите проверить делегирование и glue без полного trace, запросите NS у авторитетного сервера TLD (его имя можно взять из вывода trace):

dig @a.gtld-servers.net example.com NS

Как интерпретировать ответ:

• в секции AUTHORITY будут NS — это делегирование;
• в секции ADDITIONAL могут быть A/AAAA для этих NS — это glue.

Быстрая проверка:

• Если NS — ns1.example.com, но в additional нет A/AAAA для него, для in-bailiwick это почти наверняка проблема.
• Если A/AAAA есть — сравните IP с тем, что должно быть на NS сейчас (и по IPv4, и по IPv6).

Проверка согласованности NS между parent и child

Здоровая картина: набор NS в parent и в child совпадает. При миграциях часто забывают обновить одну из сторон, и домен начинает «плавать».

Проверяем parent (делегирование):

dig @a.gtld-servers.net example.com NS

Проверяем child (что сами авторитетные серверы объявляют внутри зоны). Спросим один NS напрямую:

dig @ns1.example.com example.com NS

Если в parent указаны ns1/ns2, а внутри child остались старые ns3/ns4 — часть резолверов будет получать разные цепочки, а валидаторы — ругаться на рассинхрон.

Как диагностировать lame delegation

Цель — проверить каждый NS из делегирования: отвечает ли он авторитетно именно за нужную зону.

Шаг 1: берём список NS из parent:

dig @a.gtld-servers.net example.com NS +noall +answer

Шаг 2: для каждого NS проверяем SOA. Нас интересуют доступность, статус и то, что SOA относится к example.com:

dig @ns1.example.com example.com SOA

dig @ns2.example.com example.com SOA

Что должно быть в порядке:

• сервер отвечает без таймаута;
• возвращается SOA для example.com;
• ответ авторитетный (обычно в заголовке есть флаг aa).

Признаки lame:

• status: REFUSED или регулярные таймауты на запросы SOA/NS;
• нет авторитетного ответа для зоны (нет ожидаемой authority-логики);
• возвращается SOA другой зоны (перепутан zonefile, view, ACL или сервер вообще «не про вас»).

Частые сценарии и как чинить

Сценарий A: подняли свои NS в домене и забыли про glue

Как выглядит: в зоне example.com есть A/AAAA для ns1/ns2, делегирование в реестре указывает на ns1.example.com, но glue отсутствует.

Что делать: у регистратора создайте host records (часто «дочерние серверы / child nameservers») и укажите IP для ns1.example.com/ns2.example.com. Затем проверьте, что делегирование указывает на эти NS, и подождите обновления и кеша.

Сценарий B: поменяли IP NS, но glue остался старый

Как выглядит: внутри зоны A/AAAA для ns1 уже новые, но на шаге TLD в dig +trace в additional виден старый IP.

Что делать: обновите IP host records у регистратора (это именно glue). На время, равное TTL и переходному периоду, имеет смысл держать старый IP доступным, если вы не уверены, что все резолверы быстро обновятся.

Сценарий C: делегирование указывает на старого DNS-провайдера (или лишние NS)

Как выглядит: в parent указаны ns.old.net и ns.new.net, но ns.old.net уже не обслуживает вашу child зону. В результате — периодические таймауты и жалобы на нестабильность.

Что делать: приведите список NS в делегировании к актуальному набору и убедитесь, что внутри child зоны опубликован тот же список NS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Мини-чеклист перед переключением NS у регистратора

Если планируете менять DNS-провайдера или переносить зону на свои серверы, этот порядок экономит часы:

• Сначала подготовьте child зону на новых NS: SOA, NS, все нужные записи.
• Проверьте ответы новых NS напрямую: dig @new-ns example.com SOA, dig @new-ns www.example.com A.
• Если NS внутри домена — заранее заведите или обновите glue (host records) у регистратора.
• Убедитесь, что набор NS в parent и child согласован.
• После переключения выполните dig +trace и отдельно проверьте каждый NS на SOA.

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

Почему dig +trace иногда «пугает» и как не ошибиться

1) Несколько NS и «случайный» выбор. На каждом шаге серверов много, и dig выбирает один из доступных. Если один NS «кривой», trace может «случайно» пройти по живому. Поэтому при подозрении на проблему тестируйте каждый NS отдельно (SOA/NS запросами напрямую).

2) IPv6 vs IPv4. Если у NS есть AAAA (в зоне или в glue), часть резолверов пойдёт по IPv6. При асимметрии (IPv6 не работает, IPv4 работает) будут «плавающие» жалобы. Проверяйте отдельно A и AAAA и реальную связность до адресов.

Итоги

Glue records — это не «ещё одна A-запись», а часть делегирования в parent зоне, которой управляет реестр через интерфейс регистратора. Ошибки в glue и NS дают самые неприятные симптомы: нестабильность, случайные SERVFAIL, долгие таймауты, а иногда и полную недоступность домена.

dig +trace — быстрый способ увидеть цепочку DNS delegation, понять, где возникает разрыв, и отличить проблему зоны (child) от проблемы делегирования (parent). Если trace показывает корректные NS и корректный glue на шаге TLD, а каждый NS отдаёт авторитетный SOA для домена — класс проблем «делегирование сломано» обычно закрыт.