Seu próprio resolvedor DNS.
O único log que ninguém pensa em mudar de lugar.

Existem duas máquinas completamente diferentes escondidas atrás da frase "meu próprio servidor DNS", e quase todo tutorial constrói a errada. Decida isso antes de instalar qualquer coisa, porque é a diferença entre uma ferramenta de privacidade e um proxy para a política de privacidade de outra pessoa.

Um encaminhador pega a sua consulta e a repassa para outro resolvedor — normalmente Cloudflare, Google, Quad9 ou seu provedor de internet — e depois armazena em cache o que voltar. É simples, é rápido, e entrega todo o seu fluxo de consultas a um único terceiro. Todo guia que termina com "agora defina seu upstream como 1.1.1.1" construiu um destes.

Um resolvedor recursivo faz o trabalho ele mesmo. Para encontrar mail.example.com, ele pergunta a um servidor raiz quem cuida de .com, pergunta aos servidores de .com quem cuida de example.com, e então pergunta aos próprios nameservers de example.com pelo registro. Três ou quatro conversas curtas com três ou quatro operadores diferentes, nenhum dos quais sabe nada sobre os outros. Com a minimização de QNAME ativada, ele vai além: a raiz é consultada só sobre .com, e os servidores de .com só sobre example.com. O nome completo é revelado a exatamente uma parte — a que hospeda o nome, que de qualquer forma ia receber sua conexão trinta milissegundos depois.

As duas colunas da direita não são concorrentes — são as duas metades da mesma construção. O AdGuard Home é dono da porta 53, aplica as listas de bloqueio e termina os transportes criptografados; o Unbound fica atrás dele, em loopback, e faz a resolução. Nenhuma das metades faz bem o trabalho da outra, e a cadeia inteira usa cerca de cem megabytes de RAM.

Se você levar só uma coisa desta página, leve esta: um resolvedor que encaminha para um provedor DNS público não tornou o seu DNS privado. Ele só moveu o log um salto adiante e acrescentou um servidor à sua lista de manutenção. A recursão é o ponto inteiro da coisa.

O Unbound é um resolvedor validador, recursivo e com cache, da NLnet Labs. Ele está empacotado em todo lugar, é o que boa parte da internet já roda, e, pronto para uso, ele faz recursão — você tem que se esforçar de propósito para transformá-lo num encaminhador. Instale-o junto com o pacote de root hints para que ele saiba onde estão os servidores raiz sem precisar buscar uma lista em lugar nenhum:

apt update && apt install -y unbound dns-root-data
unbound -V | head -2

O pacote dns-root-data instala as root hints em /usr/share/dns/root.hints e a âncora de confiança raiz do DNSSEC em /usr/share/dns/root.key, e mantém as duas atualizadas pelo canal normal de pacotes. Essa é a forma chata e correta de consegui-las; baixar o root.hints de uma URL num cron job é a forma que, mais cedo ou mais tarde, falha em silêncio.

/etc/unbound/unbound.conf.d/nb-resolver.conf

server:
    # ---- Who may ask. Deny first, allow narrowly.
    interface: 127.0.0.1@5335
    interface: 10.8.0.1
    access-control: 0.0.0.0/0 refuse
    access-control: ::0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.8.0.0/24 allow

    # ---- Privacy of the recursion itself.
    qname-minimisation: yes
    qname-minimisation-strict: no
    hide-identity: yes
    hide-version: yes
    rrset-roundrobin: yes

    # ---- DNSSEC. The anchor is maintained by the dns-root-data package.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    root-hints: "/usr/share/dns/root.hints"
    harden-dnssec-stripped: yes
    harden-glue: yes
    harden-below-nxdomain: yes
    harden-large-queries: yes
    harden-short-bufsize: yes
    aggressive-nsec: yes
    val-clean-additional: yes

    # ---- Do not be a reflector, even by accident.
    refuse-any: yes
    ratelimit: 1000
    ip-ratelimit: 200
    edns-buffer-size: 1232

    # ---- Cache. This is where the 4 GB actually earns its keep.
    msg-cache-size: 128m
    rrset-cache-size: 256m
    cache-min-ttl: 60
    cache-max-ttl: 86400
    prefetch: yes
    prefetch-key: yes
    serve-expired: yes
    serve-expired-ttl: 3600

    # ---- Never chase a name that has no business being on the internet.
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10

    num-threads: 2
    so-reuseport: yes
    verbosity: 0
    logfile: ""

