DNS — An Underrated Part of Your Digital Identity

A maioria dos usuários percebe o DNS como um detalhe técnico que funciona em segundo plano. A internet abre, os sites carregam — isso significa que tudo está configurado corretamente. É por isso que muitas pessoas configuram o DNS público do Google (8.8.8.8) ou o Cloudflare (1.1.1.1) uma única vez, ou até mesmo deixam as configurações automáticas recebidas do provedor e nunca mais se preocupam com isso. Essa abordagem é perfeitamente adequada para o uso normal da internet. Mas quando se trata de proxies, navegadores anti-detecção, automação, web scraping ou pesquisa em segurança da informação, o DNS deixa de ser uma configuração secundária. Ele se torna parte da sua identidade online.

Vale lembrar que o DNS é um dos mecanismos mais antigos da internet. Suas bases foram lançadas no início da década de 1980 (os principais RFCs 1034 e 1035 datam de 1987), quando privacidade e prevenção de fraudes eram conceitos desconhecidos. Uma requisição DNS clássica é enviada em texto não criptografado via UDP para a porta 53 — visível tanto para o provedor de internet quanto para qualquer nó intermediário no caminho. Esse "legado" deu origem a problemas modernos e também a tentativas de solucioná-los, como o DNS criptografado. Compreender o contexto nos ajuda a entender por que escolher um resolvedor é mais do que uma mera questão estética.

DNS é mais do que uma lista telefônica

O DNS é frequentemente descrito como a lista telefônica da internet: um nome de domínio é convertido em um endereço IP, após o qual o navegador se conecta ao servidor correto. Essa explicação está correta, mas é uma simplificação excessiva. Hoje, o DNS é usado no balanceamento de carga, na seleção do nó de CDN mais próximo, no roteamento, na garantia de tolerância a falhas e na construção de um perfil estatístico do usuário. Geo-DNS e roteamento baseado em latência são bons exemplos. O mesmo domínio pode retornar endereços IP diferentes dependendo de quem está fazendo a solicitação e de onde ela vem. Um grande site hospedado em uma CDN retornará um servidor de borda quando solicitado por meio de um resolvedor alemão e outro por meio de um americano. Serviços como o AWS Route 53 ou o Cloudflare Load Balancing fazem isso automaticamente: eles definem um TTL muito curto (às vezes de 30 a 60 segundos) nos registros para alternar rapidamente o tráfego e manter a tolerância a falhas. O mesmo mecanismo que torna um domínio "resiliente" transforma o DNS em um sinal em tempo real sobre onde a rede acredita que o cliente está localizado.

Vale a pena mencionar separadamente a Sub-rede do Cliente EDNS (ECS, RFC 7871). Trata-se de uma extensão na qual o resolvedor passa uma porção truncada da sub-rede do cliente para o servidor autoritativo, permitindo que a CDN encontre um nó mais próximo. Pode parecer puramente técnico, mas o significado é simples: seu resolvedor pode comunicar a geografia aproximada da conexão a servidores externos mesmo antes da conexão principal ser estabelecida. Diferentes resolvedores se comportam de maneira diferente nesse aspecto — voltaremos a isso mais adiante.

É por isso que os sistemas antifraude modernos analisam não apenas os endereços IP, mas também como a resolução de nomes foi realizada. A ideia central da proteção moderna é simples: o sistema quase nunca toma uma decisão com base em um único indicador. Ele avalia uma combinação de sinais e gera uma pontuação de risco. Um registro DNS incomum, por si só, não prova nada. Mas quando são adicionadas incompatibilidades de fuso horário (por exemplo, o sistema reporta Europe/Berlin, mas o idioma do navegador é en-US), geografia do IP, impressões digitais do dispositivo (Canvas, WebGL, conjunto de fontes) e características da rede, o perfil começa a parecer menos natural. Cada indicador isoladamente é fraco; a combinação deles tem peso.

Por que o DNS público nem sempre é a melhor escolha

