Resolvedores DNS públicos: o que você está de fato escolhendo

Um resolver público é um resolver recursivo que qualquer pessoa pode usar, e trocar para um deles entrega ao operador todo nome que o seu dispositivo consulta. O que separa 1.1.1.1, 8.8.8.8, 9.9.9.9 e 208.67.222.222 é política, não velocidade: o que é registrado e por quanto tempo, quais endereços filtram e como um bloqueio responde, se há validação DNSSEC, se a sua sub-rede é repassada aos servidores autoritativos e quais transportes cifrados são oferecidos. Depois da leitura, você consegue ler as páginas de um operador contra a lista que a RFC 8932 pede que ele publique, escolher por esses critérios e testar cada um com dig e curl.

Ver em Markdown

Um resolver DNS público é um resolver recursivo que qualquer pessoa na internet pode usar; 1.1.1.1, 8.8.8.8, 9.9.9.9 e 208.67.222.222 são os quatro acompanhados aqui. Você encontra um deles quando o roteador, o sistema operacional ou o navegador oferece substituir o resolver que a sua rede entregou pelo Dynamic Host Configuration Protocol (), quase sempre com a promessa de velocidade. O que você escolhe é a parte que vê todo nome que você consulta: o que ela registra e por quanto tempo, se filtra, se valida as DNS Security Extensions (), se conta aos servidores autoritativos onde você está e quais transportes cifrados oferece. Depois da leitura, você consegue ler as páginas do próprio operador contra a lista que a (RFC) 8932 pede que ele publique, escolher por esses critérios e testar cada um com dig e curl.

O que é um resolver público, e o que você entrega a ele

A RFC 9499 define open resolver como "A full-service resolver that accepts and processes queries from any (or nearly any) client", um resolver completo aberto a qualquer cliente, e chama de public resolver os que são abertos de propósito (RFC 9499, seção 6). O stub resolver do seu sistema operacional (seção 6) envia a ele uma query com recursion desired (RD) ligado e recebe a resposta final com recursion available (RA) ligado, flags que o header DNS explica; DNS, lido a partir da resposta abre a série.

O que você entrega é todo nome que o seu dispositivo pergunta: "Recursive resolvers see all the traffic since there is typically no caching before them", o resolver recursivo vê todo o tráfego (RFC 9076, seção 6.1). Trocar move essa visibilidade do provedor de acesso (, internet service provider) para um operador cujas políticas definem a sua privacidade (seção 6.1.1). A cifragem não muda isso: "Use of encrypted transports does not reduce the data available in the recursive resolver", cifrar não reduz o que o resolver vê (seção 6.1.4.1).

A lista para ler uma política é a da RFC 8932: "a DNS recursive operator SHOULD publish a Recursive operator Privacy Statement (RPS)", o operador deve publicar uma declaração de privacidade (RFC 8932, seção 6) dizendo se endereços IP são dado pessoal, o que é retido e por quanto tempo, o que é compartilhado ou correlacionado, se os resultados são filtrados (seção 6.1.1), quais transportes ficam em quais endereços e o que vai aos servidores autoritativos (seção 6.1.2), e "To our knowledge, there are no specific privacy laws for DNS data in any country", nenhum país tem lei específica para dados de DNS (RFC 9076, seção 9).

Endereços e alcance anycast

Operador	IPv4	IPv6	Fonte
Cloudflare	1.1.1.1, 1.0.0.1	2606:4700:4700::1111, 2606:4700:4700::1001	IP addresses
Google	8.8.8.8, 8.8.4.4	endereços em 2001:4860:4860::	FAQ
Quad9	9.9.9.9, 149.112.112.112	2620:fe::fe, 2620:fe::9	Service Addresses and Features
Cisco OpenDNS	208.67.222.222, 208.67.220.220	2620:119:35::35, 2620:119:53::53, da tabela do Umbrella	Set Up OpenDNS; Umbrella, Anycast IP Addresses