remote-control:
    control-enable: yes
    control-interface: /run/unbound.ctl

Quatro dessas linhas estão fazendo o trabalho de verdade e merecem uma frase cada uma.

• 01access-control: 0.0.0.0/0 refuse — a resposta padrão para a internet é "não". Tudo depois dela é uma exceção que você escreveu de propósito. Essa única linha já é o que barra a história de amplificação do passo 02 antes mesmo de o firewall precisar agir.
• 02qname-minimisation: yes — os servidores raiz são consultados sobre .com, não sobre o hostname completo. RFC 9156, ativado por padrão nas versões atuais do Unbound, e o motivo pelo qual um resolvedor recursivo vaza menos do que o diagrama sugere. Deixe o modo estrito desligado: um pequeno número de zonas malconfiguradas ainda quebra com ele ativado.
• 03refuse-any: yes — consultas ANY retornam a maior resposta possível para a menor pergunta possível, que é exatamente o que um ataque de amplificação quer. Nada legítimo precisa delas.
• 04serve-expired: yes — quando um servidor autoritativo está inalcançável, entregue a resposta vencida e renove em segundo plano, em vez de falhar. Essa é a configuração que impede que uma queda distante pareça, para todo mundo em casa, a internet ter caído.

Note as duas escutas. O loopback na porta 5335 é o que o AdGuard Home vai usar no próximo passo; 10.8.0.1 é o endereço do túnel, para que clientes na VPN possam consultar o Unbound diretamente caso você decida pular a camada de filtragem. Se você ainda não está rodando o WireGuard, remova por enquanto essa segunda linha de interface — o Unbound não vai iniciar com um endereço que não existe na máquina.

Inicie-o e prove que funciona:

unbound-checkconf
systemctl restart unbound && systemctl enable unbound

apt install -y dnsutils
dig @127.0.0.1 -p 5335 nordbastion.com +short

# DNSSEC: the first must come back with the "ad" flag set,
# the second must FAIL — its signatures are deliberately broken.
dig @127.0.0.1 -p 5335 dnssec-tools.org +dnssec | grep -E 'flags:|status:'
dig @127.0.0.1 -p 5335 dnssec-failed.org  | grep 'status:'

A flag ad na primeira resposta significa que o Unbound conferiu a cadeia de assinaturas desde a raiz até o registro, e ela se sustentou. O SERVFAIL na segunda significa que a validação rejeitou uma resposta adulterada em vez de repassá-la a você. Se a segunda retornar um endereço em vez disso, a validação não está ativa, e a âncora de confiança é a primeira coisa a checar.

Um resolvedor que ninguém consegue alcançar não serve para nada, e um resolvedor que todo mundo consegue alcançar é o modo de falha do passo 02. Existem exatamente duas boas respostas, e a maioria das pessoas acaba rodando as duas — o túnel em casa e no laptop, o DNS criptografado no celular e em redes onde o UDP é filtrado.

Opção A — pelo WireGuard. A melhor das duas, e o motivo de este guia continuar apontando para o guia de WireGuard. A porta 53 continua invisível para a internet, a consulta em si nunca atravessa uma rede não confiável em forma alguma, e não há certificado para renovar. Se o VPS já é a sua saída de VPN, isso é uma linha na configuração de cada peer:

# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1

Uma sutileza que costuma pegar as pessoas: no Linux, o wg-quick define esse endereço através do resolvconf ou do systemd-resolved, e, se nenhum dos dois estiver instalado, ele silenciosamente não faz nada enquanto o túnel sobe perfeitamente. Verifique com resolvectl status ou lendo /etc/resolv.conf depois que o túnel subir — um túnel funcionando com o resolvedor antigo ainda configurado é exatamente o vazamento que todo este exercício busca evitar.

Opção B — DNS sobre TLS e DNS sobre HTTPS. Necessário quando o dispositivo não pode estar sempre no túnel. Os dois são autenticados por certificado, o que significa um hostname: aponte um registro A para o VPS, e então deixe o AdGuard Home segurar o certificado diretamente ou o coloque atrás de um proxy reverso que já termina o TLS para você. As escutas são 853/tcp para DoT e 443/tcp para DoH.

