Registros DNS para desenvolvedores — A, CNAME, MX, TXT e o TTL que fez você esperar 48 horas

Você comprou um domínio, apontou para algum lugar e agora está olhando para um navegador que ainda exibe o site antigo. Ou você configurou incorretamente seus registros MX e descobriu que os e-mails começam a rejeitar. O DNS é uma das coisas que os desenvolvedores ignoram na maioria das vezes até que ele os ataca — e quando isso acontece, o ciclo de feedback é lento e doloroso.

Isso não é um tutorial para pessoas que nunca ouviram falar de DNS. É uma referência para desenvolvedores que sabem o que é um domínio, mas sempre recorrem ao Stack Overflow toda vez que precisam adicionar um tipo de registro que não tocaram há seis meses.

Como o DNS realmente funciona (versão de 30 segundos)

Quando um navegador resolve example.com, ele pede a um resolutor recursivo (geralmente seu provedor de internet ou 8.8.8.8). O resolutor verifica seu cache. Se houver um acerto no cache, ele retorna a resposta armazenada. Caso contrário, ele percorre a árvore do DNS — servidores de raiz → servidores de domínio de extensão (.com) → o servidor autoritativo do seu domínio — e armazena o resultado por quanto tempo o TTL indica.

Cada registro DNS tem um tipo, um nome, um valor e um TTL. Isso é tudo. A complexidade vem do conhecimento de qual tipo faz o que e como os registros interagem de maneiras não óbvias.

Os tipos de registro que você realmente usará

Registro A — endereço IP para um nome de host

Mapeia um nome de host para um endereço IPv4. Este é o registro mais comum que você tocará.

example.com.     300   IN  A   93.184.216.34
www.example.com. 300   IN  A   93.184.216.34

O problema: você pode ter múltiplos registros A para o mesmo nome de host. O DNS retornará todos eles, e o cliente escolherá um (geralmente por rotação). Isso é uma configuração simples de balanceamento de carga — mas se um desses IPs parar de funcionar, o DNS não tem verificações de saúde. Ele continuará servindo o IP quebrado até o TTL expirar e você remover o registro.

Para IPv6, a equivalência é um registro AAAA. Mesmo conceito, endereço de 128 bits em vez de 32 bits.

Registro CNAME — alias para outro nome de host

Ponto um nome de host para outro nome de host (não para um IP). O resolutor segue a cadeia até encontrar um registro A.

www.example.com.    300  IN  CNAME  example.com.
blog.example.com.   300  IN  CNAME  mysite.netlify.app.

CNAME vs A — quando usar qual: Se você estiver apontando para um serviço que fornece um nome de host (Netlify, Vercel, GitHub Pages, Heroku, a maioria dos CDNs), use um CNAME. Se você tiver um IP estático, use um registro A. Fácil.

A regra dura: você não pode colocar um CNAME no apex da sua zona (o domínio puro — example.com, e não www.example.com). O RFC 1034 proíbe isso porque o apex precisa conter registros SOA e NS, e um CNAME no mesmo nome causaria conflito. Quando Netlify ou Vercel dizem para adicionar um CNAME para o domínio raiz, o que realmente querem dizer é usar o provedor de DNS que suporta registros ANAME ou ALIAS — uma extensão proprietária que se comporta como um CNAME, mas resolve para registros A no nível da zona.

Também: nunca use um CNAME para um CNAME se você puder evitar. Tecnicamente legal, mas cada salto na cadeia é uma consulta DNS extra. Mais importante, se o CNAME intermediário falhar, seu registro também falhará.

Registro MX — roteamento de e-mails

Informa aos servidores de e-mail para onde os e-mails devem ser entregues para o seu domínio. Os registros MX têm um número de prioridade — número menor = prioridade maior.

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

Se o mail1 estiver indisponível, os servidores de envio tentarão o mail2. Isso é um fallback adequado, não um balanceamento de carga — você não está dividindo o tráfego, você está especificando uma ordem de preferência.

O erro que os desenvolvedores cometem: apontar MX para um endereço IP ou para um CNAME. Os valores do registro MX devem apontar para registros A (nomes de host), não para IPs ou CNAMEs. Alguns provedores de DNS permitem salvar essa configuração incorreta sem aviso, e então seus e-mails falham silenciosamente.

Se você estiver configurando o Google Workspace ou o Microsoft 365, eles fornecerão um conjunto de registros MX. Não modifique os números de prioridade pensando que está sendo inteligente — a lógica de roteamento de e-mails depende deles serem exatos.

Registro TXT — texto arbitrário, principalmente para verificação e autenticação de e-mail

Os registros TXT armazenam strings de texto livre. Na prática, são usados para três coisas:

• Verificação de domínio — o Google Search Console, o Stripe, o GitHub e centenas de outros serviços pedirão para você adicionar um registro TXT para provar que é dono do domínio
• SPF (Framework de Política de Enviante) — especifica quais servidores de e-mail são permitidos para enviar e-mails no nome do domínio
• DKIM e DMARC — registros de autenticação de e-mail que previnem falsificação

