Nameserver (NS-сервер) — это сервер, который хранит DNS-записи вашего домена и отвечает интернету на вопросы «по какому IP находится сайт» и «куда доставлять почту». При регистрации домена в реестре фиксируется, какие NS-серверы за него отвечают. Смена NS означает перенос управления DNS от одного провайдера к другому: с этого момента все записи читаются уже с новых серверов. Поэтому это не просто правка одного поля, а процесс, требующий предварительной подготовки.
NS и DNS-записи: в чём разница
Многие путают смену NS со сменой A-записи. A-запись связывает одно имя с одним IP-адресом и находится внутри DNS-зоны. NS же указывает, где находится сама зона. Если вы переключаете NS на нового провайдера, все записи у старого — адрес сайта, почта (MX), TXT-записи вроде SPF и DKIM, поддомены — мгновенно перестают иметь значение. Если на новых серверах этих записей нет, остановятся и сайт, и почта.
Отсюда главное правило: сначала полностью подготовьте зону на новом месте, а потом меняйте NS. Если сделать наоборот, простой может длиться от нескольких часов до нескольких дней.
Шаг 1: зафиксируйте текущие записи
Большинство DNS-серверов не разрешают полный перенос зоны (AXFR), поэтому важные записи нужно проверить вручную. Если в панели старого провайдера можно посмотреть список записей, сохраните его. Дополнительно проверьте основные записи в терминале:
for t in A AAAA MX TXT CAA; do
echo "== $t"; dig +short klinika-misol.uz $t
done
dig +short www.klinika-misol.uz
dig +short mail.klinika-misol.uz
dig +short _dmarc.klinika-misol.uz TXTDKIM-запись хранится под именем селектора (например, default._domainkey или mail._domainkey), точное имя смотрите в настройках почтового сервиса. Не забудьте и о TXT-записях подтверждения для поисковых систем и других сервисов, иначе подтверждение домена, например в Google Search Console, может слететь.
Шаг 2: подготовьте зону на новых серверах
Новый провайдер выдаст два или более адреса NS-серверов, обычно вида ns1.provayder.uz. Добавьте домен в его сервис и внесите все записи, собранные на первом шаге. Если сайт тоже переезжает на новый хостинг, A-запись должна указывать на IP нового сервера; если почта остаётся на месте, MX и связанные с ней записи переносятся без изменений.
Перед сменой NS проверьте работу новой зоны, обратившись к новому серверу напрямую. Это работает, даже пока домен ещё не делегирован на эти серверы:
dig @ns1.provayder.uz klinika-misol.uz SOA +short
dig @ns1.provayder.uz klinika-misol.uz A +short
dig @ns1.provayder.uz klinika-misol.uz MX +shortЕсли ответ пустой или возвращается REFUSED, зона ещё не создана или имя домена указано с ошибкой. В таком случае NS менять нельзя.
Шаг 3: заранее снизьте TTL
TTL определяет, сколько времени запись хранится в кэше резолверов. Если в старой зоне TTL составляет несколько часов или сутки, за день до переезда полезно снизить его примерно до 300 секунд. Это не ускорит обновление самой NS-записи, ведь ею управляет реестр, но поможет пользователям не застревать надолго между старыми и новыми записями в переходный период. После завершения переезда TTL можно вернуть к обычному значению.
Шаг 4: смените NS у регистратора
NS меняются только там, где зарегистрирован домен, — в панели регистратора. Клиенты sayt.uz делают это в личном кабинете в разделе «Домены»: выбирают нужный домен, вписывают новые адреса в поля NS-серверов и сохраняют. Соблюдайте несколько простых правил:
- укажите не менее двух NS-серверов, желательно на разных машинах;
- копируйте адреса, а не набирайте вручную: одна опечатка выводит из строя весь домен;
- не добавляйте точку в конце, пробелы или
http://— нужно только чистое имя хоста; - не смешивайте NS старого и нового провайдера, иначе резолверы будут получать разные ответы случайным образом.
Если NS-серверы находятся внутри самого домена (например, ns1.klinika-misol.uz), у регистратора для них нужно указать и IP-адреса. Такие записи называются glue, и без них резолвер не сможет найти NS-сервер. Если для домена включён DNSSEC, сначала удалите DS-запись в реестре или настройте подписание у нового провайдера, иначе домен перестанет открываться у многих резолверов.
Шаг 5: дождитесь распространения и проверьте
После того как изменение попало в реестр, часть пользователей продолжает обращаться к старым серверам, пока резолверы не удалят старые данные из кэша. Обычно это занимает несколько часов, но у некоторых провайдеров растягивается до суток-двух. Следите за состоянием так:
dig NS klinika-misol.uz +short
dig @8.8.8.8 klinika-misol.uz A +short
dig +trace klinika-misol.uz
whois klinika-misol.uz | grep -i "name server"В Windows та же проверка выполняется через nslookup:
nslookup -type=NS klinika-misol.uz 8.8.8.8
ipconfig /flushdnsОсобенно полезен dig +trace: он показывает путь запроса от корневых серверов шаг за шагом, и вы точно видите, какие NS отдаёт реестр. Если trace показывает новые серверы, а в браузере всё ещё открывается старый сайт, дело просто в кэше компьютера или интернет-провайдера.
Пример: переезд клиники в Самарканде
Частная клиника в Самарканде решила перенести сайт на новый хостинг. В первый раз администратор перенёс только файлы сайта и сразу переключил NS на нового провайдера. На следующий день сайт открылся, но на корпоративную почту клиники перестали приходить письма: в новой зоне не было MX и SPF, а заявки пациентов на приём приходили именно на эту почту. Проблему решили, открыв старую панель и заново внеся записи, но письма за сутки были потеряны.
Для второго домена процесс выполнили в правильном порядке: сначала собрали список записей, внесли их в новую зону и проверили через dig @ns1, за день снизили TTL и только потом сменили NS. На этот раз ни сайт, ни почта не прерывались.
Что не забыть после переезда
Не удаляйте зону у старого провайдера ещё несколько дней после смены NS: резолверы со старыми данными в кэше всё это время обращаются к старым серверам. Если сайт переехал на новый сервер, SSL-сертификат выпускается только после того, как DNS начнёт указывать на новый сервер, поэтому HTTPS проверяйте после завершения распространения. В конце по очереди проверьте отправку и получение почты, поддомены и подтверждения во внешних сервисах. При таком порядке смена NS становится безопасной и почти незаметной операцией.