Смена NS домена: сколько длится и как проверить результат

NS меняют место управления зоной

Смена NS домена — это не правка одной записи. Вы говорите реестру и резолверам: за зону теперь отвечают другие авторитетные серверы. Если новая зона не подготовлена заранее, сайт может открываться, а почта — пропасть; кабинет может работать, а API — нет; основной домен может быть правильным, а help-поддомен — забытым.

Именно поэтому смену NS проверяют как миграцию зоны. Перед переключением старая и новая зоны должны совпадать по критичным записям: A, AAAA, CNAME, MX, TXT, поддомены, служебные подтверждения. Смысл такой операции подробно раскрыт в старой статье про nameservers и момент, когда их действительно нужно менять.

Сколько длится смена NS

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

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

Что сравнить до переключения

Перед сменой NS нужно открыть старую и новую зоны рядом. Проверяются не только сайт и `www`, но и почта, TXT-подтверждения, DKIM, DMARC, API, личный кабинет, help, status, временные стенды и записи для SSL. Если проект использует DNSSEC, отдельно проверяют DS и цепочку доверия, иначе часть валидирующих резолверов может перестать принимать ответы.

Для правки без хаоса полезно заранее выполнить процедуру из статьи про проверку DNS перед изменением: сначала зафиксировать состояние, затем проверить новый ответ, а не наоборот.

Проверка после смены NS

После переключения смотрят:

1. какие NS видны извне;

2. что отвечают новые авторитетные серверы;

3. остались ли публичные резолверы со старой делегацией;

4. совпадают ли веб, почта и поддомены;

5. нет ли ошибок DNSSEC;

6. не появились ли жалобы только из отдельных сетей.

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

Кейс: NS сменили, но почта исчезла

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

Проблему нашли через проверку MX у авторитетного сервера. После восстановления MX, SPF и DKIM почта вернулась, но часть писем за период сбоя уже была потеряна. Вывод: смена NS должна проверяться по списку сервисов, а не по факту открытия главной страницы.

Мини-чек перед сменой NS

новая зона полностью собрана;
MX и TXT перенесены;
поддомены кабинета, API и help проверены;
DNSSEC учтён или временно корректно отключён;
TTL снижен заранее;
старая зона сохраняется до окончания окна;
есть план отката.

Почему старую зону нельзя удалять сразу

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

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

Как проверить переход без ожидания жалоб

До изменения NS можно заранее спросить новую зону напрямую, даже если делегация ещё не переключена. Это позволяет увидеть ошибку до публичного эффекта: отсутствующий MX, старый TXT, неверный CNAME или забытый поддомен. После переключения ту же проверку повторяют уже через публичные резолверы и несколько сетей. Такой подход особенно полезен, когда домен обслуживает не только сайт, но и кабинет, API и почту поддержки. Команда видит не «вроде работает», а конкретное совпадение старого плана и нового ответа.

FAQ о смене NS

Можно ли сменить NS без простоя?

Да, если новая зона заранее повторяет критичные записи, TTL подготовлен, а старая зона не удаляется сразу.

Почему после смены NS часть людей видит старый сайт?

Резолверы могут держать старую делегацию и старые ответы. Это нормальное окно обновления, если новая зона подготовлена правильно.

Нужно ли переносить MX при смене NS?

Да. MX относится к DNS-зоне. Если он останется только в старой зоне, почта может перестать работать.

Что опаснее всего при смене NS?

Переключить делегацию на пустую или неполную зону. Тогда ломается не одна запись, а весь набор сервисов домена.

Источники

---

#DNS#Nameservers#Миграция

К списку статей На главную