Todos são anycast: um endereço anunciado de muitos locais autônomos, cada pacote roteado a um deles (RFC 4786, seção 2). Mais próximo é um fato de roteamento, não de mapa: "The routing system decides which node is used for each request", o roteamento decide o nó (seção 3.1), e proximidade topológica não garante ida e volta mais curta (seção 3.2). Anycast explica o mecanismo, BGP o sistema de roteamento por trás dele.

Teste perguntando qual instância respondeu: uma query na classe CHAOS por id.server. (RFC 4892, seção 2), ou a opção Name Server Identifier (NSID) no registro do (Extension Mechanisms for DNS) (RFC 5001, seção 2.2). A Cloudflare documenta dig +short CHAOS TXT id.server @1.1.1.1 (Cloudflare, Troubleshooting), o Quad9 dig +short ch txt id.server. @9.9.9.9 com a regra "If the answer is anything except resXXX.xxx.rrdns.pch.net, then DNS is being transparently redirected", outra resposta é redirecionamento (Quad9 docs, FAQs); o Google responde dig @dns.google. +nsid com gpdns-<código de aeroporto> (Google, Troubleshooting).

Transportes cifrados oferecidos

DNS over TLS () escuta na porta TCP 853 (RFC 7858, seção 3.1), () mapeia cada query em uma troca HTTP (RFC 8484, seção 1) e DNS over QUIC (DoQ) usa a porta UDP 853 (RFC 9250, seção 4.1.1); Cloudflare e Google também respondem DoH em JSON (JavaScript Object Notation). DoT, DoH e DoQ comparados explica os três; aqui, o que cada operador declara.

Operador	DoT	DoH	DoQ	Fonte
Cloudflare	one.one.one.one ou os endereços, porta 853; TLS 1.2 e 1.3	https://cloudflare-dns.com/dns-query, POST e GET em wire format, GET em JSON	não documentado nas páginas lidas	DNS over TLS; Make API requests
Google	dns.google, porta 853; TLS 1.2 e 1.3	https://dns.google/dns-query (RFC 8484) e https://dns.google/resolve (JSON)	não documentado nas páginas lidas	Secure Transports; DNS-over-TLS
Quad9	dns.quad9.net e as variantes dns10, dns11, dns12; porta 853 ou 8853	https://dns.quad9.net/dns-query e as variantes; e , HTTP/1.1 desligado em 15 de dezembro de 2025	todas as variantes, porta 853, desde março de 2026	Services; FAQs; DoH3 and DoQ
OpenDNS	não documentado nas páginas lidas	não documentado nas páginas lidas	não documentado nas páginas lidas	Set Up OpenDNS

Só o Quad9 documenta DoQ: "For DoQ, use the hostname for the Quad9 service variant you want on port 853", o hostname da variante, porta 853 (Quad9, DoH3 and DoQ). As páginas da OpenDNS lidas em 2026-10-18 e 2026-10-19 não nomeiam endpoint DoT nem DoH; o antigo artigo de suporte sobre DoH redireciona para o Cisco Community. Nas trocas DoH capturadas em 19 de outubro de 2026, dns.quad9.net e cloudflare-dns.com responderam com alt-svc: h3=":443", anunciando HTTP/3; dns.google não enviou esse header. O dig +short txt proto.on.quad9.net. do Quad9 responde com o transporte pelo qual a sua query chegou (Quad9 docs, FAQs).

Validação DNSSEC e a flag ad

