DNS Soberano com Pi-hole e Unbound: Eliminando Rastreamento da Operadora e Bloqueando Telemetria · EvandroCarvalho

Fala pessoal!

Queria trazer uma discussão sobre soberania de DNS em redes locais, um tópico que vejo ser negligenciado até por devs experientes que confiam cegamente em resolvers públicos. Recentemente montei uma stack com Pi-hole + Unbound recursivo na minha rede doméstica e a diferença na postura de segurança e privacidade foi imediata. O problema real é que mesmo usando HTTPS/TLS em tudo, suas consultas DNS continuam em texto plano e visíveis para a operadora ou qualquer nó intermediário, e muitos ISPs fazem interceptação transparente da porta 53, redirecionando seu tráfego mesmo quando você configura outro resolver manualmente.

O primeiro ponto técnico importante é a separação de responsabilidades entre filtro e resolvedor. O Pi-hole fica na porta 53 como gateway de bloqueio, mas quem faz o trabalho pesado de recursão é o Unbound escutando apenas no loopback na porta 5335. Isso impede exposição externa do resolvedor e permite que o cache do Unbound seja agressivo sem interferir nas listas de bloqueio. A config básica do Unbound pra isso em /etc/unbound/unbound.conf.d/pi-hole.conf fica assim:

server:
  interface: 127.0.0.1
  port: 5335
  val-permissive-mode: no
  auto-trust-anchor-file: "/var/lib/unbound/root.key"
  harden-dnssec-stripped: yes
  use-caps-for-id: yes
  hide-identity: yes

O segundo ponto é a validação DNSSEC obrigatória. Sem ela, você está vulnerável a envenenamento de cache pela própria operadora. O Unbound valida assinaturas automaticamente quando configurado com val-permissive-mode: no e a âncora de confiança inicializada via unbound-anchor. Pra testar se tá funcionando de verdade, consulte fail01.dnssec.works — tem que retornar SERVFAIL, confirmando que cadeias quebradas são rejeitadas. Referência oficial: https://dnssec.vs.uni-due.de/.

O terceiro ponto é performance pós-warm-up. Muita gente acha que recursão local é lenta, mas após o cache aquecer, a latência média cai pra 1-5ms porque não há ida e volta pra resolver externo. A primeira consulta fria pode levar 20-80ms extras percorrendo a hierarquia desde os Root Servers, mas isso acontece uma vez por TTL. Em produção, mantenha verbosity: 0 no Unbound pra evitar I/O desnecessário em SSD e use unbound-control reload ao invés de restart pra preservar o cache.

Minha pergunta pra comunidade: alguém aqui já implementou DoT (DNS over TLS) entre o Pi-hole e o Unbound na mesma máquina, ou acham overkill sendo comunicação loopback? Tô considerando adicionar essa camada caso decida migrar o Unbound pra um container separado no futuro, mas queria ouvir experiências reais antes de complicar a arquitetura.

Um ajuste no reload: pela man page, o unbound-control reload limpa o cache e relê a config. Pra manter o cache quente tem o reload_keep_cache (desde o 1.17.1), que só funciona se o tamanho dos caches e o número de threads não mudarem.

E o guia do Pi-hole deixa use-caps-for-id em no, porque às vezes dá problema com DNSSEC.

Sobre a pergunta do DoT: o trecho em texto puro que pesa não é o loopback, é o do Unbound pra fora. Na recursão, as consultas pros servidores autoritativos saem pela porta 53 sem cifra, então a operadora continua vendo os nomes (o qname minimisation só esconde o nome completo da raiz e do TLD) e pode interceptar. Você tira o resolver de terceiro da jogada, não a operadora. Pra esconder dela, o caminho é um forward-zone com forward-tls-upstream: yes pra um resolver público, que aí passa a ver tudo. E o SNI do TLS ainda entrega o domínio na maioria dos sites.