NS-запись (Name Server record)

Автор

Что такое NS-запись?

NS-запись (Name Server record) — это тип DNS-записи, который указывает на авторитативные DNS-серверы, ответственные за хранение и предоставление всех остальных записей (A, MX, CNAME и др.) для конкретной доменной зоны, тем самым делегируя управление зоной этим серверам.

В 2026 году стандартом надёжности является наличие минимум двухNS-записей для каждой зоны (расположенных на разных сетях или в разных дата-центрах), чтобы обеспечить отказоустойчивость; среднее время распространения изменений NS-записей по глобальной DNS-системе составляет от 24 до 48 часов, поэтому для плановых изменений рекомендуется заранее снижать TTL до 300 секунд. Время ответа авторитативных NS-серверов должно быть ниже 150 мс для поддержания общей скорости загрузки сайта (влияет на TTFB).

Как это работает?

При попытке разрешить доменное имя рекурсивный DNS-резолвер обращается к корневым серверам, затем к серверам TLD-зоны (например, .com), которые возвращают список NS-записей для целевого домена. Резолвер выбирает один из этих авторитативных NS-серверов и запрашивает у него конкретную запись (например, A-запись). Полученный ответ кэшируется на всех уровнях согласно TTL, указанному в SOA-записи для всей зоны. Если NS-сервер недоступен, резолвер переходит к следующему серверу из списка, что обеспечивает отказоустойчивость при правильной настройке.

Метрики и стандарты

КоличествоNS-записей — минимум 2 (рекомендация RFC 2182), оптимально 3–4 для баланса между надёжностью и задержкой; более 6 записей могут увеличить время разрешения из-за опроса лишних серверов.
Время ответаNS-сервера — среднее значение ≤ 120 мс (индустриальный ориентир для 2026); если сервер отвечает более 200 мс, это негативно сказывается на общей загрузке страницы.
Распространение изменений — при TTL = 86400 (24 ч) максимальное время обновления NS-записей составляет 48 ч; для критичных миграций рекомендуется устанавливать TTL = 300–600 с за сутки до изменений, чтобы сократить время до 10–20 минут.
ДоступностьNS-серверов — показатель uptime должен быть ≥ 99.99% для каждого сервера, иначе рискует пострадать доступность сайта.

Почему это важно для бизнеса?

Неправильно настроенные или недоступные NS-серверы делают сайт неразрешимым для пользователей — браузер выдаёт ошибку DNS, что полностью прекращает трафик, продажи и доступ к почте. Время распространения изменений NS-записей критично при смене хостинга или DNS-провайдера: если не снизить TTL заранее, бизнес может потерять часть аудитории на несколько дней. Поисковые роботы также не смогут индексировать сайт при сбоях NS, что приводит к падению позиций в выдаче. Миграция домена с сохранением NS-записей, но с изменением IP-адреса через A-запись, выполняется быстрее, чем смена самих NS-серверов, поэтому многие бизнесы используют сторонние DNS-сервисы (Cloudflare, AWS Route 53) для гибкости.

Пример применения

Сценарий: Компания «ТехноЛайн» переносит свой сайт tehnoline.ru с российского хостинга на зарубежный VPS-сервер. Они решают оставить текущих NS-серверов (от регистратора), но изменить A-запись на новый IP. Однако через месяц они переходят на DNS-сервис Cloudflare для ускорения и защиты. Для этого в панели регистратора они заменяют NS-записи с ns1.oldhost.ru и ns2.oldhost.ru на amy.ns.cloudflare.com и bob.ns.cloudflare.com. Так как они за сутки до этого установили TTL для NS-записей на 300 секунд, весь мир узнал об изменении в течение 10 минут, и сайт остался доступен без длительного простоя.

Как это реализуется в WordPress?

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

Настройка: выполняется в панели управления доменом (например, в кабинете регистратора или через API провайдера DNS). Поля: «Имя» (обычно @ или пустое), «Тип» = NS, «Значение» — адрес NS-сервера (например, nsexample.com). Для каждой зоны требуется минимум две записи.
Влияние наWordPress: CMS не затрагивается прямо, но при создании мультисайтов (WordPress Multisite) с поддоменами необходимо убедиться, что NS-записи для этих поддоменов делегированы корректно, либо использовать внешние NS-серверы.
Плагины: плагинов для изменения NS-записей нет, но можно использовать WP Health Check для мониторинга доступности сайта, что косвенно сигнализирует о проблемах с DNS. Для проверки распространения NS-записей полезны внешние сервисы (например, DNS Checker).
Серверный уровень: на веб-сервере (Nginx / LiteSpeed) NS-записи не настраиваются, но если сайт использует внешние API по домену, локальный resolver должен правильно обрабатывать NS-записи — настройка resolver с валидацией DNSSEC может ускорить ответы.
Аналитика иSEO: в Google Search Console можно увидеть проблемы с DNS-доступностью (раздел «Покрытие»), если робот не может разрешить домен; в GA4 падение трафика — индикатор проблем с NS.

Связанные понятия

SOA-запись — определяет начальную авторитетную информацию о зоне (серийный номер, TTL по умолчанию, контакты администратора).
DNS-зона — контейнер для всех записей, управляемый авторитативными NS-серверами.
Рекурсивный резолвер — DNS-сервер (например, 8.8.8.8), который опрашивает NS-серверы для получения ответа клиенту.
CNAME-запись — может использоваться для указания на другой домен, но не может существовать вместе с NS-записью для одного имени.
Glue-запись — специальная A-запись, которая привязывает имя NS-сервера к IP-адресу, чтобы избежать циклической зависимости.
DNSSEC — расширение, подписывающее NS-записи для защиты от подмены (MITM).

Ошибки:

Оставлять только один NS-сервер — при его отказе сайт полностью недоступен; всегда указывайте минимум два.
Менять NS-записи без предварительного снижения TTL — изменения могут распространяться сутки и дольше, что вызывает длительный простой.
Указывать NS-сервер, который не является авторитативным для зоны — это приведёт к ошибкам разрешения; проверяйте через dig или nslookup до внесения.
Игнорирование времени кэширования у промежуточных провайдеров — даже при низком TTL некоторые публичные DNS могут игнорировать TTL и кэшировать дольше, поэтому стоит подождать 48 часов для полного распространения.