DNS leak: o que é, como testar e por que o proxy sozinho não basta

O time fecha o checker de WebRTC, sorri, e publica. O HTTP do perfil mostra um residencial em São Paulo. O STUN está limpo. Duas horas depois alguém abre um teste de DNS e a consulta ainda cai no resolvedor da Claro do escritório. Para a página, o caminho foi um. Para o sistema de nomes, foi outro. Isso não é detalhe de laboratório. É dois lugares ao mesmo tempo, só que no eixo que a planilha de IP quase nunca lista.

DNS leak é isso: o browser pergunta “qual o IP deste host?” por um caminho que o proxy HTTP não vê. O provedor de DNS vê o site que você resolve, a hora, e de que rede a pergunta saiu. Este texto é educacional e operacional. Não ensina a esconder crime. Ensina o gestor a testar o perfil vazio, a não misturar furo de DNS com furo de WebRTC, e a recusar o mito de que “o proxy está ligado, então a rede inteira está certa”. O hub de comparativos agrupa ferramentas. O ritual abaixo é o mesmo em qualquer stack séria.

O que o DNS faz quando você abre o Ads Manager

Antes do TLS, antes do cookie, o browser precisa de um endereço. Você digita ou clica um host. O sistema pergunta a um resolvedor. O resolvedor responde com um IPv4, um IPv6, ou os dois. Só então o HTTP — e o proxy — entram na conversa.

Esse resolvedor não é o site de anúncio. É um serviço de nomes: o da operadora, o do escritório, o do roteador, um 8.8.8.8, um 1.1.1.1, ou um DNS sobre HTTPS. Quem opera o resolvedor vê metadado. Não vê o POST da campanha. Vê que aquele IP de origem perguntou por ads.google.com, business.facebook.com, ads.tiktok.com, em sequência, às 9h14.

Na agência isso importa por dois motivos. Primeiro, consistência: se o HTTP sai por um residencial em Pinheiros e o DNS sai pela fibra empresarial em Savassi, a identidade de rede está rachada. Segundo, vazamento de intenção: mesmo com o conteúdo criptografado, o padrão de consultas conta uma história. Padrão de mesa de mídia é reconhecível. Não é prova jurídica de nada. É sinal barato.

Você não precisa virar administrador de bind. Precisa da frase: proxy no HTTP não é contrato de DNS. Se ninguém configurou o DNS do perfil, o sistema operacional decide. O sistema operacional da agência costuma decidir “o DNS da operadora”.

O que é leak, o que é só DNS “diferente”

Nem todo DNS fora do proxy é incidente. Precisa de critério.

Leak, no sentido operacional deste artigo, é o resolvedor ver a rede real — escritório, casa do gestor, 4G do celular — enquanto o HTTP da página de anúncio usa outro IP. O checker de DNS leak lista os servidores que responderam. Se a lista é o ASN da Vivo da sala e o ipinfo do HTTP é um residencial de outro estado, você tem o desencontro.

DNS “diferente mas coerente” é outro caso. O perfil força DoH para um resolvedor público, e o HTTP sai por um proxy cujo próprio caminho já era conhecido. Ainda pode ser um desencontro de país ou de reputação. Não é o mesmo filme do ISP do escritório aparecendo no teste. Trate os dois. Não os funda num único susto.

Há ainda o falso positivo clássico. O teste abre vários hosts. Alguns resolvem em CDN. O relatório mostra IPs de Anycast. Gestor lê “vários países” e conclui que o perfil está “queimado”. Anycast não é leak. Leak é origem da consulta na rede que você não documentou.

A leitura honesta pede duas colunas. Coluna A: IP HTTP do perfil, geo, ASN. Coluna B: resolvedores que o teste viu, geo, ASN. Se A e B contam a mesma história plausível, passe para o próximo eixo. Se B é a operadora da sala, pare. Não logue a BM.

Por que o proxy sozinho não basta

