RFC 1034exige que atribuamos pelo menos dois endereços IP para servidores DNS. Entretanto, a redundância já pode ser alcançada por um único endereço IP se usarmos o endereçamento 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? Isso realmente aumenta a redundância (contribui para a disponibilidade) se já tivermos anycast instalado ou é apenas um mito?
Que problemas e erros podemos esperar enfrentarse 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.
Responder1
Um único endereço IP anycast não oferece a mesma redundância que dois endereços IP unicast em prefixos IP distintos dariam.
Freqüentemente, o problema mais difícil de redundância não é quando algo falha completamente, mas sim quando está se comportando mal apenas o suficiente para passar nas verificações de integridade, mas não ser 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. O que quer que estivesse cuidando da publicidade do prefixo pode 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 unicast caíssem, poderia facilmente parecer saudável o suficiente para que ainda fossem consultas roteadas.
Anycast é uma ótima ferramenta para escalabilidade e redução de latência. Mas, em termos de redundância, não deve ser independente.
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 (assumindo 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 um do outro. Isso geralmente significa que você precisará alocar um /24 de espaço de endereço IPv4 inteiro 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 do DNS com todos os seus registros NS e a cola A e AAAA deve caber em um único pacote de 512 bytes. Para os servidores raiz isso resultou em 13 endereços. Mas isso não incluía cola e IPv6, então o número que você alcançaria seria menor.
Cada pool deve ser tão distribuído geograficamente quanto possível. Se você tiver 5 servidores na Europa e 5 na América do Norte e 2 IPs anycast, você não criará um pool abrangendo cada continente. Você coloca 2 da Europa em um pool com 3 da América do Norte e os outros 5 no outro pool.
Se você tiver mais de dois pools anycast, poderá permitir que um servidor físico esteja 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 IP anycast para trabalhar, pode fazer sentido incluir também IPs unicast. O problema é que incluir IPs unicast não proporcionará latência e balanceamento de carga tão bons.
Se um servidor físico for disponibilizado tanto por unicast quanto por anycast, você corre o risco de os usuários acessarem o mesmo servidor como primário e secundário e perderem 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 no mix, menos consultas serão enviadas ao endereço anycast e menos benefícios você obterá do anycast em termos de latência e escalabilidade.
Responder2
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 desejar. Ter apenas um endereço IP causará 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 funcionando corretamente, o prefixo sendo sequestrado, etc.), todo o seu domínio se tornará inacessível.
Cada endereço anycast exigirá pelo menos um prefixo /24IPv4 ou /48IPv6 para ser roteável no BGP. Prefixos menores (mais longos) geralmente não serão aceitos na tabela de roteamento global em muitos lugares.
Nuncasemprecoloque um endereço IP falso como um servidor DNS. Isso causará atrasos graves para os resolvedores.
Responder3
O RFC 1034 afirma apenas que você precisa de dois servidores DNS. Este não é um requisito obrigatório, mas uma recomendação, então faça o que quiser. Independentemente disso, se você quiser 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 falhar é uma falta momentânea de conectividade à medida que a rede reconverge.
Então, em resumo, sim, usar anycast é suficiente para ser compatível com RFC 1034.