Os servidores DNS já usam anycast. A adição de mais IPs aumentará a escalabilidade?

8

RFC 1034 exige que atribuamos pelo menos dois endereços IP para servidores DNS. No entanto, a redundância já pode ser obtida por um único endereço IP se usarmos o endereçamento anycast. O anycast da BGP parece se adaptar a centenas ou mesmo milhares de servidores.

Se sim, por que ainda precisamos de vários endereços IP para servidores DNS? Isso realmente aumenta a redundância (contribui para a disponibilidade) se já tivermos anycast no lugar, ou é apenas um mito?

Quais problemas e erros podemos esperar enfrentar se usarmos apenas um único endereço IP?

Com isso, quero dizer que omitimos totalmente os endereços DNS secundários ou usamos um IP falso (por exemplo, 1.2.3.4 ) para o segundo endereço quando algumas configurações exigem pelo menos dois.

    
por Pacerier 13.05.2014 / 10:27

3 respostas

16

Um único endereço IP anycast não oferece a mesma redundância que dois endereços IP unicast em prefixos IP distintos.

Muitas vezes, o problema mais difícil para a redundância não é quando algo falha completamente, mas quando ele está se comportando mal o suficiente para passar nas verificações de integridade, mas não é realmente funcional.

Eu vi uma configuração de DNS anycast em que um servidor DNS caiu, mas os pacotes ainda seriam roteados para esse servidor DNS. Seja o que for que estivesse cuidando da publicidade, o prefixo poderia simplesmente não estar ciente de que o servidor DNS havia caído.

Torna-se ainda mais complicado se o servidor DNS em questão não for um servidor DNS autoritativo, mas sim um resolvedor recursivo.

Esse resolvedor recursivo precisaria ter o endereço anycast para receber consultas de clientes e endereços unicast para consultar servidores DNS autoritativos. Mas se os endereços de unicast fossem desativados, poderia facilmente parecer saudável o suficiente para continuar sendo consultas roteadas.

O Anycast é uma ótima ferramenta para escalabilidade e redução de latência. Mas, para redundância, não deve ficar sozinho.

Vários pools anycast redundantes são, no entanto, uma boa solução para disponibilidade. Um exemplo bem conhecido é 8.8.8.8 e 8.8.4.4. Ambos são endereços anycast, mas nunca devem ser roteados para o mesmo servidor DNS físico (supondo que o Google fez bem o seu trabalho).

Se você tiver 10 servidores DNS físicos, poderá configurá-los como 2 pools com 5 servidores em cada pool ou 5 pools com 2 em cada pool. Você deseja evitar que um servidor DNS físico esteja em vários pools simultaneamente.

Então, quantos IPs você deve alocar? Você precisa ter IPs que possam ser configurados como anycast independentemente uns dos outros. Isso geralmente significa que você precisará alocar um espaço de endereço inteiro / 24 de IPv4 ou / 48 de espaço de endereço IPv6 para cada pool. Isso pode muito bem limitar o número de pools que você pode ter.

Além disso, se estivermos falando de servidores autoritativos, a resposta do DNS com todos os seus registros NS e cola A e AAAA deve caber em um único pacote de 512 bytes. Para os servidores raiz, isso funcionou para 13 endereços. Mas isso não inclui cola e IPv6, então o número que você alcançaria seria menor.

Cada pool deve ser o mais geograficamente distribuído possível. Se você tiver 5 servidores na Europa e 5 na América do Norte e 2 IPs de anycast, você não criará uma piscina abrangendo cada continente. Você coloca 2 da Europa em uma piscina com 3 da América do Norte, e os outros 5 na outra piscina.

Se você tiver mais de dois pools anycast, poderá permitir que um servidor físico fique temporariamente em mais de um pool. Mas você nunca deve permitir que um servidor físico esteja em todos os pools ao mesmo tempo.

Combinar anycast e unicast é possível, mas é preciso ter cuidado. Se você tiver IPs para dois pools, eu não combinaria. Mas se você tiver apenas um único IP anycast com o qual trabalhar, pode fazer sentido incluir também IPs unicast. O problema é que incluir IPs unicast não fornecerá a você uma latência e um balanceamento de carga satisfatórios.

Se um servidor físico for disponibilizado tanto por unicast quanto por anycast, você poderá arriscar que os usuários cheguem ao mesmo servidor que o primário e o secundário e perderão acesso se ele ficar inativo. Isso pode ser evitado usando somente endereços unicast de servidores que não estão no pool anycast ou sempre fornecendo aos usuários dois endereços unicast.

Quanto mais endereços unicast você colocar no mix, menos consultas serão enviadas para o endereço anycast e menos benefícios serão obtidos com anycast em termos de latência e escalabilidade.

    
por 13.05.2014 / 11:04
4

A melhor prática é usar pelo menos dois endereços de prefixos diferentes e atribuir a eles um nome em dois TLDs diferentes. Ambos os endereços podem ser anycast se você quiser. Ter apenas um endereço IP fornecerá um único ponto de falha. Se o roteamento para esse endereço não funcionar (erro de configuração, uma instância anycast não está funcionando corretamente, o prefixo sendo seqüestrado etc), todo o seu domínio ficará inacessível.

Todo endereço anycast exigirá pelo menos um prefixo /24 IPv4 ou /48 IPv6 para ser roteado no BGP. Prefixos menores (mais longos) geralmente não serão aceitos na tabela de roteamento global em muitos lugares.

Nunca nunca coloca um endereço IP falso como servidor DNS. Isso causará atrasos graves para os resolvedores.

    
por 13.05.2014 / 12:23
3

O RFC 1034 apenas afirma que você precisa de dois servidores DNS. Este não é um requisito obrigatório, mas uma recomendação, então faça o que você quiser. Independentemente disso, se você quiser HA, seus 2 servidores DNS poderão receber o mesmo IP usando anycast, e a única coisa que seus usuários finais perceberão quando um servidor DNS falhar, é uma falta momentânea de conectividade à medida que a rede reconverge.

Em resumo, sim, usar anycast é suficiente para ser compatível com RFC 1034.

    
por 13.05.2014 / 10:49