Cloudflare: "1.1.1.1 is a DNSSEC-validating resolver", valida DNSSEC (Cloudflare FAQ). Google: "Google Public DNS is a validating, security-aware resolver", um resolver validador, embora "we may temporarily disable validation on the zone until the problem is fixed", possa desligar a validação de uma zona (Google FAQ). Quad9: "DNSSEC validation is enabled on all resolver addresses", validação em todos os endereços (Quad9, Service Addresses and Features); o FAQ ainda diz "two out of three of our services", dois dos três serviços (Quad9 FAQ). OpenDNS: nenhuma declaração nas páginas lidas. Nas trocas capturadas em 19 de outubro de 2026, os outros três responderam www.example.com A com a flag authentic data () ligada e, com o bit DNSSEC OK (DO) ligado, acrescentaram a assinatura de tipo 46.

A flag AD diz menos do que parece. Um resolver validador "MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic", AD só com Answer e Authority inteiramente autênticas (RFC 4035, seção 3.2.3). Para o seu stub ela é só uma dica (RFC 4033, seção 7): um stub "MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel", só pode confiar na validação de um resolver confiável por canal seguro (RFC 4035, seção 4.9.3). Cifragem não prova validação (RFC 8932, seção 5.1.4), e um resolver que não valida na sua lista desfaz o resto, porque o cliente que recebe SERVFAIL pergunta ao próximo (RFC 8914, seção 6). O teste do próprio Google é visitar http://www.dnssec-failed.org/ (Google FAQ). DNSSEC de ponta a ponta monta a cadeia inteira.

Variantes com filtragem e o que elas devolvem

Um resolver que altera respostas é um policy-implementing resolver, que um stub em geral não detecta (RFC 9499, seção 6); alguns marcam o bloqueio com um código Extended DNS Error (EDE) (RFC 8914, seção 6). Por endereço:

Operador e endereço	Filtra	Como um bloqueio responde
Cloudflare 1.1.1.1, 1.0.0.1	nada	sem bloqueio
Cloudflare 1.1.1.2, 1.0.0.2	malware e phishing	registro A 0.0.0.0
Cloudflare 1.1.1.3, 1.0.0.3	malware, phishing e conteúdo adulto	registro A 0.0.0.0
Google 8.8.8.8, 8.8.4.4	nada, exceto casos raros de segurança e ordens judiciais em BE, FR, IN, IT e PT	REFUSED, opcionalmente EDE 16
Quad9 9.9.9.9, 149.112.112.112	ameaças de segurança	NXDOMAIN, AUTHORITY 0, EDE 15, 16 ou 17
Quad9 9.9.9.10, 149.112.112.10	nada	sem bloqueio
Quad9 9.9.9.11, 149.112.112.11	ameaças de segurança; sub-rede do cliente enviada	como 9.9.9.9
Quad9 9.9.9.12, 149.112.112.12	nada; sub-rede do cliente enviada	sem bloqueio
OpenDNS 208.67.222.222, 208.67.220.220	OpenDNS Home ou Public Service	não documentado nas páginas lidas
OpenDNS 208.67.222.123, 208.67.220.123	FamilyShield	não documentado nas páginas lidas

Cloudflare: "Cloudflare does not block or filter any content through the 1.1.1.1 Public DNS Resolver", nada é bloqueado em 1.1.1.1 (Cloudflare, Public DNS Resolver); os endereços 1.1.1.1 for Families respondem bloqueios com 0.0.0.0 (Cloudflare, Set up). Google: "it does not perform blocking or filtering of any kind, except for certain domains in rare cases", não filtra salvo casos raros (Google FAQ); sob ordem judicial em Bélgica, França, Índia, Itália e Portugal "The response returned will have DNS REFUSED, optionally with an extended DNS error 16 (Censored)", REFUSED com EDE 16 (Google, Blocking Behavior). Quad9: só ameaças de segurança, nunca conteúdo, anúncios ou rastreadores (Quad9, Threat blocking); "When you receive an NXDOMAIN with AUTHORITY: 0, that is a block from Quad9", NXDOMAIN com AUTHORITY zero é bloqueio (Quad9 docs, FAQs), marcado com EDE 15, 16 ou 17 (Quad9, Data and Privacy Policy); o 9.9.9.12 aparece só no site de documentação (Quad9 docs, Services). OpenDNS: o OpenDNS Home oferece filtragem configurável e o FamilyShield vem "Preconfigured to block adult content", pré-configurado para bloquear conteúdo adulto (OpenDNS, home or small business). A RFC 8914 define 15 como lista do próprio operador, 16 como exigência externa e 17 como lista pedida pelo cliente (RFC 8914, seções 4.16 a 4.18).