Um registro SPF parece assim:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Isso diz: o Google e o SendGrid são permitidos para enviar e-mails para este domínio; qualquer outro deve ser tratado com suspeita (~all = falha suave, -all = falha dura).

Um registro DMARC está em _dmarc.example.com:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

A coisa importante: você pode ter apenas um registro SPF TXT por domínio. Se você adicionar um segundo registro (porque um novo serviço disse que precisava), ambos os registros existirão, os servidores de e-mail verão políticas conflitantes e a autenticação de e-mail quebrará. Mesclá-los em vez disso: v=spf1 include:_spf.google.com include:sendgrid.net ~all.

Registro NS — delegação de servidores de nomes

Especifica quais servidores de nomes são autoritativos para o seu domínio. Você geralmente configura esses registros no seu provedor de domínio, e não diretamente no seu zone DNS. Quando você migra de um provedor de DNS para outro (por exemplo, do GoDaddy para o Cloudflare), você está atualizando os registros NS no nível do provedor de domínio.

A propagação dos registros NS é o que torna as migrações de domínio lentas. Os TTLs dos registros NS são frequentemente de 24 a 48 horas, e as mudanças no provedor de domínio têm seu próprio atraso de propagação sobre isso.

TTL — o número que fez você esperar 48 horas

O TTL (Time To Live) é um número em segundos. Ele diz aos resolutores em cache por quanto tempo lembrar da resposta antes de fazer uma nova consulta. Um TTL de 300 significa cinco minutos. Um TTL de 172800 significa 48 horas.

Quando você altera um registro DNS, a resposta antiga ainda é armazenada em todos os lugares por até o TTL antigo. Se seu registro A tivesse um TTL de 48 horas e você apenas mudasse o IP, alguns usuários irão atingir o servidor antigo por até dois dias — e não há nada que você possa fazer sobre isso após a mudança ser feita.

A solução é reduzir o TTL antes de fazer a mudança. Prática padrão para migrações planejadas:

1. Reduzir o TTL para 300 (5 minutos) pelo menos 48 horas antes da migração — você precisa esperar pelo expirar do TTL antigo primeiro
2. Fazer a mudança no DNS
3. Aguardar 5 a 10 minutos para a propagação
4. Aumentar o TTL de volta para algo razoável (3600 a 86400) assim que você confirmar que a nova configuração está funcionando

Se você esquecer o passo 1 e ir direto ao passo 2 com um TTL alto, ficará preso. Você pode reduzir o TTL agora, mas isso apenas reduz o tempo de espera para os resolutores que ainda não o armazenaram. Quaisquer que já armazenaram o registro precisam esperar pelo TTL original.

Referência rápida

Registro	Aponta para	Uso comum	Ponto importante
A	Endereço IPv4	Nome de host → IP do servidor	Sem verificações de saúde — IPs quebrados permanecem na rotação até o TTL expirar
AAAA	Endereço IPv6	Nome de host → IP do servidor IPv6	Fácil de esquecer de adicionar ao lado do registro A para suporte dual-stack
CNAME	Outro nome de host	Aliases, roteamento de CDN/PaaS	Não pode ser usado no apex da zona; MX/NS não podem apontar para um CNAME
MX	Nome de host (registro A)	Roteamento de entrega de e-mail	O valor deve ser um nome de host, não um IP; os números de prioridade importam
TXT	Texto livre	SPF, DKIM, DMARC, verificação de domínio	Apenas um registro SPF permitido por domínio — mesclá-lo, não adicionar
NS	Nome do servidor de nomes	Delegação do DNS	As mudanças passam pelo registrador e propagam lentamente
CAA	Domínio do CA	Quais CAs podem emitir certificados SSL para o seu domínio	Fácil de bloquear a renovação do certificado por configuração incorreta

Coisas que irão economizar seu tempo

Use o dig diretamente, não por uma ferramenta web. dig @8.8.8.8 example.com A evita seu resolutor local e mostra exatamente o que o Google DNS vê. Adicione +short para apenas a resposta. Adicione +trace para percorrer a cadeia completa de resolução.

# Check what Google sees right now
dig @8.8.8.8 example.com A +short

# Check MX records
dig @8.8.8.8 example.com MX

# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT

# Full resolution trace
dig @8.8.8.8 example.com A +trace

Verifique o TTL antes de qualquer migração. Execute dig example.com A e olhe para o número na terceira coluna da seção de resposta. Isso é quanto tempo (em segundos) você pode esperar se mudar o registro agora sem reduzir o TTL primeiro.

Os registros proxy do Cloudflare não revelam seu IP real. Quando você ativa a nuvem laranja do Cloudflare em um registro, o IP exposto ao mundo é o do Cloudflare, não o seu. Isso geralmente é o que você deseja para proteção contra DDoS — mas isso significa dig não mostrar o IP real do seu servidor, e ferramentas que investigam seu IP diretamente não funcionarão como esperado.

Você também pode gostar