dnsbench: qual DNS é mais rápido na sua conexão, e para qual CDN ele te manda

Também disponível em inglês: dnsbench: which DNS resolver is fastest on your connection, and which CDN it sends you to.

Todo ranking público de DNS responde a mesma pergunta: qual resolver é mais rápido, em média, visto de datacenters espalhados pelo mundo. A minha pergunta é outra: qual é mais rápido no meu link, na minha operadora, agora, e se depois ele me manda para o edge de CDN certo.

Essa segunda parte quase ninguém mede. Um resolver que ganha por 2 ms na consulta e perde 90 ms na escolha do edge perdeu, mesmo liderando a tabela. Por isso escrevi o dnsbench.

O que é

Um binário estático único, sem dependência em tempo de execução, sem telemetria e sem tráfego além da própria medição. Tem CLI e uma TUI em tela cheia (--tui).

É escrito em V, linguagem sobre a qual já falei na introdução ao V e no guia de Bash para V. Os documentos em docs/ foram escritos antes do código e descrevem a ferramenta final. Quando código e documento divergem, o bug é o código.

O que ele mede

São nove probes, escolhidos com --probes: consulta com cache (warm), tcp, cache forçadamente frio (cold), penalidade de edge do CDN (ecs), handshake DoT novo contra conexão reaproveitada (dot-fresh e dot-warm), doh, dnssec (quem valida de verdade) e filter (veredito de bloqueio de anúncios, medido). Os transportes são UDP, TCP, DoT e DoH. DoQ fica para quando o V ganhar QUIC.

Essa é a bateria completa na minha conexão. A coluna EDGE é a penalidade de CDN. Os resolvers locais ficam separados no fim, rotulados como cache e fora da comparação. Nos selos da direita, +DNSSEC e -ads são medidos pelas probes. Os que começam com ~, como ~nolog, são só a declaração do provedor: o dnsbench repete, não verifica.

Usando

dnsbench --tui --probes warm,cold,ecs,dot-warm,dnssec,filter
dnsbench --format json
dnsbench --watch 15m --history ~/.local/share/dnsbench/runs.jsonl --only quad9,cloudflare

TUI do dnsbench no meio de uma medição, com a barra de progresso em 50 de 912 consultas e 6 segundos decorridos. A tabela lista os provedores ainda sem nota, agrupados em "not ranked", com as colunas de latência vazias e apenas os selos declarados, como ~nolog e ~nofilter, preenchidos

A tabela vai se preenchendo durante a execução. s ordena, tab troca a probe por trás das colunas de latência, / busca, enter abre o detalhe de um provedor e e exporta. Com p eu troco o perfil de pesos e a ordem muda sem medir nada de novo, que é o jeito mais honesto de mostrar quanto do resultado é rede e quanto é peso.

Escolhas de projeto

Ele se recusa a rodar com uma interface de túnel ativa, porque mediria o túnel e não o link. Quem vive de VPN, como o WireGuard, vai esbarrar nisso. O --force libera e avisa na saída.
O histórico é em JSONL e nunca mistura redes diferentes. Uma medição na fibra e outra no 4G, na mesma máquina, não viram uma média sem sentido.
A probe cold usa uma zona própria, probe.dnsbench.esli.blog, com anycast e ponto de presença em São Paulo. Se ela ficar inacessível, o dnsbench cai para rótulos aleatórios e marca a execução como não comparável.
O catálogo do DNSCrypt é opcional e verificado com minisign. Nunca é o padrão: a própria lista avisa que algumas entradas censuram ou monetizam consultas. Se o assunto é novo para você, comece pelo guia de DNSCrypt e DNS Stamps e pela configuração do dnscrypt-proxy no Linux.

Ele também não troca o DNS do seu sistema. Mede e reporta, a decisão é sua.

Instalação

Os binários estáticos (amd64 e arm64) estão na página de releases, com SHA256SUMS.

Caso queira ir pelo código-fonte, é preciso V 0.5.2 ou mais novo:

git clone https://github.com/Esl1h/DNSbench && cd DNSbench
make build
make install

A versão atual é a v0.2.1, licença MIT. O guia completo está em docs/USAGE.md e o código em github.com/Esl1h/DNSbench.