EDNS Client Subnet

O EDNS Client Subnet (), opção de código 8 (RFC 7871, seção 6), repassa parte do seu endereço aos servidores autoritativos para que uma content delivery network () responda com um nó próximo. A RFC pede que ele venha "be turned off by default in all nameserver software", desligado por padrão em todo software (seção 2), porque torna o seu endereço de rede visível a todo servidor da resolução (seção 11.1). O cliente pode recusar: "A SOURCE PREFIX-LENGTH value of 0 means that the Recursive Resolver MUST NOT add the client's address information to its queries", prefixo zero proíbe acrescentar o endereço (seção 7.1.2), o que o dig envia como +subnet=0 (manual do dig, Query Options).

Cloudflare: "It does not send the EDNS Client Subnet (ECS) header", não envia ECS (Cloudflare FAQ). O Google envia "the first 24/56 bits or less for IPv4/IPv6 respectively", até 24 ou 56 bits (Google FAQ), e a sua API JSON o retém com edns_client_subnet=0.0.0.0/0 (Google, JSON API), ecoado na captura de 19 de outubro de 2026. Quad9: "we do not transmit that data in our default service", não transmite no serviço padrão, ao custo de roteamento de CDN menos exato (Quad9 FAQ); 9.9.9.11 e 9.9.9.12 enviam. OpenDNS: nada nas próprias páginas; só a orientação do Google a operadores autoritativos menciona "resolvers that require ECS whitelisting, like OpenDNS", resolvers que exigem allowlist de ECS (Google, ECS Guidelines), uma afirmação sobre terceiro. Se um resolver envia ECS aos servidores autoritativos não é visível do lado do cliente.

Logs e retenção

Operador, documento e data	Endereço IP do cliente	Logs	Compartilhamento
Cloudflare, compromisso de privacidade, última atualização em 27 de março de 2024	truncado (último octeto do IPv4, últimos 80 bits do IPv6) e apagado em 25 horas; nenhum endereço inteiro em armazenamento não volátil, exceto 0,05 % de pacotes amostrados	apagados em 25 horas; dados agregados mantidos indefinidamente	um parceiro de pesquisa, sem endereços de cliente; práticas auditadas por firma de contabilidade
Google, Your Privacy, última atualização em 3 de setembro de 2024	só nos logs temporários, apagados em 24 a 48 horas, mais em casos de abuso	logs permanentes são uma amostra com localização por cidade ou região, número de sistema autônomo e transporte	processos legais; sem anúncios; sem correlação exceto segurança
Quad9, Data and Privacy Policy, versão 1.1, 24 de junho de 2026	não registrado; fica em memória volátil por microssegundos a milissegundos	contadores por prefixo não mais fino que /24 ou /56, região de pelo menos 10.000 pessoas, protocolo, nome consultado; mantidos permanentemente	não compartilhado, vendido nem alugado; contagens e timestamps por domínio malicioso aos parceiros de ameaças
OpenDNS, Cisco Online Privacy Statement, 26 de setembro de 2023	nenhuma declaração específica de DNS	retidos "as needed to fulfill the purposes for which it was collected"	remete às Cisco General Disclosures

