Os servidores DNS já usam anycast. Adicionar mais IPs aumentará a escalabilidade?

A RFC 1034 exige que designemos pelo menos dois endereços IP para servidores DNS. No entanto, a redundância já pode ser alcançada por um único endereço IP, se usarmos o endereço anycast. O anycast do BGP parece escalar bem em centenas ou até milhares de servidores.

Se sim, por que ainda precisamos de vários endereços IP para servidores DNS? Ele realmente melhora a redundância (contribui para a disponibilidade) se já temos uma transmissão em andamento ou é apenas um mito?

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

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

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

Freqüentemente, o problema mais difícil de redundância não ocorre quando algo falha completamente, mas quando se comporta mal o suficiente para passar nas verificações de integridade, mas na verdade não é 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. O que quer que estivesse cuidando da publicidade, o prefixo simplesmente não sabia, 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 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 unicast diminuíssem, poderia facilmente parecer saudável o suficiente para que ainda fossem consultas roteadas.

Anycast é uma ótima ferramenta para escalabilidade e redução da 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 tenha feito seu trabalho bem).

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 um do outro. 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 autorizados, a resposta DNS com todos os seus registros NS e a cola A e AAAA devem caber em um único pacote de 512 bytes. Para os servidores raiz, isso resultou em 13 endereços. Mas como isso não incluía cola e IPv6, o número que você alcançaria seria menor.

Cada pool deve ser o mais geograficamente distribuído possível. Se você possui 5 servidores na Europa e 5 na América do Norte e 2 IPs anycast, não cria um pool 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 de anycast, poderá deixar um servidor físico temporariamente em mais de um pool. Mas você nunca deve permitir que um servidor físico esteja em todos os pools ao mesmo tempo.

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

Se um servidor físico for disponibilizado pelo unicast e pelo 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 cair. Isso pode ser evitado usando apenas 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 na mistura, menos consultas serão enviadas para o endereço anycast e menos benefício você obterá do anycast em termos de latência e escalabilidade.

A melhor prática é usar pelo menos dois endereços de prefixos diferentes e dar-lhes um nome em dois TLDs diferentes. Ambos os endereços podem ser anycast, se você desejar. 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 do anycast não funcionando corretamente, o prefixo sendo invadido etc.), todo o seu domínio se tornará inacessível.

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

Nunca jamais colocar em um endereço IP falso como um servidor DNS. Causará atrasos graves nos resolvedores.

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

Portanto, em resumo, sim, usando anycast é suficiente para ser compatível com RFC 1034.