Migração de DNS para Cloudflare: o checklist que evita três horas de apagão

A migração de DNS para o Cloudflare tem a reputação de ser trivial: importe a zona, aponte os nameservers, aguarde a propagação. Os times que ficam três horas em apagão seguiram exatamente esse roteiro. O problema é que "trivial" descreve o caso perfeito, e produção raramente é perfeita.

O que a importação automática não faz por você

Quando você adiciona um domínio ao Cloudflare, a plataforma consulta os servidores autoritativos do provedor atual e tenta importar todos os registros da zona. O resultado é uma lista de registros que parece completa — e quase sempre está. O "quase" é onde mora o risco.

Registros do tipo TLSA, usados para DANE (autenticação de entidades denominadas por DNS), frequentemente não são importados. O mesmo acontece com alguns registros SRV com configurações fora do padrão, registros CAA com múltiplos flags ou values incomuns, e qualquer registro que o provedor anterior sirva via resposta não-padrão. A importação do Cloudflare é um ponto de partida, não uma garantia de fidelidade.

O protocolo correto é: após a importação, exportar a zona do provedor atual no formato BIND (a maioria dos provedores oferece isso) e comparar manualmente os dois conjuntos de registros. Ferramentas como diff contra o arquivo de zona exportado revelam o que a importação perdeu. Esse passo toma vinte minutos e evita descobrir, após a virada dos nameservers, que o certificado de e-mail parou de validar porque um registro TLSA sumiu.

O proxy do Cloudflare e os serviços que não são HTTP

O Cloudflare opera em dois modos para cada registro A ou AAAA: proxied (o tráfego passa pela rede da Cloudflare, o IP real fica escondido) e DNS-only (resolução pura, sem intermediação). Registros MX importados ficam como DNS-only por padrão, o que é correto, porque SMTP não passa pelo proxy do Cloudflare.

O problema aparece com registros A que apontam para servidores de e-mail ou para qualquer serviço que não seja HTTP/HTTPS. Um registro A chamado mail.exemplo.com que aponta para o servidor SMTP pode ser proxied por acidente durante a configuração, especialmente se alguém estiver revisando os registros e ativando o proxy em lote. O resultado é que o servidor de e-mail passa a expor os IPs da Cloudflare em vez do IP real, e conexões SMTP externas chegam a um proxy que não sabe o que fazer com elas. O erro não é imediato — alguns clientes de e-mail tentam novamente, o timeout leva minutos, e o problema parece intermitente antes de se tornar consistente.

O mesmo acontece com bancos de dados expostos via DNS. Um registro A que resolve para um servidor MySQL ou PostgreSQL atrás do proxy retorna o IP do Cloudflare. A aplicação tenta conectar na porta 3306 ou 5432, o proxy recusa (não suporta essas portas por padrão), e a conexão falha com timeout. O serviço parece caído, mas o DNS está "funcionando" — está só apontando para o lugar errado.

Antes de virar os nameservers, revise cada registro A e AAAA e confirme o modo correto. A regra é direta: se o serviço naquele endereço não responde exclusivamente em HTTP/HTTPS nas portas 80 e 443, o modo deve ser DNS-only.

TTL e a janela de propagação

A propagação de nameservers não é instantânea, e o TTL dos registros no provedor atual determina quanto tempo leva para resolvers ao redor do mundo descartarem o cache antigo. Se os seus registros estão com TTL de 86400 segundos (24 horas) — o padrão de muitos provedores — e você vira os nameservers agora, parte dos resolvers vai continuar servindo os registros antigos por até 24 horas, independente do que o Cloudflare já diz.

A estratégia correta começa dois dias antes da migração. Baixe o TTL de todos os registros críticos para 300 segundos (cinco minutos) no provedor atual. Aguarde o tempo equivalente ao TTL original: se os registros estavam a 3600 segundos, espere uma hora; se estavam a 86400, espere 24 horas. Só então vire os nameservers. Com isso, quando a virada acontece, os caches ao redor do mundo expiram em no máximo cinco minutos, e qualquer problema que aparecer durante a migração é resolvido com rapidez — você não fica preso esperando caches de 24 horas expirarem enquanto o incidente corre.

Esse passo é o mais frequentemente ignorado porque exige planejamento antecipado. Quem chega na véspera da migração e percebe que os TTLs estão em 86400 tem duas opções: baixar o TTL e esperar 24 horas antes de prosseguir, ou aceitar o risco de uma janela de propagação longa. A segunda opção é o caminho mais comum para um apagão que dura mais do que deveria.

DNSSEC: o detalhe que transforma propagação em falha de validação

Se o domínio tem DNSSEC ativo no provedor atual, migrar os nameservers sem tratar os registros DS no registrador causa falha de validação em todos os resolvers que verificam DNSSEC. O resolver recebe o aviso de que o domínio usa DNSSEC (via registro DS no registrador), consulta o Cloudflare, recebe assinaturas assinadas com as chaves do Cloudflare, e rejeita a resposta porque as chaves não batem com o DS que ainda aponta para o provedor anterior.

A sequência correta tem quatro etapas com janelas de espera entre elas. Primeiro, remova os registros DS do registrador (não no provedor de DNS, no registrador onde o domínio está registrado). Segundo, aguarde o TTL dos registros DS expirar — geralmente entre uma e quatro horas, dependendo do registrador. Terceiro, vire os nameservers para o Cloudflare. Quarto, ative o DNSSEC dentro do painel do Cloudflare e adicione os novos registros DS que a plataforma fornece ao registrador. Pular o período de espera entre o primeiro e o terceiro passo é a causa mais comum de incidentes de DNSSEC em migrações.

Como estruturar a migração para não improvisar sob pressão

A diferença entre uma migração que termina em trinta minutos e uma que vira incidente de três horas é quase sempre organizacional. Times que executam bem definem antecipadamente quem valida cada etapa, o que configura rollback, e qual é o critério de sucesso antes de declarar a migração concluída.

A sequência operacional que funciona começa com a comparação de zonas entre o provedor atual e o Cloudflare, feita antes de qualquer virada. Domínios com SPF, DKIM e DMARC exigem atenção especial: os registros TXT podem ter aspas ou concatenações que a importação automática reformata, quebrando a validação mesmo que o conteúdo pareça correto. Registros SRV para serviços como SIP, XMPP ou Minecraft precisam de verificação manual do campo de prioridade e peso.

Após a virada dos nameservers, o protocolo de verificação tem três comandos que devem rodar em sequência. O comando dig @1.1.1.1 +short exemplo.com NS confirma que o Cloudflare já é autoritativo para o domínio naquele resolver. O comando dig @8.8.8.8 +short mail.exemplo.com A verifica que o registro de e-mail retorna o IP real do servidor, não um IP da Cloudflare. Um teste de envio de e-mail a partir de um endereço externo dentro dos primeiros trinta minutos após a virada fecha o ciclo de verificação básico.