POC DNS Anycast TCP

Introdução

Na palestra do meu amigo Elizandro Pacheco, que ocorreu na 12ª Semana de Infraestrutura da Internet no Brasil em 25 de outubro de 2022, foi questionado por um participante se em um ambiente onde tivéssemos 2 servidores de DNS Recursivo Anycast sendo consultados e respondendo queries de forma balanceada, poderia ocorrer uma quebra nas consultas de DNS (53/TCP), já que imaginamos que um cliente no estabelecimento de uma sessão TCP (Three-way Handshake), poderia ocorrer de um pacote SYN ir para o servidor de DNS Recursivo A, retornando um SYN+ACK como resposta para o cliente e este acabar enviando o ACK para o servidor de DNS Recursivo B, o que quebraria a conexão forçando uma retransmissão. O mesmo resultado também poderia ocorrer após a sessão TCP estabelecida. Esse comportamento seria esperado porque no ambiente Anycast as consultas de DNS são para o mesmo IP sendo utilizado por mais de um servidor.

Vamos nos atentar ao seguinte: consultas de DNS usando o protocolo TCP são percebidas em transferências de zonas entre o DNS Autoritativo Primário e o DNS Autoritativo Secundário e consultas cuja resposta tenha um tamanho grande, maior que 512 bytes mas que isso nem sempre é uma regra, por exemplo, consultas envolvendo DNSSEC possuem respostas maiores que 512 bytes e são realizadas em UDP. Com isso podemos dizer que consultas recursivas de DNS usando o protocolo TCP são ínfimas e não tenho relatos de problemas de acesso com esse cenário. Vamos observar a tela abaixo:

Reparem no monitoramento acima que no item 2 temos no horário de pico 16948 qps (queries per second) sendo que consultas TCP apenas 116 qps.

Diagrama do LAB para o nosso PoC (Proof of Concept)

Além das informações já passadas resolvi montar um LAB em um ambiente real, para vermos o comportamento das consultas quando temos esse cenário com 2 servidores DNS Recursivos Anycast servindo uma rede de clientes. Primeiro vou apresentar o diagrama abaixo para que possamos visualizar os testes que serão feitos. Esses servidores DNS Recursivos Anycast foram montados utilizando esse artigo.

Os IPs no diagrama são fictícios apenas para entendermos o seguinte: Nos servidores de DNS A e B que escutam nos IPs 10.10.10.10 e 10.10.9.9 anunciados via OSPF pelo FRR, terei um programa tcpdump escutando requisições de DNS 53/TCP vindas do IP 198.18.1.10. Na Máquina de Consulta 198.18.1.10 forçarei consultas de DNS utilizando apenas o protocolo TCP e observaremos o comportamento em cada servidor. Fiz diversas consultas e sempre obtive o mesmo comportamento registrado nos testes. Abaixo estou colocando apenas o suficiente para concluirmos nosso PoC:

1ª leva de consultas

Essa abaixo é a tela da Máquina de Consulta, de onde fiz duas consultas pesquisando o domínio debian.org via TCP com o programa dig:

No momento das duas consultas acima, coletei os seguintes dados no servidor DNS Recursivo A conforme abaixo:

Agora repare que no servidor DNS Recursivo B abaixo; não chegou qualquer requisição para as duas consultas que fizemos acima:

2ª leva de consultas

Agora, conforme abaixo, enviei mais duas consultas de DNS para o endereço www.terra.com.br e debian.org novamente.

Dessa vez no servidor de DNS Recursivo A não chegou qualquer requisição como podemos verificar abaixo:

Contudo as requisições foram para o servidor DNS Recursivo B conforme abaixo:

Conclusão

Pelo que pude constatar não houve em nenhuma tentativa, de várias que fiz, alguma situação onde visualizei uma consulta chegando simultaneamente em ambos os servidores de DNS, o que ao meu ver não quebrou a conexão TCP. Juntando esses testes com o que comentei no início do artigo com os dados coletados do monitoramento de queries, tenho por mim que não existe problema de quebra de TCP na arquitetura Anycast, pelo menos utilizando o FRRouting fazendo os anúncios via OSPF. Não vi algo que impactasse de alguma maneira os acessos dos clientes.

Essa documentação foi útil? Compartilhe, divulgue e ajude outras pessoas. Meus contatos podem ser vistos aqui.