Introdução
Ao discutir a soberania de DNS em redes locais, é notável que muitos desenvolvedores experientes ainda negligenciam esse tópico. Recentemente, montei uma stack com Pi-hole e Unbound recursivo em minha rede doméstica e percebi uma diferença significativa na postura de segurança e privacidade. Apesar do uso de HTTPS/TLS em tudo, as consultas DNS continuam em formato de texto plano e visíveis para a operadora ou qualquer nó intermediário.
Separação de Responsabilidades entre Filtro e Resolvedor
O primeiro ponto técnico importante é a separação de responsabilidades entre o filtro e o resolvedor. O Pi-hole fica na porta 53 como gateway de bloqueio, mas quem faz o trabalho pesado de recursão é o Unbound, que escuta apenas no loopback na porta 5335. Isso impede a 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 para isso em /etc/unbound/unbound.conf.d/pi-hole.conf é:
options {
bind-addr 127.0.0.1;
port 5335;
}Validação DNSSEC Obrigatória
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 .. Para testar se está funcionando de verdade, consulte fail01.dnssec.works, que deve retornar SERVFAIL, confirmando que cadeias quebradas são rejeitadas. Referência oficial: https://dnssec.vs.uni-due.de/.
Performance Após o Warm-up
Muita gente acha que a recursão local é lenta, mas após o cache aquecer, a latência média cai para 1-5ms porque não há ida e volta para 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 para evitar I/O desnecessário em SSD e use unbound-control reload ao invés de restart para preservar o cache.
Discussão sobre DoT (DNS over TLS)
Minha pergunta para a comunidade é: alguém aqui já implementou DoT (DNS over TLS) entre o Pi-hole e o Unbound na mesma máquina? Ou acham o overkill sendo a comunicação loopback? Eu estou considerando adicionar essa camada caso decida migrar o Unbound para um container separado no futuro, mas queria ouvir experiências reais antes de complicar a arquitetura.
Conclusão
Implementar DNS soberano com Pi-hole e Unbound é uma maneira eficaz de garantir que suas consultas DNS não sejam rastreadas pela operadora ou interceptadas por nós intermediários. A separação de responsabilidades, validação DNSSEC obrigatória e otimização de performance são pontos cruciais para essa implementação. A adição de DoT pode ser uma opção futura, mas é importante ouvir a experiência de quem já implementou essa solução antes de tomar uma decisão definitiva.