Я пытаюсь переместить DNS с GD на route 53, и, похоже, невозможно избежать простоя, даже с идентичными файлами зон в обоих местах. Из моих экспериментов, как только я меняю на «пользовательские» серверы имен в GoDaddy, они перестают отвечать на запросы DNS, и route 53 тоже не отвечает (они ждут подтверждения, что они авторитетны, прежде чем ответить?). Я протестировал с dig, и вот что я увидел. Если вы используете внутренний инструмент тестирования в AWS, то все хорошо, но если вы попробуете использовать dig с @ одного из ваших серверов имен route 53, он не вернет результат.
Я думаю установить низкий ttl для записей сервера имен, но длинный ttl для всего остального. Есть ли у кого-нибудь опыт, если это поможет с проблемой?
Я понимаю, что это будет иметь эффект только в том случае, если конкретный разрешающий сервер имен запросил запись совсем недавно, но на самом деле это кажется лучше, чем низкие значения ttl для всего, из-за которых разрешающий сервер имен с большей вероятностью потребует авторитетный сервер имен в течение окна распространения.
решение1
Убедитесь, что ваши новые серверы имен обслуживают ваши записи перед переключением. Допустимо настраивать DNS на серверах, которые еще не являются авторизованными. Как только вы убедитесь, что они обслуживают правильные данные, добавьте их в список серверов имен в конфигурации домена. Затем вы можете удалить исходные серверы имен.
У вас уже должны быть длинные TTL для всех хостов. Это снизит риск, если возникнут проблемы с изменением сервера имен. Вы можете уменьшить отрицательный TTL для домена, чтобы ошибки поиска не кэшировались в долгосрочной перспективе. Уменьшение TTL для записей NS упростит изменение. Если исходные серверы имен прекратят обслуживать записи до того, как истечет срок действия записей NS, указывающих на них, они могут начать обслуживать отрицательные ответы.
Из моего опыта работы с GD, вы не сможете избежать кажущегося сбоя с их стороны. Наличие короткого TTL для записей NS в конфигурации домена уменьшит влияние.
решение2
Я понимаю, что это будет иметь эффект только в том случае, если конкретный разрешающий сервер имен запросил запись совсем недавно, но на самом деле это кажется лучше, чем низкие значения ttl для всего, из-за которых разрешающий сервер имен с большей вероятностью потребует авторитетный сервер имен в течение окна распространения.
Если DNS-резолвер (DNS-сервер или клиент указанного DNS-сервера) ранее искал ваши DNS-записи, то эти записи будут кэшироваться в соответствии с TTL, действующим на тот момент. Увеличение или уменьшение TTL после факта ничего не даст вам в этом сценарии. Новые TTL будут действовать в течениеновыйпоиски.