Proxy HTTP e SOCKS5 encapsulam o que a aplicação manda por aquele cano. A consulta de DNS, em muita stack, acontece antes ou ao lado. O sistema pergunta ao DNS da placa. O browser pergunta ao DNS do SO. Só o tráfego do site vai ao proxy.

Extensão de proxy no Chrome vanilla é o exemplo didático. O site abre pelo túnel. O nslookup mental do browser ainda pode ir ao DNS da máquina. Antidetect mal configurado faz o mesmo: perfil com proxy no HTTP e DNS no host.

SOCKS5 com remote DNS, quando o cliente honra isso, manda a resolução pelo proxy. HTTP CONNECT, em vários setups, não. A nuance importa na compra e no teste, não no slogan. A pergunta ao fornecedor não é “tem proxy?”. É “a resolução de nome deste perfil sai por onde?”. Se a resposta for um olhar vazio, teste você.

VPN de consumidor por cima do proxy piora. Terceiro IP, terceiro DNS, ninguém documentou. O perfil de anúncio não é o notebook do sócio no aeroporto. Um cano de cada vez. Teste o perfil só com o proxy da operação.

IPv6 entra de novo. Dual stack resolve AAAA. Se a placa tem IPv6 da operadora e o proxy só engole IPv4, a consulta AAAA pode ir pela rota nativa. O artigo de IPv6 e conta de anúncio aprofunda esse eixo. Aqui cabe a nota: teste de DNS em IPv4 limpo não aprova IPv6.

Como testar sem relogar a conta quente

Ritual curto. Igual ao de WebRTC: perfil vazio, print, freeze, só então autenticação.

Abra o perfil da identidade com o proxy já aplicado. Sem cookie de BM. Sem extensão de laboratório que você não usa em produção. Sem a VPN pessoal ligada “por via das dúvidas”.

Rode um teste de DNS leak reconhecido pelo time — o mesmo, sempre. Não cinco sites diferentes a cada incidente. Anote os resolvedores, o IP que o teste atribui à origem, o país. Screenshot com relógio visível.

Na mesma sessão, anote o IP HTTP. ipinfo, whoer, o checker que a mesa já usa para qualidade de IP. Não misture as abas com a conta logada de outro cliente.

Compare. Origem DNS versus origem HTTP. ASN. Geo. Se brigarem, o perfil não está pronto. Corrija DNS ou proxy. Teste de novo. Não “vai assim que o Ads abriu”.

Repita depois de mudar proxy, de atualizar o browser, de trocar de rede (escritório para casa). DNS é dos eixos que mudam quando o gestor leva o laptop. Home office sem reteste é leak com agenda.

Não teste com a sessão de anúncio já autenticada “porque é mais rápido”. O teste em si é inofensivo. O hábito de abrir checker e gerenciador no mesmo fôlego, no perfil errado, não é. Disciplina: laboratório, depois trabalho.

Se o teste listar o DNS da empresa e você “já sabia”, ainda é leak. Saber não fecha o furo. Fecha o furo forçar a resolução pelo mesmo caminho do HTTP, ou aceitar o risco por escrito — o que uma mesa séria quase nunca aceita em conta de cliente.

DoH, DoT e o interruptor que cria outro problema

DNS over HTTPS e DNS over TLS escondem a consulta do ISP local. O resolvedor passa a ser Cloudflare, Google, o do próprio browser. Para o técnico da operadora, a pergunta de nome some. Para a mesa de mídia, surge outra pergunta: esse resolvedor é coerente com o IP HTTP?

Perfil com HTTP no residencial brasileiro e DoH em resolvedor cuja reputação e geo não combinam com a conta é desencontro novo. Não é o leak clássico do escritório. É inconsistência. Plataformas de anúncio não publicam um PDF “banimos por 8.8.8.8”. Elas somam sinais baratos. País do IP, idioma, fuso, e às vezes o cheiro de rede. Não otimize um sinal quebrando o outro.

