DNS-запись типа NS: что это и как она работает

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

Например, для домена второго уровня NS-записи обычно задаются у регистратора. Они передают управление DNS-зоной выбранному набору серверов. Эти серверы уже хранят сведения о сайте, почте и подтверждениях владения доменом. Внутри зоны NS-записи также могут делегировать поддомен на отдельные серверы имен.

Важно различать NS-запись и IP-адрес. NS содержит имя сервера, а не его адрес. Чтобы найти IP самого сервера имен, DNS использует отдельные записи A или AAAA. Такая схема позволяет менять сетевую инфраструктуру без изменения логики делегирования.

Делегирование означает передачу ответственности за часть DNS-пространства определенным авторитетным серверам. Для основного домена делегирование выполняется в зоне родительского домена. Например, сведения о серверах имен домена второго уровня хранятся у реестра соответствующей доменной зоны.

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

При делегировании поддомена в родительской зоне создают NS-записи для имени поддомена. После этого записи внутри делегированной зоны обслуживаются уже назначенными серверами. Такой подход применяют для разделения инфраструктуры, управления разными проектами или передачи части зоны специализированному сервису.

Если сервер имен расположен внутри делегируемого домена, могут понадобиться glue-записи. Это служебные данные с IP-адресом NS-сервера, которые помогают разорвать логическую зависимость при поиске адреса самого сервера имен.

Основная смена NS-серверов обычно выполняется в личном кабинете регистратора домена. Там выбирают стандартные серверы регистратора, серверы хостинга или собственные серверы DNS-провайдера. После сохранения изменений регистратор передает сведения в родительскую зону, и начинается обновление информации в DNS.

Не следует одновременно менять NS у регистратора и редактировать записи в старой DNS-панели, не понимая, какая зона будет авторитетной. После смены делегирования работают записи только на новых авторитетных серверах. До переключения необходимо заранее перенести в новую зону все нужные данные.

Минимальный набор обычно включает записи для сайта, почты и подтверждений сервисов. Это могут быть A или AAAA для веб-сервера, MX для приема почты, TXT для SPF, DKIM или верификации, а также CNAME для отдельных имен. Если часть записей забыть перенести, домен может открываться, но почта или подключенные сервисы перестанут работать.

В панели DNS NS-записи корневого имени зоны иногда отображаются автоматически. Их не всегда нужно редактировать вручную. Важнее проверить, что они совпадают с серверами, указанными в делегировании у регистратора, и что каждый сервер действительно обслуживает одинаковую актуальную версию зоны.

Проверять NS-записи следует с помощью DNS-диагностики в панели провайдера, системных утилит или специализированных проверок. Результат должен показывать те серверы имен, которые были указаны при делегировании. Затем полезно запросить записи A, MX и TXT непосредственно у каждого авторитетного NS-сервера, чтобы убедиться в синхронности зоны.

После изменения серверов имен данные обновляются не мгновенно. Срок зависит от регламента реестра, настроек кэша у резолверов и времени жизни записей. На практике часть пользователей может увидеть новую конфигурацию быстро, а у других старые данные будут сохраняться некоторое время. Поэтому перенос DNS лучше выполнять заранее, не в момент критического запуска.

До смены NS нужно уменьшить TTL важных записей, если это позволяет текущая зона. Небольшое время жизни помогает быстрее обновить данные у кэширующих резолверов. После завершения переноса TTL можно вернуть к обычному значению, чтобы снизить количество DNS-запросов.

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

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

Другая проблема возникает при несовпадении данных на двух NS-серверах. Один сервер может возвращать новый IP, а второй — старый. Ответы для пользователей становятся непредсказуемыми, особенно при кэшировании. Для надежной работы все авторитетные серверы должны содержать одинаковые записи и серийные номера зоны при использовании классической синхронизации.

Нельзя подменять NS-запись записью A или CNAME. A связывает имя с IPv4-адресом, CNAME создает псевдоним, а NS определяет авторитетный сервер имен. У каждой записи своя функция, и неправильный тип не решает задачу делегирования.

Также рискованно удалять старую DNS-зону сразу после смены серверов имен. Пока обновление не завершилось, часть запросов еще может попадать на прежние серверы. Старую конфигурацию разумно сохранять рабочей на переходный период, а после подтверждения стабильной работы отключать.