NS-серверы и делегирование домена: как сменить DNS без ошибки

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

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

Авторитетный сервер хранит ответ для своей зоны

DNS использует разные виды серверов. Рекурсивный резолвер получает запрос от устройства пользователя, проходит по иерархии и кеширует найденное. Авторитетный сервер публикует записи зоны, за которую отвечает.

NS означает name server. Запись NS называет авторитетный сервер для домена или его части. Когда резолвер ищет www.example.com, родительская зона сообщает, какие серверы обслуживают example.com. Затем резолвер запрашивает у одного из них A, AAAA, CNAME или другую нужную запись.

Обычно DNS-провайдер выдаёт не один, а несколько NS, например два или четыре имени в разных инфраструктурных узлах. Укажите весь набор без самовольной замены. Несколько серверов нужны, чтобы зона оставалась доступной при отказе одного адреса или площадки.

Делегирование передаёт управление нижней частью дерева

Делегирование — запись в родительской зоне о том, кто отвечает за дочернюю зону. Для зарегистрированного example.com родительской является зона .com. Владелец вводит NS в панели регистратора, регистратор передаёт изменение реестру, а реестр публикует его в родительской зоне.

При этом сами записи сайта находятся уже у DNS-провайдера. Получается две связанные стороны:

Где	Что хранится	Кто меняет
родительская зона	NS, делегирующие example.com	реестр по запросу регистратора
зона example.com	A, AAAA, CNAME, MX, TXT и другие записи	владелец у выбранного DNS-провайдера

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

Определите, какие серверы действуют сейчас

Откройте карточку домена у регистратора и найдите раздел «DNS-серверы», «NS» или «Делегирование». Запишите все имена без изменения. Затем откройте панель предполагаемого DNS-провайдера и убедитесь, что там существует зона этого домена.

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

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

Подготовьте новую зону до переключения

Создайте домен у нового DNS-провайдера и перенесите все необходимые записи. Не ограничивайтесь сайтом: MX направляет почту, TXT может подтверждать сервисы и политику отправки, CAA ограничивает центры сертификации, а поддомены могут обслуживать API и панели.

Сравнивайте записи построчно:

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

SOA и верхние NS новой зоны копировать вручную обычно не нужно: их формирует DNS-провайдер. SOA содержит служебные параметры зоны и указание на её основной источник. Остальные записи должны соответствовать рабочей конфигурации.

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

Меняйте NS отдельной операцией

Когда новая зона готова, замените полный набор NS в панели регистратора. Не удаляйте домен и не запускайте трансфер к другому регистратору: для смены DNS-провайдера эти операции не нужны.

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

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

Когда нужны glue-записи

Особый случай возникает, когда NS находится внутри делегируемого домена: например, ns1.example.com должен обслуживать example.com. Чтобы узнать адрес такого сервера, резолверу уже требуется попасть в зону example.com, но путь к ней зависит от того же NS. Это круговая зависимость.

Родительская зона разрывает её с помощью glue — вспомогательной адресной записи для NS. Такие адреса задаются у регистратора в отдельном разделе вроде «дочерние DNS-серверы» или «host objects». Обычная A-запись ns1 внутри редактора зоны не заменяет glue у родителя.

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

Как вернуть прежнее делегирование

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

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

Типы записей подробно разобраны в уроке об A, AAAA и CNAME. Чтобы не потерять административный контроль, заранее защитите аккаунт и контакты владельца. Общая иерархия объяснена в статье об уровнях доменного имени.

Источники

• RFC 1034: Domain Names — Concepts and Facilities
• RFC 1035: Domain Names — Implementation and Specification
• IANA: Root Zone Management