DNS Cloudflare (1.1.1.1): privacidade, DoH/DoT, implantação

Por CaptainDNS
Publicado em 23 de dezembro de 2025

#DNS
#Cloudflare
#1.1.1.1
#Resolvedor DNS
#Privacidade
#DoH
#DoT
#Segurança

Ilustração: 1.1.1.1 (Cloudflare), resolvedor DNS público com opções DoH/DoT/ODoH e foco em privacidade

TL;DR

📢 1.1.1.1 é o DNS público da Cloudflare: fácil de implantar e interessante se você quer um DNS "limpo" em privacidade.
Lembre as 3 variantes úteis: 1.1.1.1 (sem filtragem), 1.1.1.2 (bloqueia malware), 1.1.1.3 (bloqueia malware + conteúdo adulto).
Para evitar escuta e interceptação no último quilômetro, prefira um transporte criptografado (DoT/DoH) ou, se sua ferramenta suportar, ODoH.
Nota ops: prepare uma estratégia de contingência (resolvedor secundário ou cache local); um incidente da Cloudflare em 2025 já mostrou que um DNS público pode parar de responder.

Seu DNS "padrão" (muitas vezes o do ISP via DHCP) raramente é uma escolha deliberada. Ainda assim, o resolvedor DNS vê todos os domínios que suas máquinas tentam acessar e pode impactar desempenho, privacidade, segurança e disponibilidade.

Nesta etapa da nossa série sobre resolvedores públicos, focamos no Cloudflare 1.1.1.1: o que é, o que promete (e o que não pode prometer), como ativar em claro ou criptografado, como testar e como integrar corretamente em PMEs.

Público-alvo: rede doméstica, mas também empresas para sysadmins, DevOps ou CTOs de PMEs que querem uma configuração pragmática, auditável e reversível.

1.1.1.1: do que estamos falando exatamente?

1.1.1.1 é um endereço IP que aponta para um resolvedor DNS recursivo público operado pela Cloudflare. Na prática, configurar seus dispositivos (ou o roteador) para 1.1.1.1 significa:

seus dispositivos enviam as consultas DNS para a Cloudflare (em vez do DNS do ISP),
a Cloudflare responde do cache quando possível,
caso contrário, a Cloudflare resolve recursivamente (raiz → TLD → servidores autoritativos) e devolve a resposta.

A Cloudflare também oferece variantes "prontas para uso":

1.1.1.1 / 1.0.0.1: resolvedor sem filtragem (respostas DNS "brutas").
1.1.1.2 / 1.0.0.2: bloqueio de malware (Cloudflare "Families").
1.1.1.3 / 1.0.0.3: bloqueio de malware + conteúdo adulto (Cloudflare "Families").

Fluxo de resolução DNS com 1.1.1.1: Do53 vs DoT/DoH

Endereços e endpoints Cloudflare para conhecer (memo)

Você vai precisar responder com frequência a duas perguntas:

Quais IPs definir como primário/secundário (IPv4/IPv6)?
Qual endpoint usar se eu quiser criptografar (DoH/DoT)?

Tabela de referência (para copiar nas suas rotinas):

Serviço	Uso	IPv4	IPv6	DoH (HTTPS)	DoT (TLS)
1.1.1.1 (sem filtragem)	Caso geral sem filtragem	`1.1.1.1`, `1.0.0.1`	`2606:4700:4700::1111`, `2606:4700:4700::1001`	`https://cloudflare-dns.com/dns-query`	`one.one.one.one`
Families (malware)	Reduzir o risco "no clique"	`1.1.1.2`, `1.0.0.2`	`2606:4700:4700::1112`, `2606:4700:4700::1002`	`https://security.cloudflare-dns.com/dns-query`	`security.cloudflare-dns.com`
Families (adulto+malware)	Rede "família", convidados, locais públicos	`1.1.1.3`, `1.0.0.3`	`2606:4700:4700::1113`, `2606:4700:4700::1003`	`https://family.cloudflare-dns.com/dns-query`	`family.cloudflare-dns.com`

Pontos operacionais a lembrar:

Do53 (UDP/TCP 53): você coloca IPs (ex.: 1.1.1.1) nas configurações de rede/DHCP.
DoT/DoH: você precisa configurar um cliente compatível (OS, navegador, proxy DNS no roteador, relé DNS local, etc.).
Para DoH, prefira a configuração por hostname (cloudflare-dns.com) em vez de "por IP", para evitar incidentes anycast (falamos disso mais abaixo).

Privacidade: o que o 1.1.1.1 promete (e como ler em operações)

