Последовательность изменения NS сервера для Домена. (для linux администраторов)

Правильно переписываем NS запись для Домена.

Данная статья предназначена для профессионалов.

Если данная статья вам сложна, существует более простая версия данной статьи.

Для начала разберемся, что мы имеем. Для этого воспользуемся замечательной утилитой host c дополнительным клюем -a (все) , получим информацию о текущих настройках SOA окружения.

host -a klondike-studio.ru 
изменения NS сервера для домена

Как мы видим из рисунка сервер 188.138.84.137 держит наш сайт,

Ns сервера выглядят очень странно да и еще 4 уровня. Что косвенно указывает на собственный ДНС сервер и скорее всего именно на данном же сервере что и сам сайт, это легко проверить.

изменения NS сервера для домена

Собственно, как я и предположил ДНС сервер расположен там же где и сайт, а следовательно, сразу предполагаем что и админка у них общая, хотя тут уже как повезет.

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

А следовательно, при переносе нужно учесть и этот факт, так что заходим в админку, в моем случае, у меня есть доступ до root ssh и мне быстрей глянуть в самом bind сервере.

vim /etc/bind/pri.klondike-studio.ru 
изменения NS сервера для домена

Отлично, теперь мы видим и остальные записи, PTR в принципе можно и пропустить.

Соответственно на новом ДНС сервере нам нужно будет добавить субдомены: crm dev m mail

Данное доменное имя более не будет выступать в роли днс сервера, а следовательно ns1 ns2 нам более не нужны.

Редактируем зону на новом сервере, как правило существуют уже стандартные шаблоны. Нам нужно всего лишь добавить субдомены spf и так далее.

Поскольку почту, мы уносим на яндекс Почта для домена нам нужно будет скорректировать и MX запись.

И к существующее spf добавить

include:_spf.yandex.ru

Но не как рекомендует яндекс.

v=spf1 redirect=_spf.yandex.ru

PTR я на всякий все же добавлю, как говориться лучше «перебдеть». Хоть сотрудники Яндекс и уверили, что проблем не будет, однако две строчки добавить не так сложно, чтобы потом думать как и что мы пропустили.

Как формируются PTR записи можно найти в интернете, поскольку данный сервер делал я, то wizard уже создал и ее и SPF уже скорректированными.

Результате получаем вот это:

изменения NS сервера для домена

После применяем и ждем изменении, проверить примерились ли они достаточно легко, для этого можно использовать как и nsloocup так и тот же host только c принудительным указанием ns сервера ответчика. В моем случае я могу скинуть кеш самостоятельно, поскольку имею полный доступ до сервера, и применение приходит за несколько секунд. Теперь проверяем:

host -a klondike-studio.ru ns1.klondike-s.ru 
изменения NS сервера для домена

Видим что ns сервер ns1.klondike-s.ru уже знает о данном домене и следовательно нам остается только переписать ns сервера. Как только они перепишутся на новые, существующий сайт сразу начнет работу уже с нового сервера поскольку все записи на нем уже корректны.

Отдельно стоит обратить внимание на следующий факт:

В конце стоит точка, и это не опечатка, а очень важный факт. Поскольку многие админки хостеров сами доставляют точку к имени ns сервера то нужно учитывать и этот факт. Если уже созданные записи NS не содержат точку на конце то следует ее и не ставить в противном случае скрипт создаст вам запись типа «klondike-s.ru.» изменения NS сервера для домена

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

В принципе все сделано осталось убедиться что все корректно работает.

Для начала мы убедились что новый ДНС сервер уже отдает саму запись, соответственно жде когда перепишутся НС не забываем что кеш у доменных имен всегда очень внушительный и кеширует его все кому не лень. От вашей ос (в ubuntu так и не нашел как его корректно сбросить не устанавливая полноценного днс кеш) в windows.

ipconfig /flushdns

Для корректно же работы в linux мы можем сделать следующее.

Принудительно указать принудительно днс сервер в настройках сети нужный нам ns1.klondiek-s.ru сервер.

Так же можно указывать его для разработчиков на новом сервере, если сайт все еще работает на старом, фактически разработчик разрабатывает на новой площадке, когда клиент все еще пользуется старой.

Указать, любезно предоставленные google, днс сервера.

Их кеш скидывается куда быстрей чем у нашего провайдера я вообще предпочитаю через них работать. «8.8.8.8» (ребята не экономят на хороших IP адресах на самом деле там их куча 4.4.4.4 5.5.5.5 6.6.6.6 и т. д.

Самый легкий способ, поскольку у меня большое количество ssh доступов до серверов по всему миру можно воспользоваться утилитой linkx или w3m.

изменения NS сервера для домена

Однако стоит помнить если вы зайдете на новый сервер и зайдете с консольного браузера то локальная ДНС запись перебьет внешнюю и вы попадете на сайт уже на данном сервере. Что тоже полезно когда вы подключаете базу данных и вам нужно проконтролировать корректно ли она подключилась. Однако не подходит для тестирования актуальности ДНС. А вот другие сервера для этого отлично подходят.

Консоль в помощь.

dig NS klondike-studio.ru
nslookup klondikestudio.ru

У последнего через пробелы можно указать еще и днс сервер ответчика.

Ну и напоследок, после полного переписывания, проходим по всем доменам указанных в, А записях, проходим по всем почтам, отправляем почту на разные ящики: яндекс, маил и корпоративную почту. Особенное внимание майлу — если у вас некорректно указан spf, почта может не дойти.

В моем случае, после проверки пришлось внести корректировку, поскольку домен 3 уровня crm ссылался на локальную машину, в свою очередь на ней, в виртуалхосте был прописан редирект типа R, уходящий на дугой адрес. Собственно, пришлось создать данный вид редиректа и на новом сервере. Большинство программистов предпочитают сделать это средством .htacces s, но для этого на сервере нужно создавать отдельную учетку под пользователя, и вообще заводить место под сайт и т. д. Мне проще сделать все нормальным способом прямо в virtualhost или CHNAME, в моем случае еще и портфорвардинг мне проще было сделать именно так.

Оставить комментарий