O DNS público do Google e o Cloudflare são excelentes serviços. São rápidos, estáveis ​​e suportam protocolos modernos: DNSSEC, DNS sobre HTTPS e DNS sobre TLS. O Cloudflare, por exemplo, opera como uma rede anycast em centenas de cidades, e testes independentes classificam consistentemente seu resolvedor entre os mais rápidos do mundo. O problema não é a qualidade, mas o contexto de uso.

Uma nuance reveladora é precisamente o comportamento com o ECS. O DNS público do Google envia uma sub-rede de cliente truncada para servidores autoritativos (zerando os bits menos significativos do endereço) para selecionar um nó de CDN com mais precisão. O Cloudflare, no endereço 1.1.1.1, não envia ECS por motivos de privacidade. Nenhum dos dois é "bom" ou "ruim" isoladamente — mas são histórias diferentes. Com o Google, o servidor autoritativo recebe uma indicação sobre sua localização geográfica aproximada; com o Cloudflare, não, mas o roteamento para a CDN pode ser menos preciso. O usuário médio não notará isso. Para alguém que esteja construindo um perfil de rede consistente, este é mais um parâmetro que confirma ou contradiz o restante da legenda.

Existe um argumento mais simples. A maioria dos usuários domésticos não altera seu DNS e utiliza os servidores do seu provedor de internet, que são atribuídos automaticamente via DHCP. Portanto, se o objetivo é parecer um assinante comum de uma rede específica, o DNS do provedor de internet costuma ser uma escolha mais natural do que um servidor público. Servidores públicos como 8.8.8.8 ou 1.1.1.1, nesse sentido, indicam uma configuração deliberada: são escolhidos por entusiastas, administradores e redes corporativas, mas não pelo usuário médio de uma operadora de celular. Isso não torna um DNS público "ruim". Apenas revela uma história ligeiramente diferente sobre a sua conexão.

A consistência é mais importante do que a velocidade.

A palavra "consistência" está sendo cada vez mais usada em ambientes profissionais. Significa que todos os elementos de um perfil de rede são consistentes. Se um endereço IP pertence a uma operadora de telefonia móvel alemã, é razoável esperar um fuso horário alemão (Europa/Berlim), uma configuração regional do sistema em alemão ou inglês e resolução de DNS por meio de uma infraestrutura conectada de forma adequada a essa rede, em vez de por meio de um nó anycast que roteia fisicamente a solicitação para outro continente.

Imagine uma discrepância típica: o endereço IP é de uma operadora de celular alemã, o fuso horário do navegador é Europa/Berlim, mas as solicitações de DNS são enviadas para 8.8.8.8 e, na verdade, acessam a rede através do ponto de presença americano do Google, e o idioma da interface está definido como inglês (EUA). Nenhum desses fatos é alarmante por si só. Mas, juntos, criam um cenário difícil de explicar pelo comportamento normal de um assinante real. Cada desvio individualmente não é crítico, mas cada nova discrepância aumenta a probabilidade de o perfil parecer incomum. A velocidade do resolvedor é quase irrelevante nessa lógica: um ganho de 10 a 20 milissegundos não compensa a perda de consistência.

Uma abordagem prática

A escolha de um servidor DNS não deve começar com a pergunta "qual servidor é o mais rápido?", mas sim com a pergunta "como este sistema deve aparecer para o usuário?". A decisão geralmente se resume ao tipo de proxy.

Para proxies móveis e residenciais (de provedores de internet), o mais natural é que a resolução de nomes ocorra por meio da infraestrutura do respectivo provedor — ou pelo menos por meio de um resolvedor acessível do outro lado do túnel, e não a partir da sua máquina. O princípio fundamental aqui é que a resolução de DNS deve ocorrer através do proxy, e não contorná-lo. Dessa forma, tanto a localização geográfica da requisição quanto a dica ECS (se transmitida) corresponderão ao endereço IP da fonte de tráfego principal.

