Назад | Перейти на главную страницу

Изменение записей DNS при перемещении сайта

Я создаю новый веб-сайт Magento на экземпляре Amazon ec2, и мне нужно будет указать домен их старого сайта OSCommerce на эластичный IP-адрес нового экземпляра ec2.

Обычно у меня была бы простая задача обновления A запись их домена, но когда я вошел в учетную запись с их регистром, я вижу tэй, у тебя уже установлено 90 записей, в основном CNAME & A записи.

У них нет айтишников, которых можно было бы спрашивать, но я почти на 100% уверен, что мне нужно делать, но, поскольку я обычно работаю с такими вещами, как php, javascript и т. Д., Я просто хочу убедиться, что у меня все правильно.

Чтобы дать вам образец их записей DNS они настроили:

Type    Host                            Data                        TTL      Kind    State    In Synch
A       intweb1.their-domain.com        19?.??.???.OLD              3600     Manual  Active     yes
CNAME   intweb.their-domain.com         intweb1.their-domain.com    3600     Manual  Active     yes
CNAME   www.their-domain.com            intweb1.their-domain.com    3600     Manual  Active     yes
A       fs.their-domain.com             19?.??.???.OLD              3600     Manual  Active     yes
CNAME   fileserver.their-domain.com     fs.their-domain.com         3600     Manual  Active     yes

Я считаю, что мне нужно только УДАЛЯТЬ:

A       intweb1.their-domain.com        19?.??.???.OLD              3600     Manual  Active     yes

И ИЗМЕНИТЬ:

CNAME   www.their-domain.com            intweb1.their-domain.com    3600     Manual  Active     yes

Кому:

A       www.their-domain.com            19?.??.???.NEW              3600     Manual  Active     yes

И ДОБАВИТЬ ДРУГОЙ ЗАПИСЬ:

CNAME   their-domain.com                www.their-domain.com        3600     Manual  Active     yes

Это верно?

Лучшей практикой было бы: Установите достаточно маленький ttl, чтобы, если что-то пойдет не так, вам не нужно было ждать 1 час для отката (ttl - в секундах), поэтому вы избегаете данных, записанных в разных версиях базы данных в зависимости от клиентов в один сайт или другой (если старый сайт позволяет вам это сделать, вы можете принудительно перенаправить его на новый сервер, чтобы этого тоже избежать)

Уменьшите время ttl до желаемого для более приятного изменения
Измените записи A, чтобы отразить правильные IP-адреса серверов.
При необходимости измените CNAME, чтобы отразить правильные имена (при необходимости, в зависимости от ситуации, приведенный вами пример следует изменить, возможно, у вас есть еще несколько)

Если вы не меняете почтовый сервер или поставщика DNS, просто не меняйте MX, SOA или что-либо подобное.

Когда вы увидите, что с разрешением все работает должным образом, увеличьте значение ttl до разумного значения.

имейте в виду, что TTL является наиболее важным здесь, если у вас есть какое-то неприятное решение, в вашем текущем сценарии изменение займет час, чтобы отразить его, поэтому переместите его на небольшое число, приближаясь к дате миграции но до логической суммы (сегодня я столкнулся с миграцией, и я установлю 10 'ttl для наиболее важных вещей, с которыми я могу столкнуться 10' для отката, это зависит от вашего приложения - имейте в виду, что ttl распространяется на другие DNS, которые идут дальше, поэтому вы не можете контролировать разрешение за пределами этого числа-)