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