Я управляю несколькими доменами, которые довольно просты, только с записями A, CNAMES и несколькими другими распространенными типами записей. Я постоянно слышу о серьезных сбоях в работе различных профессиональных поставщиков DNS, например DynDNS, DNSimple, а также более простые провайдеры, такие как GoDaddy и им подобные.
Хотя AWS Route 53 никогда не выходил из строя и имеет массовую репликацию на своей стороне, и у них есть соглашение об уровне обслуживания на 100%, мне интересно, не вызывает ли сложение всех наших яиц в одну корзину просто проблемы.
Кто-нибудь знает, как сделать так, чтобы Route 53 был либо первичным, либо вторичным провайдером DNS (даже если на самом деле нет такой вещи, как первичный / вторичный в области DNS) и иметь альтернативного провайдера, который может автоматически обнаруживать, а затем отправлять изменения в / с шоссе 53?
Может ли кто-нибудь перечислить некоторые методы, используемые для предотвращения единой точки отказа не в оборудовании, а в целом с одним поставщиком.
Маршрут 53 не поддерживает передачи зон.
Поддержка DNS Zone Transfers (AXFR / IXFR) для Route53 является очень востребованной функцией, и мы рассмотрим возможность ее добавления в будущем.
https://forums.aws.amazon.com/click.jspa?searchID=6666267&messageID=326081
Вы, конечно, можете управлять своими записями DNS во внутренней системе и программно передавать настройки Route 53 через API, а также другому провайдеру с помощью интерфейса другого провайдера, но это не совсем «автоматически».
Сбой на Route 53 всегда возможен, но маловероятен. Похоже, что он был разработан таким образом, чтобы позволить множеству катастрофических отказов развиваться, фактически не влияя на доступность.
Служба управляется централизованно, но распределена по всему миру, и 4 сервера имен, назначенные каждой из ваших размещенных зон, не являются 4 фактическими серверами, каждый в определенном месте, а фактически 4 IP-адресами anycast, которые соответствуют более чем 4 фактическим серверам в глобус.
Хотя детали архитектуры не являются общедоступными, отдельные наблюдения показывают, что когда вы обновляете свои записи DNS, они почти сразу отправляются на все отдельные серверы, поэтому нет необходимости полагаться на центральную базу данных, когда отдельные серверы имен должны искать данные. У них есть копии. Как только данные распространяются по всему миру, они становятся доступными для запросов на периферии, а централизованная инфраструктура управления может быть полностью отключена, не влияя на возможность обслуживания запросов.
Также обратите внимание, что в каждой из ваших размещенных зон никогда не будет более двух назначенных серверов имен, общих с любыми другими вашими размещенными зонами, поэтому даже сбой, который случайно затронул все серверы одной из ваших зон, не должен повлиять более чем на одну. ваших зон.
Дело в том, что Anycast также должно означать, что если серьезный сбой приведет к тому, что какое-либо место в граничной сети полностью отключится, объявления о маршруте на этом граничном сервере исчезнут, в результате чего трафик будет автоматически маршрутизироваться на другой край, где объявляются те же IP-адреса.
Вы заметите, что ваши 4 имени сервера имен распределены между 4 доменами верхнего уровня (.com, .net, .org, .co.uk), что дополнительно снижает глобальные проблемы DNS, которые также могут нарушить работу. Маршрут 53, по-видимому, был спроектирован с учетом даже потенциальных проблем, которые даже не были бы под контролем Route 53, если бы они действительно возникли.
Сбои никогда не бывают по-настоящему невозможными, но моя оценка дизайна Route 53 (основанная на том, что я могу наблюдать извне) предполагает, что сбои в работе Route 53 настолько маловероятны, что сделают отказоустойчивые сервисы ненужными, и, возможно, добавление альтернативного сервиса потенциально может уменьшить надежность, если бы альтернативный сервис не был таким устойчивым, как кажется Route 53.
В Категория Route 53 в блоге об архитектуре AWS дает некоторые интересные сведения об устойчивости, заложенной в Route 53.