Substituí Pi-hole por Unbound por uma semana, e a atualização de privacidade não foi o único benefício.

Minha configuração de DNS funcionou perfeitamente. Pi-hole tratou do bloqueio de anúncios, do tráfego DNS criptografado por dnscrypt-proxy e o Quad9 resolveu todas as consultas geradas pela minha rede. Eu uso essa configuração há muito tempo e raramente penso nisso. Então comecei a pensar: se a filtragem e a criptografia de DNS já estavam na minha pilha local, por que eu estava permitindo que um resolvedor de terceiros visse todas as consultas feitas pela minha rede? Cada pesquisa foi terceirizada para a infraestrutura de outra pessoa. Esse pensamento simples foi suficiente para substituir o solucionador público por um auto-hospedado – sem restrições. Estou usando há uma semana, esperando por melhor privacidade. E no final da semana eu tinha uma compreensão muito mais clara do que meu DNA estava realmente fazendo.

Pi-hole fez o trabalho, mas na verdade não resolveu o DNA

A peça que faltava

Quando configurei o Pi-hole em meu servidor Debian doméstico, meu principal motivo foi bloquear anúncios na rede, não porque eu odeie anúncios em sites ou aplicativos. Sou editor e desenvolvedor independente. Coloco anúncios em meu aplicativo e site como fonte de monetização. Mas alguns sites têm mais anúncios do que o conteúdo que visitamos. Eu poderia conviver com os anúncios, mas pessoas como minha mãe, que tinham uma pegada digital menor, tinham dificuldade para navegar nos aplicativos sem clicar acidentalmente nos anúncios. Implantei o Pi-hole em meu servidor doméstico e o conectei em rede por meio de meu gateway WAN duplo e nossa experiência online foi limpa.

O buraco resolveu o problema de visibilidade, mas deixou outro intacto. Certa vez, notei que o Pi-hole estava apenas filtrando solicitações como um gatekeeper – filtrando as solicitações localmente, mas repassando-as à medida que saíam da minha rede. Comecei a explorar mais opções. Honestamente, Pi-hole fez o que deveria fazer. Não era função do Pi-hole verificar as consultas depois que elas haviam passado do escopo do Pi-hole, se elas viajavam em texto simples ou foram resolvidas ou não. Para corrigir isso, adicionei outra camada à configuração como DNS sobre HTTPS para criptografar as consultas até que cheguem ao resolvedor. Eu hospedei dnscrypt-proxy para criptografar solicitações de DNS e configurei resolvedores DNS Quad9 e Cloudflare.

Após a configuração completa, um dos meus problemas de configuração de DNS em texto simples foi resolvido, mas ainda tinha mais um. As solicitações de DNS ainda chegaram a resolvedores de DNS de terceiros, no meu caso Quad9 e Cloudflare. Mesmo que o tráfego tenha sido criptografado, a Quad9 e a Cloudflare ainda receberam todas as consultas e realizaram a pesquisa. O fluxo foi o seguinte:

Device -> Pi-hole -> dnscrypt-proxy -> Quad9/CF (root servers → TLD servers → authoritative servers)

Eu já estava interessado em alternativas de autoatendimento. Comecei a procurar opções para possuir a última parte do ciclo, o DNA. O DNS ainda era terceirizado e eu não estava pronto para aceitá-lo. Isso não quer dizer que não confio na Quad9 ou na Cloudflare, mas estou mais inclinado a possuir essa parte. Se os resolvedores públicos ainda estivessem fazendo todas as pesquisas, o que aconteceria se eu os removesse completamente? Foi quando pensei em tentar o Unbound. Em vez de encaminhar solicitações upstream, o Unbound poderia resolvê-las sozinho. Parecia uma experiência divertida de fim de semana.

O benefício da privacidade era real, mas a independência era mais importante

Menos um intermediário

Usando Pi-hole e dnscrypt-proxy, os provedores de DNS Quad9/Cloudflare ficavam entre minha rede e o sistema DNS mais amplo. Eles cuidaram de todas as pesquisas recursivas em meu nome e seus registros tinham uma imagem completa de cada domínio que visitei. Mas quando o Unbound foi lançado, esse resolvedor público desapareceu e nenhum provedor de DNS cuidava mais de todas as pesquisas. Mas, ao mesmo tempo, perdi a camada de criptografia de saída. O novo fluxo do meu tráfego tornou-se:

Device -> Unbound -> root servers -> TLD servers -> authoritative servers

Com a resolução do processamento desacoplado, cada parte da cadeia de liquidação passa agora para uma parte diferente. Os servidores raiz só sabiam que eu estava perguntando onde encontrar .com. Os servidores TLD sabiam qual domínio eu estava procurando. E os servidores autorizados só viam solicitações de seus próprios domínios. Nenhuma das partes viu a cadeia, apenas os seus respectivos segmentos. Isso não me tornou anônimo nem ocultou magicamente minha atividade na Internet, apenas removeu um observador centralizado.

Por fim, minha rede não dependia de resolvedores públicos como Quad9 e Cloudflare. Troquei não porque esses serviços fossem ruins, mas porque queria que o DNA fosse outro serviço que pertencesse ao meu laboratório doméstico. Eu já estava auto-hospedando o gateway, o armazenamento e os aplicativos e, de repente, o próprio resolvedor parecia parte de minha própria infraestrutura hospedada. Não só fiquei feliz com o ângulo da privacidade, mas também fiquei surpreso com as estatísticas.

