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

Как передать записи DNS новому провайдеру DNS с минимальным временем простоя или без него

Я хотел бы перенести записи DNS из Network Solutions в DNS Made Easy, в основном для того, чтобы воспользоваться преимуществом «DNS Failover», предоставляемым DNS Made Easy, чтобы автоматически сбой пары ключевых записей A на новые IP-адреса в моем центре обработки данных, где я реплицирую серверы для аварийного восстановления, если DNS Made Easy определяет, что первичный IP-адрес недоступен.

Это руководство полезно, но я не понимаю первый шаг в отношении TTL. Насколько я понимаю, TTL всегда заключался в том, что записи кеша размещаются на определенное время, указанное TTL при запросе записей. Если это понимание верное, как я могу контролировать истечение срока?

Мой план:

  1. Создавать новые файлы зоны на новом провайдере DNS на досуге
  2. Меняю существующие серверы имен в регистраторе на новые DNS-серверы Made Easy ночью, скрещиваю пальцы и жди утра

Что я могу сделать в отношении TTL, чтобы повысить мои шансы на то, чтобы сделать это без проблем?

Мое понимание TTL всегда заключалось в том, что записи кеша размещаются в течение определенного времени, как указано в TTL.

Это правильно. TTL были определены следующим образом из почтенного RFC1034:

TTL - время жизни RR. Это поле представляет собой 32-битное целое число в секундах, которое в основном используется распознавателями, когда они кэшируют записи RR. TTL описывает, как долго RR может храниться в кэше, прежде чем его следует отбросить.

Попутно обратите внимание:

  • это максимальное значение, преобразователи могут очистить свой кеш до достижения значения TTL (по политическим причинам или для освобождения места в кеше)
  • некоторые резолверы будут ограничивать значения TTL до минимума, если исходное значение будет сочтено слишком низким; обычно менее 5 минут вы рискуете, что некоторые решатели не соблюдают его

Обычно рекомендуется изменять любую запись таким образом:

  1. Вы понижаете TTL текущей записи примерно до 5 минут.
  2. Ты ждешь по крайней мере значение предыдущего TTL перед переходом к следующему шагу
  3. Вы меняете запись, сохраняя малую стоимость
  4. Вы проверяете, все в порядке
  5. Затем вы можете вернуть более высокое значение TTL

Для полноты, в зависимости от вашей инфраструктуры NS вам также могут понадобиться:

  • для понижения МИНИМАЛЬНОГО значения SOA, которое на самом деле является «отрицательным TTL»: это актуально только в том случае, если вы добавляете запись, которой раньше не было
  • для уменьшения значения SOA REFRESH, если вы не контролируете вторичные серверы имен, чтобы они быстрее получали новое значение (или отправляли им сообщения NOTIFY и проследили, чтобы он запускал от них запросы AXFR / IXFR вскоре после этого).

Ваш случай немного отличается:

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

Некоторые примеры:

$ for tld in com biz info org guru fr de ; do echo -n $tld ' '; dig @`dig $tld. NS +short|head -1` nic.$tld NS +noall +auth | grep "IN NS" | head -1 | awk '{ print $2}' ; done
com  2d
biz  2h
info  1d
org  1d
guru  1d
fr  2d
de  1d

PS: в случае подписанного доменного имени (DNSSEC) все немного сложнее.