Para servidores de data center, a consistência interna de toda a configuração é mais importante do que tentar imitar uma conexão de internet residencial. Não surpreenderá ninguém se um data center usar, digamos, o Cloudflare ou seu próprio resolvedor — mas se toda a frota de nós se comportar de maneira uniforme, previsível e sem vazamentos, isso já representa um cenário estável ou, em um bom sentido, "monótono". Não existe uma solução universal: a resposta correta não é determinada pela velocidade nominal, mas pela capacidade de processamento que o sistema deve suportar.

Vazamentos de DNS e navegadores modernos

Um vazamento de DNS geralmente ocorre quando as requisições de DNS seguem um caminho diferente do tráfego principal. Por exemplo, o HTTP passa por um proxy, enquanto o DNS continua sendo enviado diretamente pelo provedor de internet local. Isso resulta em inconsistências adicionais: o site "vê" um IP na conexão, enquanto o servidor DNS autoritativo, ao longo do caminho, vê uma origem completamente diferente da requisição. Uma fonte clássica desses vazamentos é a localização da resolução de nomes ao usar SOCKS5. A diferença é perceptível até mesmo no nível do curl: o esquema socks5:// força o cliente a resolver o domínio localmente (e a requisição ignora o proxy), enquanto socks5h:// passa o nome para o servidor proxy, que o resolve internamente. A lógica é a mesma nos navegadores: no Firefox, isso é controlado pelo parâmetro network.proxy.socks_remote_dns. Se estiver desativado, os domínios são resolvidos localmente, resultando em um vazamento mesmo com um proxy configurado corretamente. Esse pequeno detalhe de configuração muda completamente a origem do "vazamento" de DNS.

A situação se complica pelo fato de os navegadores modernos estarem usando cada vez mais DNS sobre HTTPS. O Firefox foi o primeiro navegador a habilitar o DoH por padrão, em 2020 para usuários nos EUA; o Chrome adicionou o modo DNS Seguro no mesmo ano. O Chrome é cauteloso nesse aspecto: ele não altera seu provedor de DNS, mas apenas atualiza seu resolvedor existente para uma versão criptografada, caso ele suporte DoH. No entanto, isso tem uma desvantagem para quem trabalha com um proxy: se o navegador alternar automaticamente para o endpoint DoH do Cloudflare em vez da sua conexão real, o DNS pode vazar, contornando o túnel, mesmo quando o HTTP é enviado pelo proxy. Por fim, os navegadores não são os únicos com seus próprios mecanismos de resolução de nomes: o Android 9 e versões posteriores suportam DNS Privado (DNS sobre TLS), o Windows 11 suporta DoH em nível de sistema e aplicativos individuais implementam a resolução de nomes de maneiras diferentes. Portanto, hoje em dia, não basta verificar as configurações do sistema operacional; é importante entender como cada aplicativo se comporta individualmente. É importante também não confundir vazamentos de DNS com vazamentos de WebRTC: estes últimos não revelam nomes, mas sim endereços IP locais e públicos via STUN — um canal separado que também deve ser fechado.

A principal conclusão

O combate à fraude mudou significativamente nos últimos anos. Antes, o foco principal era o endereço IP e sua reputação. Hoje, toda a identidade digital do usuário é analisada: navegador, dispositivo, idioma, fuso horário, roteamento, comportamento do resolvedor, vazamentos de DNS e dezenas de outros sinais. Essencialmente, trata-se de um modelo probabilístico que combina características pouco confiáveis ​​em uma única avaliação — e introduzir mais uma discrepância quase sempre custa mais do que os milissegundos ganhos por um resolvedor rápido.

Isso elimina a necessidade de buscar o "DNS perfeito". É muito mais útil pensar no sistema como um todo. Além disso, uma configuração estéril e irrealisticamente limpa pode, às vezes, parecer mais suspeita do que uma configuração padrão: usuários reais não são perfeitos. Uma boa configuração não precisa ser invisível — ela deve parecer lógica e natural, e seus elementos não devem se contradizer. Essa abordagem — consistência em vez de buscar parâmetros individuais "ideais" — geralmente se mostra a mais sustentável a longo prazo: a reputação se constrói com o tempo, e um perfil que permanece coerente envelhece melhor.