Configurei no sábado e deixei funcionando por dois dias de trânsito real. Em dois dias, já resolveu 25.845 consultas com 63.641 pacotes UDP de saída, tempo médio de recursão de 148ms e 6.596 acessos de cache. 63.641 saídas UDP contra 25.845 consultas resultaram em aproximadamente 2,5 pacotes de saída por consulta, indicando que cada consulta tocou uma parte diferente da cadeia de resolução. Já não era uma teoria e nem algo testado num laboratório simulado; Vi números reais em meu fluxo de trabalho diário.

Parei de depender do Quad9 ou Cloudflare para fazer o trabalho e observei meu próprio servidor fazer isso.

A maior atualização foi algo que eu não esperava que o Unbound fizesse

Uma vitória inesperada

Ok, substituí o resolvedor público por um auto-hospedado. Tudo funcionou bem, mas enquanto isso esqueci o recurso principal que pretendia quando escolhi o Pi-hole – o bloqueio de anúncios. Eu disse a um colega que executaria o Unbound e o Pi-hole juntos, já que o Unbound sozinho não lida com o bloqueio de anúncios. Ele então me disse que, embora não exista uma maneira direta de bloquear anúncios com o Unbound, eu poderia criar uma lista personalizada de bloqueio de anúncios que funcionaria com resolução DNS.

Eu imediatamente escrevi um script que baixou a lista unificada de hosts de Stephen Black de 83.600 domínios do repositório GitHub e a salvou como um arquivo blocklist.conf em cada execução.

#!/bin/bash
BLOCKLIST_URL="https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts"
OUTPUT="/etc/unbound/unbound.conf.d/blocklist.conf"

echo "Downloading blocklist..."
echo "server:" > /tmp/blocklist.conf
curl -s "$BLOCKLIST_URL" | grep '^0\.0\.0\.0' | awk '{print "    local-zone: \""$2"\" redirect\n    local-data: \""$2" A 0.0.0.0\""}' >> /tmp/blocklist.conf

echo "Installing blocklist..."
mv /tmp/blocklist.conf "$OUTPUT"

echo "Restarting Unbound..."
systemctl restart unbound

echo "Done. $(grep -c 'local-zone' $OUTPUT) domains blocked."

Quando a lista de domínios foi carregada, vi uma mudança repentina no uso da memória; A memória passou de cerca de 7 MB para quase 88 MB quando a lista de bloqueio foi carregada. Mas os números após dois dias de uso fizeram com que esse salto de memória fosse facilmente esquecido.

Com bloqueio de anúncios e DNSSEC, as estatísticas pareciam 1.760 respostas NXDOMAIN, 3.406 respostas validadas de DNSSEC e 1.953 pré-carregamentos. Isso significava que o Unbound bloqueava anúncios e rastreadores enquanto verificava criptograficamente se as respostas não haviam sido adulteradas. E foi a primeira vez que entendi o que esses números realmente significavam.

O experimento não foi totalmente perfeito. Também pude ver 148 solicitações excedidas; isso significou que a fila foi preenchida 148 vezes durante o carregamento. Não é surpresa se o servidor já estiver rodando com 19 contêineres. As surpresas não pararam por aí; ele também tinha funcionalidade nativa de divisão de DNA que eu havia usado anteriormente com Pi-hole. Configurei-o para resolver meu domínio Jellyfin local, acessando pela mesma rede local, contornando o túnel Cloudflare. E por que Jellyfin em primeiro lugar? Devido às limitações do serviço Cloudflare para streaming.

Houve algumas coisas que perdi no buraco Pi. A visibilidade era o mais importante. Quando abri o painel Pi-hole, eu sabia exatamente o que estava acontecendo na minha rede. Não apenas números brutos, mas dados reais e legíveis. Atividade do cliente, tipos de consulta, domínios bloqueados exatos e tempos de resposta. Na configuração ilimitada eu tinha estatísticas, mas eram apenas números brutos disponíveis apenas através do terminal.

Mesmo se eu voltar ao Pi-hole ou passar para outra coisa, agora entendo uma parte da infraestrutura da Internet que terceirizei e em grande parte ignorei.

Uma semana depois: valeu a pena?

Uma semana com Unbound me convenceu de que este não é um simples substituto de Pi-hole que alguém deveria se apressar. Substituir Pi-hole por Unbound não tornou minha internet repentinamente mais rápida nem revelou quaisquer falhas em minha configuração. Tudo na minha configuração já estava fazendo o que deveria. Mas isso me convenceu de que a maioria dos laboratórios domésticos terceiriza a resolução de DNA sem pensar duas vezes.

Se você não deseja zero dependências anteriores e só pode usar o gerenciamento de terminal, vale a pena executar o Unbound, mesmo que temporariamente. Mas se você depende de painéis para obter visibilidade e precisa de uma configuração mais simples e gerenciada por GUI, o Pi-hole é para você. E se você quiser o melhor de ambos, você sempre pode executar o Pi-hole com o Unbound. Às vezes, os melhores projetos de laboratório doméstico não são aqueles que adicionam novos recursos – são aqueles que revelam quanta infraestrutura você considera garantida.