O enquadramento correto: DoT/DoH criptografam o transporte entre o cliente e o resolvedor. Mas o resolvedor continua vendo os domínios solicitados (caso contrário não poderia responder). No fim, você escolhe em quem confiar o seu DNS e como proteger o último quilômetro.

A Cloudflare documenta seus compromissos de privacidade para o resolvedor 1.1.1.1, incluindo:

não vender/compartilhar dados pessoais dos usuários do resolvedor com terceiros e sem uso publicitário,
retenção limitada (logs do resolvedor apagados em ~25 horas),
não armazenamento do IP de origem em "non-volatile storage", com anonimização/truncamento,
amostragem muito baixa de pacotes de rede para troubleshooting/mitigação de DoS,
compartilhamento limitado de dados agregados com a APNIC para pesquisa.

Tradução operacional:

Se você quer evitar principalmente a observação local (Wi-Fi, ISP, rede convidada): ative DoT/DoH.
Se o seu objetivo é "minimizar a pegada no provedor": leia a política de retenção e avalie se prefere um provedor com "logs curtos" (Cloudflare) vs "sem IP" (ex.: Quad9) vs um provedor que guarda logs temporários mais longos (ex.: Google).
Se o seu objetivo é compliance: não misture "DNS público" e "DNS corporativo". Para políticas (categorias, exceções, logs, analytics), você vai preferir DNS gerenciado (Zero Trust / DNS gateway) ou um resolvedor interno.

Do53, DoT, DoH, ODoH: escolhendo o transporte certo

Atalho útil: trocar de resolvedor (1.1.1.1 vs DNS do ISP) não implica automaticamente criptografar o DNS.

Do53 (DNS clássico)

Portas: UDP/53 (principalmente), às vezes TCP/53.
Vantagem: universal, simples (roteador/DHCP).
Limites: legível/interceptável na rede; alguns ambientes reescrevem o DNS.

DoT (DNS-over-TLS)

Porta: TCP/853.
Vantagem: DNS criptografado, frequentemente suportado nativamente no OS (Android "DNS privado", systemd-resolved, alguns roteadores).
Limites: a porta 853 às vezes é filtrada.

DoH (DNS-over-HTTPS)

Porta: HTTPS 443.
Vantagem: mais difícil de bloquear (é HTTPS), bom em redes "hostis".
Limites: no parque, você precisa saber quem faz DoH (navegadores, agentes, proxy DNS...), caso contrário perde o controle do caminho DNS.

ODoH (Oblivious DoH)

Ideia: separar "quem pergunta" (IP de origem) de "o que é perguntado" (nome de domínio) via um proxy.
Vantagem: reduz a capacidade de um único ator de vincular IP ↔ consultas.
Limites: ainda não é um "padrão universal" na empresa; suporte cliente mais raro; trate como opção avançada.

Escolher Do53 / DoT / DoH / ODoH conforme as restrições de rede

Atualidade 2025: a pane global do 1.1.1.1 e a lição a lembrar

Em 14 de julho de 2025, a Cloudflare sofreu uma pane global do seu resolvedor 1.1.1.1 (cerca de 62 minutos). Nesse tipo de incidente, o impacto para os usuários é brutal: "a Internet quebrou", porque nada resolve.

Ponto interessante do post-mortem: o tráfego DoH ficou mais estável, porque muitos clientes DoH usam o nome de domínio cloudflare-dns.com (outra superfície anycast) em vez de resolução DoH "por IP".

A conclusão operacional não é fugir do 1.1.1.1, e sim integrá-lo corretamente:

não depender de um único resolvedor,
adicionar uma estratégia de contingência,
observar e testar regularmente.

Implantação em PMEs: 3 modelos que funcionam (e suas armadilhas)

Modelo 1: Roteador/DHCP (rápido, mas frequentemente em claro)

Objetivo: todo o LAN muda sem tocar cada máquina.

Configure o DNS do LAN em 1.1.1.1 e 1.0.0.1 (e IPv6 se tiver).
Lembre-se: isso costuma ser Do53 (não criptografado) e alguns dispositivos podem contornar (DNS estático, DoH no navegador, VPN).

Modelo 2: Configuração por OS (boa para DoT/DoH nativos)

Casos típicos: laptops em mobilidade, servidores críticos, frota móvel.

Exemplos concretos:

Android 9+ (DoT via "DNS privado"): defina o provedor como one.one.one.one (ou security.cloudflare-dns.com / family.cloudflare-dns.com conforme a necessidade).
Navegadores (DoH): útil em mobilidade, mas atenção: pode contornar o DNS corporativo.

Modelo 3: Relé DNS local (recomendado se você quer criptografar "em todo lugar")

