3
DevairFernandes
4 min de leitura ·

Pitch: Criando um Appliance DNS Recursivo Otimizado para ISPs (Rocky Linux + Unbound + Dashboard 3D)

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.

Se você quer o máximo desempenho e resiliência a quedas, precisa lidar com 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, desenvolvi 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.

Neste post, quero compartilhar as principais decisões de engenharia, os tunings de kernel aplicados e as RFCs que tornam este sistema de alta performance.

🏗️ 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.

  • Particionamento otimizado: Separação automática das partições /var/log (para evitar travamento do disco por acúmulo de logs de consultas) e / utilizando LVM.
  • Pre-packaged modules: 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.

2. 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.

3. RFC 8767 (Serve-Expired) & Prefetch

ISPs não podem parar. Se os servidores root ou autoritativos mundiais estiverem sob ataque DDoS ou indisponíveis, o DNS recursivo costuma falhar. Para evitar isso, 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.

4. RFC 7706 (Hyperlocal)

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.

5. 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 durante o startup do sistema.

📊 O Dashboard de Monitoramento (Three.js 3D + Node.js)

Para gerenciar e monitorar toda essa pilha de forma simples, desenvolvi um painel web acoplado:

  • Processador de Ameaças em Tempo Real (CTI Parser): Um motor assíncrono consome os logs de queries do Unbound filtrando logs de DNSSEC inválidos (Bogus) e ameaças conhecidas em tempo real.
  • Enriquecimento Dinâmico: Integração com base GeoIP MaxMind local (offline) e consultas de risco em motores de reputação (VirusTotal).
  • Globo 3D Cyberpunk: Renderizado no browser usando Three.js, conectando geograficamente através de arcos dinâmicos e coloridos os IPs dos clientes locais aos servidores de destino das ameaças detectadas ao redor do mundo.

🛠️ Como baixar e testar?

O projeto está disponível para download e documentação nos links oficiais:

💬 O que acham dessa abordagem de Tuning?

Gostaria de abrir espaço para discussão técnica aqui no TabNews:

  1. Vocês costumam utilizar o Unbound ou preferem alternativas como Bind9, Knot Resolver ou PowerDNS para redes de alto desempenho?
  2. Quais outros parâmetros do Kernel Linux (sysctl) vocês consideram essenciais para servidores de alta concorrência de rede que eu possa incorporar ao auto-tuning?
Carregando publicação patrocinada...