Construímos um Servidor DNS focado em Provedores (ISPs) e batemos o Unbound em performance. Veja os benchmarks.

Fala, pessoal do TabNews!

Quem trabalha com infraestrutura ou desenvolvimento focado em redes sabe que o DNS é, literalmente, o coração da internet. Se o DNS “engasga”, a percepção do usuário final é de que “a internet está lenta”, não importa se ele tem um link de fibra de 1 Gbit/s.

Para provedores regionais (ISPs), isso é uma dor colossal. Usar DNS público (Google, Cloudflare) joga a latência lá para cima e quebra o roteamento local de CDNs (Google Global Cache, Netflix OCA). A solução padrão do mercado sempre foi hospedar o próprio DNS usando ferramentas open-source consagradas, como o Unbound ou o BIND9.

O problema? Ferramentas genéricas fazem de tudo um pouco, mas não são hiper-otimizadas para o fluxo insano de um provedor que precisa entregar filtragem pesada (RPZ, bloqueio de malware, Anatel) com latência virtualmente zero.

Foi para resolver essa lacuna que desenvolvemos o Sentinel DNS.

Fizemos um benchmark pesado para validar a arquitetura. Queríamos provar que resolver localmente com um motor construído para esse cenário específico faz diferença real.

O Cenário de Teste (Benchmark)

Usamos a ferramenta padrão da indústria de redes, o dnsperf (mantido pela DNS-OARC), para simular tráfego pesado.

• Carga: 500 QPS (Queries Per Second) constantes.
• Duração: 5 rodadas seguidas para testar tanto o Cold Cache (primeiras consultas) quanto o Hot Cache (sistema estabilizado).
• Lista: 50 dos domínios mais populares e pesados da internet.

Colocamos no ringue:

1. Sentinel DNS (rodando local na infraestrutura)
2. Unbound Puro (rodando local, mesma máquina virtual, configuração padrão otimizada)
3. Cloudflare (1.1.1.1) (via internet)
4. Google (8.8.8.8) (via internet)

Os Resultados

Aqui estão os números do nosso laboratório (cenário de cache quente estabilizado):

O que esses dados nos dizem?

1. A morte do DNS Público para ISPs: Note que a latência média da Cloudflare e Google fica na casa dos 30ms. Para um usuário comum, é ok. Para um provedor, isso significa que cada requisição web demora 25 a 30 vezes mais do que se fosse resolvida dentro de casa (1,24ms). É um desperdício de percepção de velocidade.
2. Sentinel vs Unbound: Mesmo ambos rodando localmente (eliminando a latência de rede externa), o Sentinel entregou uma latência média ~3,5x menor que o Unbound.
3. O perigo dos Picos (Latência Máxima): Onde o bicho pega é no pico. Sob carga, o Unbound chegou a travar respostas por 272ms. O Sentinel segurou o pior cenário em 27ms. Esse controle rígido de tail latency é o que impede que o cliente sinta aqueles “soquinhos” ao abrir um site pesado com dezenas de recursos.
4. Consistência: O desvio padrão de 6,4ms do Sentinel prova que a distribuição das respostas é extremamente agrupada. Ele não apenas é rápido, ele é previsivelmente rápido.

Por que a diferença?

Soluções como Pi-hole, AdGuard ou até o Unbound “puro” com RPZ carregado sofrem quando precisam lidar com milhões de regras de bloqueio (exigências de órgãos reguladores, C2, malware) junto com tráfego massivo.

Nós construímos o Sentinel com uma máquina de estado (que chamamos internamente de AnaBlock) focada em injetar listas direto na camada de memória, sem gerar “lockings” obstrutivos na hora da resolução.

O que acham?

Construir infraestrutura core não é fácil, mas os números mostram que otimizar para um nicho específico traz ganhos absurdos.
Se alguém aqui gerencia redes de provedores, data centers ou trabalha com infraestrutura crítica, adoraria ouvir: como vocês estão lidando com a gestão do DNS interno hoje? Vocês sofrem com gargalos de performance quando precisam aplicar filtros de segurança massivos no Unbound/Bind?

Se quiserem ver mais detalhes sobre a arquitetura, eu consolidei os dados técnicos na landing page do projeto: sentineldns.net/comparativo.

Qualquer dúvida sobre a metodologia de teste com o dnsperf (ou sobre a arquitetura do motor), manda aqui nos comentários!