Vários provedores de DNS replicados com o Route 53

2

Eu gerencio alguns domínios que são bastante simples, com apenas registros A, CNAMES e alguns outros tipos de registro comuns. Uma coisa que eu ouço constantemente são as grandes interrupções de vários provedores de DNS profissionais, por exemplo. DynDNS, DNSimple, bem como provedores mais básicos, como GoDaddy e afins.

Embora o AWS Route 53 nunca tenha diminuído e tenha uma enorme replicação do lado deles e eles tenham um SLA de 100% de tempo de atividade, estou imaginando se colocar todos os nossos ovos em uma só cesta está apenas causando problemas.

Alguém sabe de uma boa maneira de fazer com que o Route 53 seja o provedor de DNS primário ou secundário (mesmo que não exista primário / secundário no DNS) e tenha um provedor alternativo que possa detectar e enviar automaticamente? puxar alterações de / para o Route 53?

Alguém pode listar algumas técnicas sendo usadas para evitar um único ponto de falha não no hardware, mas com um único provedor em geral.

    
por Jonathan Oliver 15.05.2016 / 04:26

1 resposta

6

O Route 53 não suporta transferências de zona.

DNS Zone Transfers (AXFR/IXFR) support for Route53 is a hotly asked for feature, and is one that we will consider adding in the future.

https://forums.aws.amazon.com/click.jspa?searchID=6666267&messageID=326081

Você poderia, obviamente, gerenciar seus registros DNS em um sistema interno e empurrar programaticamente as configurações para o Route 53 via API, bem como para outro provedor usando a interface do outro provedor, mas isso não é exatamente "automático".

Uma falha no Route 53 é sempre possível, mas parece muito improvável. Parece ter sido projetado de forma a permitir que várias falhas catastróficas se desenvolvam sem afetar a disponibilidade.

O serviço é gerenciado centralmente, mas distribuído globalmente, e os 4 servidores de nome atribuídos a cada uma de suas zonas hospedadas não são 4 servidores reais, cada um em um local específico, mas na verdade 4 endereços IP anycast que correspondem a mais de 4 reais servidores em todo o mundo.

Embora os detalhes da arquitetura não sejam públicos, as observações sugerem que, quando você atualiza seus registros DNS, eles são enviados para todos os servidores individuais quase imediatamente, portanto, não há confiança em um banco de dados central quando o nome individual servidores precisam procurar dados. Eles replicaram cópias. Depois que os dados são propagados globalmente, eles ficam disponíveis nos pontos de presença para consultas, e a infraestrutura de gerenciamento centralizado pode ser completamente desativada sem afetar a capacidade de atender a consultas.

Observe também que cada uma de suas zonas hospedadas nunca terá mais do que quaisquer 2 servidores de nomes atribuídos a qualquer uma das outras zonas hospedadas, portanto, mesmo uma interrupção que coincidentemente impactou todos os servidores de uma das suas zonas não deve impactar mais de uma das suas zonas.

O fato de anycast ser usado também deve implicar que, se uma interrupção grave levar um local na rede de borda completamente off-line, os anúncios de rota da borda desapareceriam, fazendo com que o tráfego fosse roteado automaticamente para uma borda diferente, onde os mesmos endereços IP estão sendo anunciados.

Você notará que seus 4 nomes de servidores de nomes são distribuídos entre 4 domínios de primeiro nível (.com, .net, .org, .co.uk), o que atenua ainda mais os problemas globais de DNS que também poderiam quebrar as coisas. O Route 53 parece ter sido projetado para acomodar até mesmo problemas em potencial que nem sequer estariam sob o controle do Route 53, caso ocorressem.

As interrupções nunca são verdadeiramente impossíveis, mas minha avaliação do design do Route 53 (com base no que posso observar externamente) sugere que interrupções de serviço no Route 53 são tão improváveis que tornam os serviços de failover desnecessários e, possivelmente, adicionando um serviço alternativo poderia reduzir a confiabilidade, se o serviço alternativo não fosse tão resiliente quanto o Route 53 parece ser.

A categoria Route 53 do Blog da AWS Architecture fornece algumas informações interessantes sobre a resiliência projetada para o Route 53.

    
por 15.05.2016 / 15:29