Se você gerencia a infraestrutura de um provedor de internet (ISP), de uma rede de escritório ou até mesmo o seu próprio homelab, sabe que a resolução de nomes (DNS) é o gargalo mais invisível da navegação. Um DNS lento causa a percepção instantânea de "internet engasgando", mesmo que você tenha 1 Gbps de banda sobrando.

A recomendação padrão da indústria para máxima performance e privacidade local é utilizar o resolvedor recursivo Unbound DNS. No entanto, configurar o Unbound manualmente para aguentar alta concorrência sem perder pacotes UDP, manter a segurança contra malware e lidar com a perda de cache no reboot exige bastante sintonia fina.

Decidi documentar e criar um ecossistema completo para automatizar esse tuning, empacotando tudo em um Appliance autônomo baseado no Rocky Linux 9.7 (apelidado de Sentinel DNS).

Abaixo, detalho os principais desafios técnicos e como resolvemos cada um deles.

1. Otimização do Kernel e Socket Buffers (UDP Tuning)
   O DNS opera prioritariamente sob UDP. Em momentos de pico ou ataques de amplificação, o buffer de entrada padrão do Linux estoura muito rápido, fazendo com que o kernel descarte pacotes.

Para resolver isso, configuramos o kernel para reservar buffers de soquete maiores e expandir a fila de pacotes recebidos (netdev_max_backlog):

/etc/sysctl.d/99-dns-performance.conf

net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.rmem_default = 8388608
net.core.wmem_default = 8388608
net.core.netdev_max_backlog = 10000
No Unbound, o número de threads de processamento e os caches de memória (msg-cache-slabs, rrset-cache-slabs, etc.) precisam ser dimensionados em potências de 2 baseadas nos cores de CPU disponíveis, para evitar locks de thread:

server:
num-threads: 4
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4

# Buffers maiores no nível da aplicação
so-rcvbuf: 8m
so-sndbuf: 8m

2. O Problema do Cache Limpo no Reboot (Persistence Engine)
Como o Unbound é um resolvedor em memória para máxima velocidade, qualquer reinicialização física ou atualização do serviço limpa o cache. Isso faz com que as primeiras consultas após o boot tenham latências gigantescas, pois o servidor precisa buscar tudo novamente nas raízes (Root Servers).

Criamos um script que roda como um gancho (hook) no Systemd antes do desligamento do serviço:

Salvar o cache de DNS ordenadamente antes de parar o Unbound

unbound-control dump_cache > /var/lib/unbound/unbound_cache.dump
E no momento do boot do sistema, restauramos os dados imediatamente para a memória RAM:

Recarregar o cache quente no início do serviço

if [ -s /var/lib/unbound/unbound_cache.dump ]; then
unbound-control load_cache < /var/lib/unbound/unbound_cache.dump
fi
Isso faz com que o servidor volte a responder requisições comuns em 0ms logo no primeiro segundo pós-reboot.

3. Resiliência: Serve-Expired (RFC 8767)
   Se os servidores autoritativos de um domínio caírem (ex: um ataque DDoS em um grande provedor autoritativo), seus usuários perdem o acesso ao site, mesmo que o IP não tenha mudado.

Habilitamos o suporte à RFC 8767 no Unbound. Se o TTL de um registro expirar e os servidores autoritativos de destino não responderem, o Unbound continuará servindo o registro expirado do cache local por até 24 horas, garantindo uptime total na navegação:

server:
serve-expired: yes
serve-expired-ttl: 86400 # 24 horas
prefetch: yes # Atualiza domínios populares antes de expirarem
4. Monitoramento CTI e Geolocalização em Tempo Real (Visual Dashboard)
Para tirar os logs de texto puro do terminal e dar visibilidade às ameaças e desempenho, desenvolvemos um painel com Node.js + Express que consome a telemetria do resolvedor e renderiza gráficos interativos (ApexCharts).

O grande destaque visual é um Globo 3D Holográfico que mostra a geolocalização dos IPs e ASNs de ameaças bloqueadas por feeds de Inteligência de Ameaças Cibernéticas (CTI) que atualizamos dinamicamente no Unbound (via regras local-zone para manter a latência em sub-milissegundos).

💾 Baixando e Testando a ISO
Empacotamos toda essa lógica dentro de um instalador kickstart autônomo baseado no Rocky Linux 9.7. A instalação leva menos de 5 minutos em qualquer VM (Proxmox, VMware, Hyper-V, VirtualBox):

Site Oficial do Projeto: https://dns.sentineldns.uk
Download da ISO: Disponível diretamente no link de downloads do site.
O que vocês têm utilizado hoje na infraestrutura de DNS recursivo de vocês? Costumam usar o Unbound cru, bind9, PowerDNS ou recorrem apenas a resolvers públicos (como Cloudflare/Google)?

Feedbacks e ideias de otimização de rede são extremamente bem-vindos!