Я пытаюсь осознать то, что, как мне казалось, я вроде как понял, но явно чего-то не хватает.
В настоящее время мы используем Zerigo в качестве основного DNS с подчиненными DNS, работающими на линоде. Это неплохо работает. Однако недавние DDOS-атаки на zerigo означали, что, хотя DNS-запросы все еще решались, мы не могли вносить какие-либо изменения в DNS. Поскольку мы полагаемся на изменения DNS в нашей собственной инфраструктуре, я хочу как-то это улучшить.
Я бы предпочел не отказываться от zerigo полностью и понять, что эта или подобные проблемы могут возникнуть с ЛЮБЫМ основным провайдером хостинга DNS. Это может быть не DDOS, а ошибка на их сервере или что-то это означает, что мы больше не можем выпускать обновления.
Для этого я хочу иметь запасной вариант: полностью независимый (основной) поставщик DNS (возможно, AWS), который мы будем синхронизировать вручную. Мы переключимся на него, когда возникнет проблема. Это подводит меня к моему вопросу:
Как мне убедиться, что мы можем достаточно быстро сменить этих провайдеров? в частности, у нашего регистратора есть список серверов имен, но нет таких настроек, как TTL и т. д. Как DNS-клиенты узнают, что нужно использовать недавно обновленные записи серверов имен? Это настроено в SOA? Однако сама SOA размещена у поставщика DNS, и мы, возможно, не сможем ее обновить ...
Это не вопрос об одноразовом переезде, который можно спланировать, запланировать и протестировать, а о возможности сделать это, когда что-то наполовину сломано.
Похоже, у вас есть хорошая инфраструктура, где Zerigo выступает в качестве ведущего и размещает ваших собственных ведомых устройств.
Предполагая, что вы используете BIND (и это должно быть верно для другого программного обеспечения DNS), вы можете превратить подчиненную зону в главную. Как мастер, вы можете изменить зону.
На самом деле это всего лишь простое изменение конфигурации, но вот пример автоматизированного процесса: http://www.mikeperry.org/tech_tips/bind_switch_slave_to_master.html
Если бы вы сделали это, как только Зериго вернется, вы могли бы:
Но также обратите внимание, что пока Zerigo столкнулся с DDOS в прошлом году, интерфейс управления был недоступен, но хосты DNS продолжали обслуживать запросы. Поэтому, если вы внесли изменения в зоны, размещенные на своих серверах, Zerigo по-прежнему будет обслуживать неправильные записи, даже если они в основном не работают.
Переключение авторитетных серверов имен для вашей зоны - это не то, что вы хотите делать «в случае чрезвычайной ситуации», так как это изменение требует не менее 48 часов для распространения по Интернету.
Вы не сможете ничего с этим поделать, так как серверы имен tld не находят забавным отвечать на запросы о том, какой сервер имен вы выбираете часто, поэтому они контролируют TTL, и вам придется жить с этим.
Из того, что я узнал, обычный сценарий выглядит так:
Это требует, чтобы вы сами управляли своими DNS-серверами, но полагаясь на службу, вы всегда будете подвержены потенциальным атакам, и если у них недостаточно избыточности, вам все равно не повезло. Если только вы не найдете провайдера, который настраивает подчиненные зоны. Мне не совсем понятно, используете ли вы Zenigo как обычный VPS и запускаете собственный DNS, или у них есть DNS-сервис.
Хотя я не могу не задаться вопросом, чем вы занимаетесь, если вам нужно ежедневно менять DNS-записи? У меня около 50 клиентов с несколькими веб-сайтами, но я все еще меняю DNS только раз в месяц ..?
Да, продолжительность NS-записей (которые указывают, что yourdomain.example размещен на ns1.zerigo.net или my-ec2.amazon.com) определяется значением TTL этих NS-записей. Если ваш хостер не позволяет вам изменить эти TTL, вы поджарены.
Даже если ваш DNS-хостер позволяет вам изменять их, существует также TTL для NS-записей в родительской зоне, и они фиксируются реестром.
Таким образом, переключение с одного DNS-хостера на другой невозможно в реальном времени. Спамеры и другие разработчики ботов делают это (это называется «fast flux»), чтобы избежать обнаружения, но они размещают свой домен, они могут устанавливать TTL по своему желанию. (У них все еще есть предел TTL в реестре.)