Criando um Appliance DNS Recursivo Otimizado para ISPs

Montar e otimizar um servidor DNS recursivo para produção, especialmente para ISPs ou redes corporativas com milhares de dispositivos, exige muito mais do que apenas instalar um pacote e iniciar o serviço. Para garantir o máximo desempenho e resiliência a quedas, é necessário lidar com o tuning de buffers de rede do kernel Linux, balanceamento de cache e partições de memória (slabs), além de monitorar o tráfego em tempo real para identificar anomalias ou consultas maliciosas.

Para automatizar todo esse fluxo de infraestrutura e monitoramento, desenvolvemos o Unbound Sentinel: um Appliance autoinstalável (100% offline via ISO remasterizada baseada no Rocky Linux 9.7 Minimal) que configura um servidor DNS recursivo blindado e otimizado em menos de 5 minutos.

Decisões de Arquitetura e Engenharia de Infraestrutura

1. Instalação 100% Autônoma (Unattended Kickstart)

Para eliminar qualquer necessidade de internet ou interação humana no deploy físico/virtual, a ISO utiliza um arquivo de configuração Kickstart (ks.cfg) integrado ao instalador do Rocky Linux. O particionamento otimizado separa automaticamente as partições /var/log (para evitar travamento do disco por acúmulo de logs de consultas) e / utilizando LVM. Todas as dependências (Node.js v20, Redis, Unbound e os módulos NPM) são empacotadas previamente de forma estática na ISO. A instalação funciona de ponta a ponta sem puxar um único pacote externo da internet.

1. Auto-Tuning Dinâmico de Hardware (Dynamic ISP Tuning)

Um dos maiores erros ao implantar o Unbound é usar arquivos de configuração estáticos. Um servidor com 8GB de RAM configurado com os mesmos limites de um de 64GB vai desperdiçar recursos, enquanto o inverso pode causar gargalos ou estouros de memória. Criamos um script que é executado a cada boot do sistema, calculando e reconfigurando os parâmetros do Unbound e do Kernel com base no hardware físico detectado:

• Buffers UDP do Kernel: O buffer máximo de recepção do Linux (net.core.rmem_max e net.core.rmem_default) é escalado dinamicamente até 16MB para suportar rajadas de pacotes UDP sem perda de pacotes (packet drop) na placa de rede.
• Slabs (Potência de 2): O Unbound usa threads para processamento concorrente. Ajustamos os parâmetros msg-cache-slabs, rrset-cache-slabs, infra-cache-slabs e key-cache-slabs para bater exatamente com a potência de 2 mais próxima do número de núcleos de CPU (nproc), otimizando as travas de leitura e escrita em memória.
• Dimensionamento de Cache: Calculamos dinamicamente os tamanhos de rrset-cache-size e msg-cache-size dedicando até 50% da memória RAM disponível (limitado a 4GB em ambientes de altíssimo tráfego) para manter respostas na memória ultrarrápida.

1. RFC 8767 (Serve-Expired) & Prefetch

Para evitar falhas no DNS recursivo em cenários de ataque DDoS ou indisponibilidade dos servidores root ou autoritativos, ativamos dois mecanismos complementares:

• Prefetch (Pré-busca): Se um domínio quente (muito acessado) é consultado quando seu TTL está prestes a expirar (nos últimos 10%), o Unbound responde ao cliente imediatamente e dispara uma consulta em background para atualizar o cache.
• Serve-Expired (RFC 8767): Caso o Unbound tente atualizar o registro expirado e os servidores autoritativos de destino não respondam, o servidor continua respondendo aos clientes locais com os registros expirados salvos no cache por até 24 horas. Isso garante navegação contínua mesmo em cenários de quebra parcial de trânsito internacional de rede.

Para acelerar a resolução e economizar banda externa, a ISO já vem pré-configurada com a zona raiz local offline. Em vez de consultar os Root Servers (a.root-servers.net, etc.) na internet para saber onde estão os TLDs (como.br ou.com), o Unbound consulta a si mesmo na zona local (127.0.0.1), respondendo ao primeiro nível de hierarquia em 0 milissegundos.

1. Persistência de Cache Quente (Zero-Downtime Reboot)

Quando um servidor DNS recursivo é reiniciado, o cache em memória RAM é limpo. Isso faz com que as consultas após o reinício fiquem lentas (passando de sub-milissegundos para mais de 100ms) até que o cache se aqueça novamente. Criamos um hook no Systemd que roda no shutdown, salvando todo o dump do cache do Unbound para o disco, e o restaura para a RAM instantaneamente.

Conclusão

Com o Unbound Sentinel, podemos otimizar o desempenho e a resiliência do servidor DNS recursivo, garantindo um desempenho consistente e uma navegação contínua mesmo em cenários de quebra parcial de trânsito internacional de rede.