Перенос многих сайтов на новый сервер - как самый быстрый способ обновить их записи DNS?

Требуемый термин - CNAME , и ответ на ваш вопрос - да и нет.

Во-первых, вот пример того, как CNAME работает в зоне файл.

example.se  IN SOA  ns1.example.se. hostmaster.example.se. (
            [....]
            )

server1    A       10.1.2.3
www        CNAME   server1

Теперь вам просто нужно обновить запись server1 , чтобы переместить оба server1 и www на новый IP-адрес.

CNAME этого не делает. не обязательно указывать на адрес в том же домене; это также может выглядеть так:

example.se  IN SOA  ns1.example.se. hostmaster.example.se. (
            [....]
            )

www         CNAME   server1.example.org.

Теперь, когда вы обновляете запись A для server1 в зоне example.org , запись для www.example.se будет следовать без какой-либо дополнительной настройки.

Плохая часть, с вашей точки зрения, заключается в том, что это не работает для записи вершины, то есть для «голого» домена. Другими словами, вы можете превратить www.example.com в CNAME, но вы не можете сделать это с example.com . Это связано с тем, что при использовании записи CNAME у вас не может быть никаких дополнительных записей для этой записи - это означает, что у вас не может быть записей почтового сервера или записей сервера имен ... а это означает, что домен перестанет работать.

Лучшим практическим решением является использование какого-либо программного обеспечения для управления конфигурацией, такого как puppet, chef или ansible, для создания файлов зоны из шаблона. Если по какой-то причине это невозможно для вас, я бы использовал сценарий для замены IP-адресов во всех файлах.

Вы также захотите уменьшить значение TTL для домена своевременно до миграции. (И не забудьте обновить серийный номер файла зоны - у меня есть, и это очень неловко ...)

Во-первых, ответ зависит от того, как реализован ваш DNS. Вы используете самостоятельный хостинг, например, привязку, несвязку или другие DNS-серверы? Используют ли ваши DNS-серверы текстовые файлы для настройки, используют ли они графический интерфейс (например, серверы Windows), используют ли они API сценариев (например, PowerShell), или они используют веб-интерфейс (обычно, если вы передали DNS на аутсорсинг). Аутсорсинговый DNS также иногда имеет REST API, который вы можете использовать.

Вы, вероятно, захотите использовать либо скриптовый API для выполнения обновлений, либо отредактировать текстовый файл, поскольку и то, и другое можно легко автоматизировать. Если это текстовый файл, вы можете даже подготовить его заранее и просто скопировать на место при выполнении миграции.

Между прочим, внесение такого типа изменений в ваш масштаб - вот почему многие люди сейчас используют инструменты DevOps, такие как Chef, Ansible, Puppet, Salt, ... Очевидно, что это большие инструменты, требующие планирования, так что это не поможет сразу в этой конкретной потребности, но может облегчить вашу жизнь в долгосрочной перспективе.

Еще несколько важных моментов:

• Проверьте свой TTL. Примерно за день или неделю до миграции измените TTL на самый короткий из возможных. Увеличьте TTL после завершения миграции.

• Не забудьте увеличить серийный номер в записи SOA! API и веб-интерфейсы могут делать это автоматически, а могут и не делать. Если ваш DNS-сервер использует текстовые файлы, вы должны помнить об этом.

• В зависимости от характера сервера, посмотрите, сможете ли вы на некоторое время запустить старый и новый рядом. Если вы можете, возможно, вам не придется выполнять все обновления DNS сразу.

Если я правильно понял, у старого сервера один IP-адрес, а у нового тоже только один.

Итак, что вы могли бы сделать, это настроить новый сервер и дальше он просто направляет весь соответствующий http / https / ftp / любой трафик на старый IP-адрес, а затем обновляет записи DNS, чтобы показать новый IP-адрес.

Если у вас только один IP-адрес, вы можете использовать простой поиск / замену для изменения всех IP-адресов в DNS (не забудьте обновить серийный номер) сразу и дождитесь, пока истечет ваш текущий TTL. Как только TTL истечет, вы можете просто удалить маршруты на новом сервере и изменить другие настройки, чтобы он обслуживал сайты напрямую, а не перенаправлял.

Перед удалением маршрутов веб-сайты должны были быть перемещены в новое место очевидно. Это имеет то преимущество, что вам не нужно полагаться на другие DNS-серверы для своевременного обновления своих записей, вы можете просто «подождать». Чтобы сократить этот период, вы можете уменьшить TTL, но имейте в виду, что некоторые кэши DNS игнорируют настройки TTL, поэтому я больше не полагаюсь на TTL.

Редактировать / дальнейшее объяснение: Чтобы упростить понимание:

Вы также можете просто установить свой новый сервер прямо сейчас, все настроить и переместить все ваши сайты на новый IP-адрес, а ЗАТЕМ направить весь трафик со старого сервера на новый сервер.

Например у вашего старого сервера IP 192.0.2.1 ваш новый сервер имеет IP-адрес 198.51.100.2

. Ваш DNS указывает на 192.0.2.1 для всех сайтов (?), и веб-сервер решает, какой контент обслуживать по имени запрошенного домена, например example.com -> /var/www/sites/example.com и www.example.com -> / var / www / sites /example.com[1156259 visible.

example.com -> 192.0.2.1

example.com -> 192.0.2.1 -> 198.51.100.2

example.com -> 198.51.100.2

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -m state --state NEW -j ACCEPT

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 198.51.100.2:80
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 198.51.100.2:443
iptables -t nat -A POSTROUTING -j MASQUERADE