DNS Recursivo Anycast Hyperlocal

Introdução

Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo Thiago Ayub sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em Engenharia de Redes, todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em BGP, OSPF, MPLS, etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:

Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: https://wiki.ispconfig.com.br, nesse momento seta 1, o navegador irá requisitar do DNS Recursivo utilizado pelo usuário, qual o IP responde pelo hostname wiki.ispup.com.br. Isso porque todos os acessos se dão na Internet através do IP Address e não através do hostname. Imaginem se tivéssemos que decorar os IPs de todos os sites e serviços que quiséssemos acessar na Internet? Só que a primeira vez que consultamos um hostname, o DNS Recursivo não tem a resposta de imediato porque ele não é o dono dessa informação. Então ele faz o trabalho de buscar e consultar o DNS Autoritativo, responsável por aquele domínio em questão ispup.com.br e vemos isso na seta 2. O DNS Autoritativo sabe quais são os IPs que respondem pelo hostname wiki.ispup.com.br e devolve a informação para o DNS Recursivo, seta 3. Na sequência, seta 4, o DNS Recursivo devolve para o navegador do usuário, o IP Address do wiki.ispup.com.br e que pode ser mais de um e de famílias diferentes como IPv4 e IPv6. Cabe ao navegador decidir por qual acessar mas normalmente a preferência é sempre por IPv6, se houver conectividade IPv6 entre o usuário e o conteúdo acessado. Por último, seta 5, o navegador faz o acesso ao site wiki.ispup.com.br através do IP Address.

Como que se dá a comunicação entre os DNS(s) Recursivos e Autoritativos? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado BGP (Border Gateway Protocol), todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na Internet conhecidos como AS (Autonomous System), esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o BGP, que serve de caminho para chegarmos nos conteúdos e sem o DNS (Domain Name System) para traduzir o hostname para o IP Address, a Internet não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.

Mas não acaba por aí. O DNS Recursivo tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.

Um erro que destrói a qualidade do nosso serviço[editar | editar código-fonte]

Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o 8.8.8.8, 1.1.1.1 e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do Thiago Ayub no GTER 51/GTS 37 (2022) 8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS: https://www.youtube.com/watch?v=Rsvpu5uF2Io

Objetivo[editar | editar código-fonte]

O objetivo desta documentação não é te ensinar tudo sobre DNS, BGP, OSPF e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o Debian GNU/Linux, por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo Anycast, ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma Rede OSPF implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o ISIS, mas esse documento não irá abordar o ISIS. Também utilizaremos o Hyperlocal como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

Diagrama[editar | editar código-fonte]

Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.

Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem 3 servidores de DNS Recursivo posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos 2 loopbacks com os IPs:

10.10.10.10/32

10.10.9.9/32

Esses IPs serão entregues pelos concentradores PPPoE ou IPoE (BNG) para seus clientes como DNS primário e secundário. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando 192.168.0.0/24. Se entregarmos o DNS sendo 192.168.0.10 e 192.168.0.20 teremos problemas e o cliente ficará sem Internet, porque 192.168.0.10 e 192.168.0.20 fazem parte da rede 192.168.0.0/24.

Agora entregando 10.10.10.10 e 10.10.9.9 não teríamos problemas com a rede 192.168.0.0/24.

Motivos para usarmos IPs privados:

• O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
• Nem mesmo o cliente da sua rede conhece os IPs públicos utilizados para recursividade na Internet.
• Memorizar os IPs 10.10.10.10 e 10.10.9.9 é tão fácil quanto memorizar o 8.8.8.8 e o 1.1.1.1. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.

Cada servidor DNS Recursivo possui um IPv4 público, aqui representado por 198.18.x.x/27 e um IPv6 global representado por um IP dentro do prefixo 2001:db8::/32. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando Anycast, o cliente será sempre atendido pelo DNS Recursivo mais próximo, desde que os pesos no OSPF estejam ajustados corretamente.

Dados do servidor[editar | editar código-fonte]

Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a 50.000 assinantes ou mais. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um Raspberry Pi e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de DNS Recursivo Anycast com HyperLocal. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a menor latência possível e sempre menor que 5ms entre o cliente e o servidor.

CPU	Memória	Disco	Sistema
2.4Ghz 6 cores	16G DDR4	30G	Debian 11 amd64 (Bullseye)

Softwares utilizados[editar | editar código-fonte]

• Debian 11 amd64 (Bullseye) instalação mínima.

• FRRouting.
• Unbound.
• IRQBalance.
• Chrony (NTP/NTS).
• Shell script em bash.

Funcionalidades que teremos[editar | editar código-fonte]

• Sistema em Anycast.
• Hyperlocal.
• Controle de acesso por ACL.
• RPZ (Response Policy Zone).
• Bloqueio de consultas do tipo ANY.
• QNAME minimization habilitado. (habilitado por default no Unbound)
• Recursividade em IPv4 e IPv6.
• DNSSEC habilitado.
• DoH (DNS over HTTPS) habilitado.

Monitoramento[editar | editar código-fonte]

O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:

• Serviço do unbound parou.
• Perda de pacotes.
• Latência alta de pacotes.
• Lentidão na resolução de queries.
• CPU alta.
• Load alto.
• Memória com uso alto.
• Disco com pouco espaço.
• Queda brusca nas queries.
• A recursividade parou de funcionar.
• A recursividade voltou a funcionar.

Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:

Autor: Marcelo Gondim