Quando pensei em implantar meu primeiro servidor DNS, presumi que seria uma tarefa do tipo configure e esqueça. Mais importante ainda, como eu mesmo faço a hospedagem do DNS, terei controle total desde o primeiro dia. Mas depois de meses com servidores DNS diferentes, percebi que cada pesquisa dependia de um resolvedor de terceiros que não era meu. Foram necessárias várias tentativas e desvios para descobrir o que realmente era a rachadura. Todo o processo me levou a uma toca de coelho mais confusa do que eu esperava.
Continuei trocando de servidor DNS e perdi o verdadeiro problema
Mudar por si só não foi a solução
Configurar meu DNA foi uma montanha-russa. Nos últimos meses, tenho trocado servidores DNS como se fossem roupas. Os mesmos contêineres, os mesmos serviços, mas o DNS continuava mudando e cada mudança parecia justificada na época, até que descobri algo mais nos dias seguintes.
Comecei com o Pi-hole como todo mundo, não como servidor DNS, mas como bloqueador de anúncios. Nos primeiros meses, ele fez exatamente o que eu planejei: bloquear anúncios. Fiquei feliz com isso até que um dia, quando estava examinando os logs, não gostei da forma como os metadados da rede estavam se movendo. Foi então que decidi implementar DNS over-HTTPS (DoH) para um upstream criptografado. Minha primeira escolha óbvia foi o proxy DoH da Cloudflare, mas ele foi descontinuado em novembro de 2025, então redirecionei e hospedei meu próprio DNS sobre HTTPS usando dnscrypt-proxy.
Agora eu tinha dois contêineres mesmo trabalho, então mudei para o AdGuard Home (AGH), que foi consolidado meus dois contêineres configurados em um. Ele tinha uma interface de usuário mais limpa, criptografia upstream nativa e, o mais importante, uma interface única para gerenciar. Eu o implantei substituindo Pi-hole e dnscrypt-proxy e usando Quad9 DoH. Na época, realmente parecia uma atualização e uma melhoria em relação à minha configuração anterior. Então, compartilhei minha experiência escrevendo sobre isso e, surpreendentemente, a seção de comentários estava repleta de sugestões sobre o Technitium.
Decidi experimentar o Technitium e ver por que tanto alarido. Visitei seu site oficial e li sobre isso. A lista de recursos era muito longa, então procurei aquele que precisava e finalmente decidi dar uma olhada. À primeira vista, o painel do Technitium não parecia ser um bloqueador de anúncios com recursos DNS, mas sim um servidor DNS real. Surpreendentemente, ele poderia lidar com a resolução recursiva por si só, o que significava que meu vício em Quad9 DoH poderia finalmente desaparecer. Mas era incrivelmente capaz, cheio de recursos e exigia mais conhecimentos de DNA do que eu gostaria de pensar todos os dias.
Finalmente, abandonei o Technitium e voltei para a configuração original do AGH e Quad9 DoH apenas por uma questão de simplicidade. Mas voltar ao AGH significava mais uma vez depender de um resolvedor de terceiros, que o Technitium resolveu para mim sem que eu pedisse. Isso começou a me incomodar mais do que eu esperava.
Recuperando o que era o Technitium sem o que custou
A resposta não foi um servidor DNS diferente
Eu estava de volta com AGH e Quad9. Funciona bem como pretendido. A AGH continuou a bloquear pedidos indesejados, enquanto cada consulta DNS não armazenada em cache era enviada à Quad9 para resolução. Mas ao mesmo tempo, voltando à minha mente, penso no Technitium; ele resolveu essa dependência sozinho, sem necessidade de configuração adicional. AGH teve que pedir uma resposta a outra pessoa – exatamente o que a Technitium evitou completamente ao resolver as dúvidas em primeiro lugar, independentemente da Quad9, Cloudflare ou Google. Criptografia não era o mesmo que independência.
Queria independência, mas também não queria voltar ao Technitium. Foi quando me deparei com o Unbound. Unbound parecia uma peça que faltava na minha configuração. Era um solucionador de DNA recursivo. Em vez de pedir uma solução, a Quad9 percorreu a hierarquia do DNA. Dos servidores raiz a uma resposta oficial, o Unbound cuidou de tudo. Uma implantação não relacionada significava que eu estaria novamente no início do círculo, com duas instâncias fazendo o mesmo trabalho. Mas mesmo assim decidi seguir em frente com o Unbound, buscando total independência no meu DNA.
Achei que a configuração seria plug-and-play simples, mas passar do DoH upstream do AGH para o Unbound na porta 5335 atingiu um obstáculo. O tráfego do contêiner AGH para o gateway da ponte Docker estava terminando silenciosamente, enquanto o Unbound autônomo estava funcionando bem. Mais tarde, descobri que o tempo limite expirou porque minha configuração do UFW só tinha a porta 53 – nada mais estava passando. Então finalmente consertei adicionando uma regra de firewall de escopo à sub-rede do Docker em vez de “Anywhere”.
Depois que tudo estava configurado e funcionando, o resultado final parecia simples. AGH ainda lidava com bloqueio de anúncios, filtragem, conexões criptografadas do lado do cliente e a mesma interface de usuário simples de sempre. Recursão local não consolidada e processada sob AGH. E o mais importante, todas as missões permaneceram na minha cadeia de solucionadores sem que eu sacrificasse a simplicidade. Mas isso realmente fez diferença?
- SO
-
Windows, Linux, macOS
- Modelo de preço
-
Gratuito
Unbound é um resolvedor DNS recursivo e armazenado em cache de código aberto.
Os números pioraram e eu não me importei
196ms era um número com o qual eu poderia conviver
Então, quanto essa configuração me custou? Com tudo offline, eu queria ver se, além da independência total, ganhava alguma coisa em comparação com solucionadores de terceiros. Como o painel do AGH mostra apenas uma janela contínua de 24 horas, não consegui obter o desempenho histórico. Mas mesmo depois de mudar os servidores DNS Upstream de Quad9 para Unbound, ainda verifiquei o painel do AGH e os números não me agradaram.
A Quad9 ainda estava praticamente dominando os dados com cerca de 99,87% de solicitações, não porque ainda houvesse tráfego lá, mas porque a janela contínua de 24 horas da AGH ainda não havia acionado. Enquanto isso, o offline mostrou apenas algumas consultas. Quad9 teve média de 177ms, enquanto Unbound teve média de 288ms com cache frio. E o tempo de processamento não fazia sentido na época porque a própria revista ainda exibia principalmente o Quad9.
Verifiquei o painel novamente após 24 horas de execução sem restrições. Desta vez foram todos dados não consolidados, e o Quad9 desapareceu silenciosamente na memória; os novos números ainda não eram bons. O tempo de resposta máximo foi de 243 ms e o tempo de processamento foi definido em 147 ms. Percebi que a remoção do resolvedor de terceiros me causou uma penalidade de latência mensurável.
Eu ainda queria dar uma semana inteira de atividade para permitir que o cache aumentasse, esperando que isso ajudasse. O resultado melhorou do tempo de resposta upstream anterior de 243 ms para 196 ms e do tempo de processamento de 135 ms para 135 ms. Isso foi melhor do que no primeiro dia, mas ainda bem atrás do tempo de resposta original de 177ms e do tempo de processamento de 60ms do Quad9.
Não consegui um resolvedor mais rápido do que Quad9 ou Cloudflare, mas ter um resolvedor que permaneceu na minha cadeia e perdeu permanentemente algumas dezenas de milissegundos devido à independência parecia uma troca deliberada. Os números de desempenho me deram uma resposta, mas a arquitetura me deu o que realmente me importava.
Eu recuperei o controle, não a velocidade
Comecei esta jornada não porque provedores de DNS públicos como Quad9 e Cloudflare fossem lentos ou não confiáveis. Eu usei Quad9 e Cloudflare, às vezes separadamente, às vezes simultaneamente; ambos foram ótimos e mais rápidos do que acabei construindo. Combinei o AdGuard Home com o Unbound porque queria controle total sobre meu DNS. E essa configuração me devolveu o que o Technitium provou ser possível sem o custo do Technitium. Não estou dizendo que todos deveriam simplesmente abandonar os resolvedores públicos e optar pelo Unbound, mas se você já está se auto-hospedando para controle de DNS, o Unbound pode completar a última cadeia.
