DNS Soberano com Pi-hole e Unbound: Eliminando Rastreamento da Operadora e Bloqueando Telemetria
A privacidade na resolução de nomes de domínio é um dos elos mais negligenciados na segurança de redes domésticas e pequenas empresas. Mesmo utilizando HTTPS e TLS em todas as comunicações, as consultas DNS permanecem, por padrão, em texto plano e visíveis para qualquer nó intermediário, incluindo sua operadora de internet. Este artigo detalha a implementação de uma arquitetura de DNS soberano utilizando Pi-hole como filtro de bloqueio e Unbound como resolvedor recursivo local, eliminando a dependência de provedores de DNS públicos e garantindo validação criptográfica via DNSSEC.
O Problema da Dependência de Resolvers Públicos
Quando você configura seu roteador para usar 8.8.8.8 (Google) ou 1.1.1.1 (Cloudflare), troca a visibilidade da sua operadora pela visibilidade dessas corporações. Embora ofereçam DoH (DNS over HTTPS), os metadados de consulta ainda são centralizados e correlacionáveis. Além disso, muitos ISPs implementam interceptação transparente de DNS (redirecionamento forçado da porta 53), tornando inútil a simples alteração de servidores nos dispositivos clientes.
A solução arquitetural correta é tornar-se seu próprio resolvedor. Ao executar um resolvedor recursivo local, suas consultas partem da sua rede diretamente para os 13 Root Servers mundiais, descendo a árvore hierárquica (.com, .br, etc.) sem intermediários. Combinado com DNSSEC, isso garante autenticidade e integridade das respostas, impossibilitando ataques de envenenamento de cache por parte da operadora.
Arquitetura da Solução: Pi-hole + Unbound
A stack recomendada separa responsabilidades em dois processos distintos:
| Componente | Função | Porta | Responsabilidade | | :--- | :--- | :--- | :--- | | Pi-hole | Filtro de Camada de Aplicação | 53 | Bloqueio de listas, dashboard, DHCP opcional | | Unbound | Resolvedor Recursivo | 5335 | Consulta aos Root Servers, cache, validação DNSSEC |
O Pi-hole escuta na porta 53 padrão e encaminha todas as consultas permitidas para 127.0.0.1#5335. O Unbound, escutando apenas no loopback na porta 5335, realiza a recursão real. Essa separação impede que o Unbound seja acessível externamente e permite que o Pi-hole gerencie múltiplas listas de bloqueio sem interferir na lógica de resolução.
Instalação e Configuração do Unbound
Em sistemas baseados em Debian 13 (Trixie) ou Ubuntu 24.04+, instale o Unbound:
sudo apt update && sudo apt install unbound unbound-anchor -y
Inicialize a âncora de confiança do DNSSEC antes de iniciar o serviço:
sudo unbound-anchor -a /var/lib/unbound/root.key
sudo systemctl enable --now unbound
Configure o arquivo /etc/unbound/unbound.conf.d/pi-hole.conf com os parâmetros otimizados para uso como backend do Pi-hole:
server:
# Escuta apenas no loopback para evitar exposição externa
interface: 127.0.0.1
port: 5335
# Desativa IPv6 se não utilizado na rede local
do-ip6: no
# Habilita DNSSEC e valida assinaturas
val-permissive-mode: no
auto-trust-anchor-file: "/var/lib/unbound/root.key"
# Otimizações de cache para ambiente doméstico
cache-size: 100000
rrset-cache-size: 200000
msg-cache-size: 100000
key-cache-size: 100000
# Previne amplificação e spoofing
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: yes
# Privacidade: não repassa queries recusadas
hide-identity: yes
hide-version: yes
forward-zone:
# Não utilize forwarders; força recursão pura
name: "."
forward-addr:
Valide a sintaxe e reinicie:
sudo unbound-checkconf
sudo systemctl restart unbound
Teste a recursão e o DNSSEC:
dig +dnssec www.icann.org @127.0.0.1 -p 5335
# Deve retornar status: NOERROR e flag 'ad' no header
Integração com Pi-hole
Após instalar o Pi-hole (curl -sSL https://install.pi-hole.net | bash), acesse a interface web em Settings > DNS. Desmarque todos os upstream DNS providers (Google, OpenDNS, etc.) e adicione manualmente:
Custom 1 (IPv4): 127.0.0.1#5335
Desative a opção "Never forward non-FQDNs" e "Never forward reverse lookups" se desejar que o Unbound também resolva nomes internos não qualificados, embora para redes maiores seja preferível usar um domínio .local gerenciado pelo próprio Unbound via zona estática.
Ajuste de Timeout e Retries
O Pi-hole possui timeout padrão de 10 segundos, mas o Unbound pode demorar até 5 segundos na primeira consulta a um TLD pouco comum. Em /etc/pihole/setupVars.conf, ajuste:
PIHOLE_DNS_1=127.0.0.1#5335
DNS_FQDN_REQUIRED=true
DNS_BOGUS_PRIV=true
E no arquivo /etc/dnsmasq.d/99-pihole-custom.conf:
# Aumenta timeout para acomodar recursão fria
server=127.0.0.1#5335
timeout=10
retries=3
Reinicie o FTL: sudo pihole restartdns.
Validação de Segurança e Monitoramento
Com a stack operacional, valide três vetores críticos:
- Vazamento de DNS: Acesse browserleaks.com/dns e confirme que todos os servidores listados são o IP do seu Pi-hole, não IPs da operadora ou resolvers públicos.
- DNSSEC Ativo: Consulte
fail01.dnssec.works. O resultado deve ser SERVFAIL, indicando que o Unbound rejeitou a assinatura inválida. - Bloqueio Efetivo: Verifique no dashboard do Pi-hole se domínios de telemetria (
telemetry.microsoft.com,data.mistat.xiaomi.com) estão sendo bloqueados consistentemente.
Logs e Auditoria
Monitore os logs do Unbound em tempo real para identificar falhas de validação ou latência anômala:
sudo journalctl -u unbound -f --no-hostname
Habilite logging detalhado temporariamente adicionando verbosity: 2 ao config do Unbound para diagnosticar problemas de DNSSEC. Em produção, mantenha verbosity: 0 para reduzir I/O e evitar escrita excessiva em SSDs.
Considerações sobre Desempenho e Manutenção
O cache do Unbound é persistente apenas em memória. Reinícios do serviço limpam o cache, causando pico de latência nas primeiras consultas. Para mitigar, configure o systemd para reiniciar o Unbound apenas quando necessário e utilize unbound-control reload para recarregar zonas sem perder cache.
Atualize a âncora de confiança do DNSSEC periodicamente. O pacote unbound-anchor inclui um timer systemd que executa essa tarefa automaticamente, mas valide semanalmente com unbound-control trust_anchor_list para garantir que a chave raiz não expirou.
Esta arquitetura fornece soberania total sobre a resolução de nomes da sua rede. Ao eliminar intermediários, você reduz a superfície de ataque, melhora a latência após o warm-up e garante que nenhuma entidade externa tenha registro completo dos domínios que sua família ou empresa acessa. É infraestrutura defensiva básica que deveria ser padrão, não exceção.