Política da agência deve escolher. Ou o DNS sai pelo proxy (remote DNS), e o HTTP também. Ou o perfil usa um DoH documentado, igual em todos os perfis daquela geo, testado, com print na entrada. O que não deve existir é cada gestor ligar “DNS seguro” no Chrome do host e achar que melhorou o antidetect.

DoH no sistema operacional, fora do perfil, afeta todos os browsers da máquina. O perfil isolado pode herdar. Teste de novo depois de qualquer mudança de DNS no Windows ou no Mac da agência. O roteiro de máquina de mídia inclui essa linha. Não é frescura de segurança. É consistência de sessão.

DNS, WebRTC e a ordem do ritual

Gestor cansa de checker. Aí escolhe um e ignora o outro. Escolha errada.

WebRTC denuncia IP da placa e IP público via STUN. DNS denuncia resolvedor e origem da consulta. Cookie denuncia sessão. Fingerprint denuncia dispositivo. Qualidade de IP denuncia reputação do ASN. Nenhum substitui o outro. O texto de WebRTC já deixa isso explícito. Repita na parede da mesa: dois testes, dois prints, um go/no-go.

Ordem prática, perfil vazio:

Rede HTTP. Proxy no ar, IP e geo esperados.

WebRTC. Sem público da operadora no STUN. Host local isolado não assusta. Público real da sala assusta.

DNS. Resolvedor coerente. Sem ISP do escritório se o HTTP não é o escritório.

Só então fuso, idioma, user-agent. Só então login.

Se o tempo de plantão não cabe nisso, o perfil não deveria ser aberto fora do horário. Conta quente não é laboratório. Laboratório não é conta quente.

Captura o print no repositório da identidade, não no WhatsApp. Daqui a três meses o cliente pergunta se “vocês testam rede”. A resposta vira arquivo, não memória do coordenador.

O que documentar no inventário

A coluna de proxy já deveria existir: tipo, geo, sticky, provedor, quem paga. Some DNS.

Como resolve: remote no proxy, DoH do perfil, herdado do SO. Qual resolvedor aparece no teste padrão. Data do último print. Quem testou.

Quando o gestor troca de casa, a linha de DNS é a primeira que murcha. BYOD e home office tornam o SO um fornecedor de rede. Trate como fornecedor: reteste.

Não transforme isso em NOC. A agência não precisa de Grafana de query DNS. Precisa de um ritual que um humano segue na segunda-feira e na entrada de gente nova. Se o teste falhar, o perfil não entra em produção. Simples. O custo é meia hora. O custo do furo é uma sessão que a plataforma pode amarrar no predinho errado.

Ferramentas mudam de nome. O critério não. Origem da consulta versus origem do HTTP. Mesma história, ou pare.

O que DNS leak não explica

Não explica criativo reprovado. Não explica pagamento recusado. Não explica ToS. Não explica pixel no domínio errado. Gestor cansado ama um culpado de rede para todo sintoma. DNS leak é específico. Ou o resolvedor denuncia a rede real, ou não.

Também não prova que a conta vai cair amanhã. Sinal barato, não oráculo. A higiene pede para fechar o furo mesmo assim. Operar com HTTP num lugar e DNS noutro é pedir para o grafo ficar feio. Feio não é o mesmo que ban. É risco que você controla.

Não use o teste como teatro para o cliente. “Olha, zeramos o leak” não é SLA de conta. É higiene de perfil. O cliente de tráfego pago compra entrega e isolamento operacional. Não compra um PDF de checker. O PDF fica interno, com data, com o perfil nomeado.

Proxy continua necessário. Qualidade de IP continua necessária. Fingerprint continua necessária. DNS é o eixo que a planilha esquece porque não cabe na fatura do residencial. Cabe no ritual. O proxy sozinho nunca bastou. O teste existe para o time parar de fingir que bastava.