DNS é tratado como infraestrutura commodity: você aponta os nameservers, configura um registro A e um MX, e esquece. O que o Cloudflare faz com um registro proxiado quebra essa premissa — o protocolo ainda existe, mas o que acontece quando você ativa o modo proxy muda o que DNS significa na sua arquitetura.
O que muda quando você proxeia um registro
Quando você cria um registro A no Cloudflare e ativa o proxy (o ícone de nuvem laranja), o endereço IP que seus clientes recebem na resposta DNS não é o IP da sua origem. O Cloudflare retorna um de seus próprios IPs — endereços que pertencem à rede anycast da empresa, distribuída em mais de 300 pontos de presença ao redor do mundo.
Toda requisição HTTP e HTTPS que chega àquele domínio entra na rede Cloudflare antes de tocar seu servidor. O TLS é terminado no PoP mais próximo do cliente. O WAF inspeciona a requisição. As regras de rate limiting são aplicadas. O cache é consultado. A mitigação de DDoS atua na borda. Só depois — se a requisição passou por todas essas camadas — ela é encaminhada para sua origem, em uma conexão separada, via rede interna do Cloudflare. O endereço IP real do seu servidor permanece oculto para qualquer cliente externo.
DNS, nesse modelo, é o ponto de entrada para toda a cadeia de segurança e desempenho — não o serviço que antecede ela.
Anycast: por que 300 PoPs importam para latência
A maioria das redes opera com roteamento unicast — cada IP é anunciado a partir de um único local, e o pacote percorre toda a distância até aquele datacenter, independentemente de onde o cliente está.
A rede Cloudflare funciona com anycast: o mesmo bloco de endereços IP é anunciado simultaneamente a partir de cada um dos mais de 300 pontos de presença, via BGP. Quando um cliente recebe um IP Cloudflare na resposta DNS, a infraestrutura de BGP da internet roteia o pacote para o PoP geograficamente mais próximo. O TLS é terminado ali, a poucos milissegundos do cliente. O percurso até sua origem — que pode estar em outra região do mundo — acontece pela rede privada da Cloudflare, com rotas otimizadas entre os PoPs, invisível para o usuário final.
Propagação, TTL e a separação entre autoritativo e recursivo
Dois papéis distintos coexistem na oferta DNS da Cloudflare e confundi-los gera expectativas erradas durante incidentes. O serviço autoritativo — quando você delega seu domínio para os nameservers da Cloudflare — é o que responde com autoridade sobre seus registros. O 1.1.1.1 é um resolver recursivo público, um serviço separado que consulta servidores autoritativos em nome de clientes. Você pode usar os nameservers Cloudflare para seu domínio sem jamais usar o 1.1.1.1, e vice-versa.
Quando você altera um registro no painel do Cloudflare, a mudança se propaga pela rede autoritativa em cerca de 30 segundos — número que impressiona quem vem de provedores que levam horas para atualizar zonas. O problema é que "propagação" no sentido que afeta usuários reais depende de outra camada: os resolvers recursivos.
Resolvers como o 8.8.8.8 do Google e os resolvers dos provedores de internet armazenam respostas em cache pelo TTL do registro. Se o TTL estava em 3600 segundos quando um resolver fez a consulta, ele continuará respondendo com o valor antigo por até uma hora — mesmo que o Cloudflare já sirva o novo registro há 30 segundos. A "propagação completa" para todos os clientes leva exatamente o TTL máximo que estava em vigor no momento da mudança.
O TTL padrão para registros não proxiados no Cloudflare é 300 segundos. Registros proxiados sempre expõem TTL de 300 segundos externamente, independentemente do valor interno — a Cloudflare precisa dessa flexibilidade para gerenciar seus próprios IPs anycast. Antes de qualquer mudança planejada — migração de origem, failover, rotação de IP — o procedimento correto é reduzir o TTL para 60 ou 300 segundos com antecedência, aguardar os resolvers atualizarem o cache, executar a mudança e elevar o TTL depois. Fazer na ordem inversa é conviver com propagação lenta exatamente quando o custo é maior.
CNAME Flattening e o problema do apex
A especificação original de DNS proíbe CNAME no apex do domínio — o próprio exemplo.com sem subdomínio — porque conflita com os registros SOA e NS obrigatórios. Durante anos, isso forçou times a IPs fixos no registro A do domínio raiz, criando atrito com serviços que não garantem IPs estáticos: balanceadores de carga na AWS expõem apenas nomes DNS, não IPs.
O Cloudflare resolve isso com CNAME Flattening. Quando você configura um CNAME para o apex, a Cloudflare resolve o target em tempo real — consultando A e AAAA do destino no momento da requisição — e retorna esses IPs diretamente ao cliente. Do ponto de vista do resolver externo, é um registro A normal.
O que isso exige de quem gerencia produção
Equipes que tratam DNS como configuração estática têm problemas específicos quando operam no Cloudflare. O modo proxy de cada registro — ativado ou desativado — determina se os sistemas de segurança e performance da borda estão no caminho ou não. Um registro A com proxy desativado expõe o IP real da origem, invalida a proteção contra DDoS e remove o WAF do fluxo. Auditar quais registros estão proxiados e quais não estão não é tarefa de implantação inicial; precisa fazer parte do processo de revisão de mudanças.
TTL merece atenção operacional contínua. TTL alto reduz carga sobre o autoritativo e melhora cache nos resolvers, mas aumenta o tempo de recuperação em mudanças de rota. A tolerância ao tempo de propagação costuma ser diferente entre registros críticos como MX e subdomínios de serviços internos — e essa diferença deveria estar explícita nas configurações de zona.
Monitorar propagação ativamente durante mudanças de registro evita surpresas. Ferramentas como o whatsmydns.net mostram o que diferentes resolvers ao redor do mundo estão retornando naquele momento. Quando a mudança foi feita mas usuários ainda relatam falha de acesso, a causa provável é um resolver com cache longo — a resposta é aguardar o TTL expirar, não empilhar outra mudança de registro por cima.
Leia também
- Cloudflare Load Balancing e Geo Steering: quando o DNS vira camada de tráfego inteligente
- DNSSEC com Cloudflare: o que protege, o que não protege e como ativar sem problemas
- Cloudflare Email Routing: receber email no seu domínio — e o que não vem junto
- Migração de DNS para Cloudflare: o checklist que evita três horas de apagão
- DNS proxied vs DNS only: o que muda e quando cada modo faz sentido
- Cloudflare Durable Objects: estado consistente no edge — o que realmente muda