Cloudflare: "Cloudflare will delete the Public Resolver Logs within 25 hours", logs apagados em 25 horas (Cloudflare, Public DNS Resolver). Google: "These logs are subject to our deletion processes within 24-48 hours", apagados em 24 a 48 horas (Google, Your Privacy). Quad9: "Quad9 does not collect or record user IP addresses", não coleta nem registra endereços IP (Quad9, Data and Privacy Policy); a responsável é uma fundação suíça sob a lei suíça de dados (Quad9, Compliance and Applicable Law). OpenDNS: o link de privacidade serve a declaração corporativa da Cisco, que não nomeia campo de log de DNS nem prazo (Cisco Online Privacy Statement).

As duas alternativas

O resolver que a sua rede entrega por DHCP vê as mesmas queries, mas pertence a quem você já contratou, e uma rede hoje pode anunciar um resolver cifrado pelas opções DHCP da RFC 9463 (RFC 9463, resumo). O seu próprio resolver validador desloca a exposição em vez de removê-la: "it may decrease privacy against an observer located on an authoritative name server", pode reduzir a privacidade diante do servidor autoritativo (RFC 9076, seção 6.2), porque um resolver com pouquíssimos usuários os expõe (RFC 8932, seção 5.3.2); o meio-termo é encaminhar cifrado a um resolver maior de política compatível (seção 5.3.2). O delv do valida do seu lado com a lógica de validação do named (manual do delv).

O que dá errado

Redirecionamento transparente da porta 53. O Quad9 documenta provedores que desviam para os próprios forwarders as queries a terceiros (Quad9 docs, FAQs); o teste de id.server expõe isso, e o teste TXT do Google abaixo também (Google, Troubleshooting).

Um captive portal. "Current captive portal solutions typically implement some variations of forging DNS or HTTP responses", os portais de hoje forjam respostas DNS ou HTTP (RFC 8952, seção 1); a opção DHCP da RFC 8910 avisa o cliente de que pode haver um portal (RFC 8910, seção 2).

Nomes de split-horizon. Zonas internas vivem só nos servidores da própria rede; o Google avisa que pode cortar domínios privados de um escritório (Google FAQ). Em casa a zona é home.arpa., que um host em outro resolver pode não resolver ou resolver errado (RFC 8375, seção 4).

Geolocalização deslocada sem ECS: um resolver que retém a sua sub-rede é respondido pela localização dele (RFC 7871, seção 5).

O próprio endereço. Em 27 de junho de 2024, 1.1.1.1 ficou inalcançável a partir de mais de 300 redes em 70 países: "The root cause was a mix of (Border Gateway Protocol) hijacking and a ", sequestro BGP mais vazamento de rota (Cloudflare Blog, incidente de junho de 2024). Em 14 de julho de 2025 o endereço ficou fora por 62 minutos por "an internal configuration error and not the result of an attack or a ", um erro interno de configuração, não um ataque (Cloudflare Blog, incidente de julho de 2025); clientes DoH configurados por nome seguiram funcionando (BGP: a queda de confiança conta o resto).

Como ver

Os comandos, com a sintaxe do manual do dig do BIND 9 (manual do dig, Query Options) e como os operadores os publicam:

# Qual instância respondeu (Cloudflare e Quad9 documentam a forma CHAOS; o Google responde NSID)
dig +short CHAOS TXT id.server @1.1.1.1
dig +short ch txt id.server. @9.9.9.9
dig @dns.google. +nsid | grep NSID
# Por qual transporte a sua query chegou (Quad9)
dig +short txt proto.on.quad9.net.
# DNSSEC: peça as assinaturas e leia ad nas flags; +cd desliga a validação
dig +dnssec @9.9.9.9 example.com
# Retenha a sua sub-rede
dig +subnet=0 @8.8.8.8 example.com
# DoT e DoH com o próprio dig
dig +tls @1.1.1.1 example.com
dig @dns.google +https example.com
# Teste de alcance do Google: NXDOMAIN significa que outro resolver respondeu, timeout significa porta 53 bloqueada
dig -t TXT test.dns.google.com. '@dns.google.'
# DoH à mão (exemplo da própria Cloudflare)
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=cloudflare.com&type=AAAA'

