У меня есть доменное имя (в настоящее время размещено на dyn.com) с A запись, указывающая на наш производственный IP-адрес.
Мы переходим на Amazon EC2 и используем балансировщик нагрузки с рекомендацией использовать CNAME вместо A запись, поскольку балансировщики нагрузки могут периодически менять IP-адрес.
К сожалению, мне кажется, что я не могу легко осуществить этот переход - мне нужно сначала удалить запись A, а затем добавить CNAME, что потенциально может привести к простою при распространении новой записи.
Есть ли способ сделать это плавно с нулевым (или минимальным) временем простоя?
Там является уловку, которую вы можете использовать здесь. Тем не менее, Уэсли умный чувак, и тебе следует его послушать. Мне не платят за это, но я надеюсь однажды это изменить.
Предполагая, что вы пытаетесь изменить запись с именем www в зоне под названием example.com....
*) в зоне. Зафиксируйте изменение. Протестируйте его, убедитесь, что запись с подстановочными знаками работает должным образом и перекрывает ответы NXDOMAIN.www Запись. Зафиксировать.* запишите, когда вы будете удовлетворены.Поскольку это ваша репутация на кону, вы можете захотеть получить быстрое освежение о том, что Википедия говорит о том, как обрабатываются подстановочные знаки. Удостовериться что вы добавляете подстановочный знак с тем же количеством точек, что и удаляемая запись, поскольку записи с подстановочными знаками не пересекают точку. (известный как метка, если вам нужен правильный термин RFC)
Кроме того, это должно быть само собой разумеющимся, но все эти тесты должны запускаться непосредственно на ваших официальных серверах. (не против резолвера по умолчанию, настроенного для компьютера, с которого вы запускаете тест)
Мы переходим на Amazon EC2 и используем балансировщик нагрузки с рекомендацией использовать CNAME вместо записи A.
Я искренне надеюсь, что вы не используете CNAME для своего верхнего домена. Если ваш DNS-хост уважает себя, это будет запрещено. Если это постыдный и склизкий хозяин, вы сможете, но потеряете частичку своей души (но вы все равно используете EC2, поэтому кажется, что забота о вашей душе уже минимальна).
Вы не можете использовать запись CNAME, чтобы связать вершину зоны с экземпляром Elastic Load Balancing. Правила DNS запрещают создание записи CNAME на вершине зоны (например, example.com). Например, если вам принадлежит доменное имя example.com, вы можете использовать запись CNAME для имени поддомена foo.example.com, но не для вершины зоны example.com.
Двигаемся дальше ...
... поскольку балансировщики нагрузки могут периодически менять IP-адрес.
Нет, балансировщики нагрузки не должны периодически менять IP-адреса. Это их точка зрения. Они остаются неизменными и действуют как уровень абстракции между потребителями и инфраструктурой контента. Если кто-то сказал вам, что IP-адрес балансировщика нагрузки может периодически меняться, попросите его пояснить.
Amazon ELB уже существует, поэтому цель состоит в том, чтобы привязать ваш домен к имени ELB. Теперь я понимаю ситуацию.
К сожалению, мне кажется, что я не могу легко осуществить этот переход - мне нужно сначала удалить запись A, а затем добавить CNAME, что потенциально может привести к простоям при распространении новой записи.
Без некоторых махинаций с многоадресной рассылкой и, возможно, даже небольшого количества дурацкого BGP, сам DNS не предназначен для нулевых изменений времени простоя. Однако вы можете минимизировать вероятность простоя, снизив значения TTL для ваших записей до минимально допустимого времени. Обычно 60 секунд, но если ваш DNS-хост не позволяет ему опуститься до такой отметки, отполируйте вилы, потому что это просто ужасно. В любом случае, уменьшите количество записей до минимально возможного числа, но затем подождите, сколько времени было у предыдущего значения TTL. Если ваше предыдущее значение TTL составляло 3600 секунд, подождите час после того, как вы изменили значение TTL до 60 секунд.
После того, как вы так долго ждали, вы можете изменить свою запись A на CNAME, и у вас будет всего около 60 секунд простоя, примерно.
Я сделал аналогичные переключения, которые включали нулевое время простоя, но синхронизация выполнялась в хранилищах данных, так что в течение непонятного периода переключения любые транзакции, отфильтрованные в старую и новую системы, синхронизировались с бэкэнд-магией. Обычно это требует больше времени и усилий, чем оправдано, если только вы не имеете дело с большим количеством пользователей и денег.
TTL уже составляет 60 секунд, однако SOA NXDOMAIN TTL составляет 1800 секунд.
... что будет проблемой только в том случае, если в вашем домене произойдет что-то, что вернет ответ NXDOMAIN, чего не будет, когда вы измените свою запись с A на CNAME.
поэтому удаление существующей записи A потенциально может привести к отключению до 30 минут (насколько я могу судить)
Нет, потому что вы не удаляете, вы меняете, и любой разумный DNS-хост зафиксировал бы удаление записи A и добавление CNAME одним махом, поэтому вы не будете отвечать NXDOMAIN ни на какие запросы.
Если Dyn делает каждое изменение в вашей зоне атомарным действием, которое индивидуально фиксируется в файле зоны, тогда да, вы потенциально можете возвращать ответы NXDOMAIN. Это ужасно для Дина, но не совсем удивительно.
который я не могу изменить с помощью dyn.com
Мое мнение (которое в сочетании с 5 долларами может принести вам чашку кофе в Starbucks): Dyn - ужасный DNS-хост.