Objetivo: os dispositivos falam com um DNS local (cache + controle), e esse DNS local fala em DoT/DoH com 1.1.1.1.

Vantagens:

criptografia para o exterior,
cache local (menor latência percebida),
ponto de controle único (observabilidade, troubleshooting, failover).

Exemplo mínimo com Unbound em DoT (adapte):

# /etc/unbound/unbound.conf.d/cloudflare-1111.conf
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 1.1.1.1@853#one.one.one.one
  forward-addr: 1.0.0.1@853#one.one.one.one

E nos dispositivos, você aponta para o seu relé DNS (ex.: 10.0.0.53) em vez de apontar diretamente para 1.1.1.1.

Arquitetura recomendada: cache local + contingência

Testar de verdade se você usa 1.1.1.1 e o protocolo correto

Teste 1: Verificar do lado da Cloudflare

A Cloudflare fornece uma página de diagnóstico: abra https://1.1.1.1/help em um dispositivo da rede. Ela indica se você está conectado ao 1.1.1.1 e se está usando DoH/DoT.

Teste 2: Testar uma resolução simples

dig @1.1.1.1 cloudflare.com A +tries=1 +time=2
dig @1.0.0.1 cloudflare.com AAAA +tries=1 +time=2

Teste 3: Testar DoH na linha de comando

curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Plano de ação (pronto para prod)

Inventário: onde o DNS é definido hoje (DHCP, estático, VPN, navegadores, agentes)?
Escolha o objetivo: privacidade do último km (DoT/DoH), filtragem simples (Families) ou controle fino (DNS gateway/solução gerenciada).
Escolha o modelo: roteador/DHCP (rápido), OS (móveis), relé DNS local (robusto).
Ative a criptografia onde importa: pelo menos em dispositivos móveis e/ou via relé DNS.
Planeje contingência: resolvedor secundário, ou no mínimo cache local + failover documentado.
Testes: 1.1.1.1/help, dig e um teste DoH/DoT conforme sua ferramenta.
Observabilidade: monitore taxa de SERVFAIL/NXDOMAIN, latência, timeouts e incidentes.

FAQ

O 1.1.1.1 é realmente mais privado do que o DNS do meu ISP?

Sim, na prática, especialmente se você ativa DoT/DoH: você evita observação e interceptação na rede local e no ISP. Mas então você confia suas consultas à Cloudflare: a questão passa a ser a política de logs e a confiança no provedor.

DoH ou DoT: qual escolher na empresa?

Escolha DoT se você controla a rede (porta 853 permitida) e quer uma implementação "DNS pura". Escolha DoH se você está frequentemente em redes filtrantes (hotéis, Wi-Fi públicos) ou se precisa passar por 443.

DoH no navegador: boa ideia ou armadilha?

Boa ideia em mobilidade (rede não confiável), mas armadilha na empresa: o navegador pode contornar seu DNS interno (split-horizon, domínios internos, políticas). Se você tem DNS corporativo, defina uma política clara (permitir, forçar via proxy DNS ou desativar).

Por que adicionar um DNS secundário se o 1.1.1.1 é anycast?

Porque o anycast não elimina quedas globais, e um incidente de DNS parece uma queda de Internet. O melhor compromisso: cache/relé DNS local + um ou dois resolvedores upstream, e failover documentado.

ODoH é para mim?

Se você já tem uma pilha DNS avançada e uma forte necessidade de dissociar IP ↔ consultas (casos sensíveis), pode valer um POC. Caso contrário, DoT/DoH + uma política de logs clara já traz 80% do benefício com muito menos complexidade.

Baixe as tabelas comparativas

Assistentes conseguem reutilizar os números consultando os ficheiros JSON ou CSV abaixo.

Comparativo de resolvedores DNS públicos (CSV)

Glossário

Resolvedor DNS (recursivo): servidor que resolve um nome de domínio em IP consultando a raiz, os TLDs e os servidores autoritativos, depois coloca em cache.
Do53: DNS clássico em claro sobre UDP/TCP porta 53.
DoT: DNS-over-TLS, DNS criptografado sobre TCP/853.
DoH: DNS-over-HTTPS, DNS criptografado sobre HTTPS/443.
ODoH: Oblivious DoH, variante que adiciona um proxy para dissociar IP de origem e conteúdo da consulta.
Anycast: roteamento que envia o tráfego para o POP "mais próximo" (em termos de roteamento), usado por grandes resolvedores.
NXDOMAIN: resposta DNS que indica que um nome não existe.
SERVFAIL: falha de resolução (upstream indisponível, validação, timeouts, etc.).