ufw allow 853/tcp                     # DNS-over-TLS
ufw allow 443/tcp                     # DNS-over-HTTPS
# 53/udp is still NOT open on the public interface. It never will be.
ufw status

Dê ao endpoint de DoH um caminho que não seja adivinhável — o AdGuard Home permite servi-lo em /dns-query/<random>, e um caminho diferente por pessoa significa que o acesso pode ser revogado uma pessoa de cada vez, sem rotacionar nada para todo o resto. Isso não é autenticação em nenhum sentido forte, mas evita que uma escuta pública seja, na prática, um resolvedor aberto com passos a mais.

A linha do roteador é a que merece atenção. Distribuir seu resolvedor via DHCP cobre todos os dispositivos da casa de uma vez, incluindo os que não têm tela de configurações — mas o salto do roteador até o VPS passa a ser DNS simples pela internet aberta, que é exatamente o que você se propôs a evitar. Rode o túnel no próprio roteador, ou aceite que a última milha fica sem criptografia e deixe a recursão ser o ganho.

Uma última configuração que vale a pena conhecer: um navegador com DNS sobre HTTPS ativado vai usar o próprio resolvedor e ignorar silenciosamente a configuração do sistema, túnel ou não. Firefox e Chrome vêm com isso ativado por padrão em algumas regiões. Ou aponte o navegador também para o seu endpoint, ou desative o DoH dele para que siga o sistema operacional.

Um resolvedor privado é uma melhoria real, e não é uma capa de invisibilidade. Quem vender isso como uma capa está vendendo outra coisa. Aqui está a lista do que continua visível depois que tudo acima estiver feito, porque conhecer a forma da exposição que resta é a diferença entre uma defesa de verdade e um cobertor de conforto.

A conexão ainda acontece. Um milissegundo depois da consulta, o seu dispositivo abre uma conexão TCP para o endereço que acabou de descobrir. Quem estiver observando a sua linha vê esse endereço. Para um site com IP próprio, o endereço é o site. O DNS criptografado remove a pergunta; ele não remove a resposta.

O handshake TLS geralmente entrega o nome do site. O Server Name Indication é enviado em claro no início de quase toda conexão HTTPS, então um observador passivo lê o hostname de qualquer forma. O Encrypted Client Hello corrige isso e está implantado de forma desigual — onde tanto o navegador quanto o site o suportam, o nome fica escondido, e onde não suportam, não fica. Não presuma que ele está ativo.

O operador do resolvedor agora é você, e você é uma pessoa só. Todo servidor autoritativo com quem o seu resolvedor fala vê um único endereço IP perguntando sobre a zona dele. Espalhado por muitas zonas, esse IP tem um padrão característico, e o padrão é uma casa. Esse é o custo de conjunto de anonimato do primeiro capítulo, e a única coisa que o suaviza é o IP não ser rastreável até um nome — um VPS sem KYC pago em cripto — e, idealmente, ser o mesmo IP de onde o seu tráfego já sai.

O provedor pode ver os pacotes, como sempre. O VPS roda no hardware de alguém, no datacenter de alguém. A NordBastion não inspeciona o tráfego dos clientes, e o relatório de transparência e o warrant canary descrevem o que aconteceria se fôssemos questionados — mas a afirmação arquitetural honesta é que uma máquina que você aluga é uma máquina que outra pessoa pode alcançar fisicamente. O que autogerenciar muda é que não há log de consultas em nível de produto, nem pipeline de analytics, nem política de privacidade que possa ser alterada; há só um processo guardando um cache na RAM, configurado por você, numa jurisdição que você escolheu de propósito.

O que você comprou de fato, com precisão: a fonte mais rica e mais barata de dados comportamentais sobre você deixou de ser coletada por uma parte cujo modelo de negócio envolve coletar exatamente isso. Essa é uma afirmação estreita, e é uma afirmação real. Nada nesta página substitui o Tor quando o modelo de ameaça pede Tor — e, para isso, o guia de serviço onion abaixo é a próxima leitura honesta.