Uma troca real capturada em 19 de outubro de 2026 às 03:19:46 Greenwich Mean Time (GMT), o endpoint JSON da Cloudflare perguntado por www.example.com A, endereços omitidos:

HTTP/2 200
"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false
Answer: dois registros A, TTL 144

O filtro aparece num nome que o Quad9 bloqueia. A mesma query em wire format, ID 0 como a RFC 8484 recomenda, pelo nome de teste da própria documentação do Quad9, em dns.quad9.net e dns10.quad9.net em 19 de outubro de 2026:

dns.quad9.net    flags=0x8123 QR=1 RD=1 RA=0 AD=1 RCODE=3 (NXDOMAIN)  QD 1 AN 0 NS 0 AR 1
                 OPT options=[EDE code 17 text '']
dns10.quad9.net  flags=0x8180 QR=1 RD=1 RA=1 AD=0 RCODE=0 (NOERROR)   QD 1 AN 1 NS 0 AR 1

NXDOMAIN sem registro de autoridade e com EDE 17 é a assinatura de bloqueio que o Quad9 documenta; a variante sem filtro devolveu o endereço. No navegador, o teste da Cloudflare é 1.1.1.1/help (Cloudflare FAQ) e o do Quad9 é on.quad9.net (Quad9 docs, FAQs). O construtor de comando dig monta qualquer comando acima e resume o que a query vai carregar (transporte, porta, RD, DO, checking disabled (CD), EDNS); o explicador de saída do dig decodifica uma resposta colada e avisa quando DO foi pedido mas AD não veio; o construtor de comando curl escreve o pedido DoH; o explicador de saída do nslookup lê o nslookup -class=chaos -type=txt id.server 1.1.1.1 da Cloudflare para Windows; o Python playground empacota o header de 12 bytes com struct, como as queries capturadas foram montadas. A saída do dig e Anatomia de uma linha de comando dig cobrem saída e sintaxe.

Para lembrar

Um resolver público é um open resolver aberto de propósito (RFC 9499, seção 6); ele vê todo nome que você consulta, cifrado ou não.
Compare pela lista da RFC 8932, na página datada de cada operador: tratamento de IP, retenção, compartilhamento, filtragem, transportes, o que vai aos servidores autoritativos.
A filtragem é por endereço: Cloudflare 1.1.1.2 e 1.1.1.3 bloqueiam com 0.0.0.0; Google só casos de segurança e ordens judiciais em cinco países, REFUSED com EDE 16; Quad9 9.9.9.9 NXDOMAIN com AUTHORITY 0 e EDE 15 a 17; OpenDNS 208.67.222.123 e 208.67.220.123 são o FamilyShield.
Cloudflare, Google e Quad9 declaram validação DNSSEC; a flag ad não vale nada sem um resolver confiável por um caminho seguro (RFC 4035, seção 4.9.3), e um resolver que não valida na lista desfaz tudo.
ECS: o Google envia até 24 ou 56 bits, a Cloudflare nada, o Quad9 nada exceto em 9.9.9.11 e 9.9.9.12; +subnet=0 retém; a política da OpenDNS só é afirmada por terceiro.
Retenção como declarada: Cloudflare 25 horas; Google 24 a 48 horas mais um log permanente amostrado; Quad9 nenhum endereço; a OpenDNS não dá número para DNS.
id.server ou NSID diz qual instância anycast respondeu, e resposta errada é porta 53 redirecionada; nomes internos, home.arpa e captive portals quebram quando você troca.

Resolvedores DNS públicos: o que você está de fato escolhendo

O que é um resolver público, e o que você entrega a ele

Endereços e alcance anycast

Transportes cifrados oferecidos

Validação DNSSEC e a flag ad

Variantes com filtragem e o que elas devolvem

EDNS Client Subnet

Logs e retenção

As duas alternativas

O que dá errado

Como ver

Para lembrar

Fontes