O que é Propagação de DNS?
A propagação de DNS é o período durante o qual uma alteração publicada por um servidor de nomes autoritativo se torna visível por meio de outros servidores autoritativos, resolvedores recursivos e caches locais. O servidor de nomes que publica a alteração pode fornecer o novo registro assim que a publicação é concluída, enquanto outros servidores autoritativos ainda podem estar se atualizando e os resolvedores recursivos podem retornar uma resposta mais antiga armazenada em cache. Os valores de TTL orientam a duração do cache, mas o comportamento dos resolvedores pode variar, portanto, respostas antigas podem, às vezes, persistir além do TTL nominal.
Entendendo "Propagação"
O termo "propagação" é um pouco enganoso — mudanças de DNS não "se propagam" ou se espalham ativamente. Em vez disso:
1. Você atualiza registros no servidor de nomes autoritativo
2. Cópias em cache expiram com base no TTL (Time To Live)
3. Novas consultas buscam registros atualizados dos servidores autoritativos
4. Cópias em cache antigas continuam servindo até TTL expirar
É mais preciso dizer "expiração de cache de DNS" do que "propagação", mas o termo propagação é amplamente usado.
Como Funcionam Mudanças de DNS
O Processo de Atualização
Step 1: Update DNS records
example.com A record: 203.0.113.50 → 203.0.113.51
Step 2: Authoritative nameserver immediately serves new record
Step 3: Existing cached copies remain valid until TTL expires
Step 4: New queries after TTL expiration receive updated record
Step 5: All caches eventually expire and refresh
→ "Propagation complete"
Exemplo de Linha do Tempo
Time: 10:00 - DNS updated (TTL: 300s / 5 minutes)
Resolver A (cached at 09:58):
09:58 - Cached old IP, expires 10:03
10:03 - Cache expires, queries again, gets new IP
Resolver B (cached at 10:01):
10:01 - Cached old IP, expires 10:06
10:06 - Cache expires, queries again, gets new IP
Resolver C (queries at 10:05):
10:05 - No cache, queries immediately, gets new IP
All resolvers have new IP by: 10:06
Propagation time: 6 minutes (worst case based on TTL)
Fatores que afetam o tempo de propagação
TTL (tempo de vida, Time To Live)
O fator mais importante:
| Valor de TTL | Tempo de Propagação | Caso de Uso |
|---|---|---|
| 60s | 1-2 minutos | Migrações ativas, balanceamento de carga |
| 300s (5 min) | 5-10 minutos | Mudanças em produção, padrão razoável |
| 3.600s (1 hora) | 1-2 horas | Infraestrutura estável |
| 86.400s (24 horas) | 24-48 horas | Registros raramente alterados |
Mudanças de Nameserver
Mudar nameservers leva mais tempo que outras mudanças de DNS:
Registry Level: 24-48 hours (TLD nameserver cache)
Resolver Level: Based on NS record TTL
Total Time: Up to 48 hours worst case
Comportamento de ISP e Resolvedor
Nem todos os resolvedores de DNS respeitam valores de TTL:
Resolvedores Bem-Comportados: Google (8.8.8.8), Cloudflare (1.1.1.1), OpenDNS- Respeitam rigorosamente TTL
- Propagação rápida
- Podem ignorar TTLs baixos
- Cache mais tempo que especificado
- Pode atrasar propagação em horas
Distribuição Geográfica
Diferentes regiões atualizam em momentos diferentes com base em cache de resolvedor local:
North America: 10:05 - Updated
Europe: 10:08 - Updated
Asia: 10:12 - Updated
Cache do Lado do Cliente
Mesmo após atualizações de servidores DNS, caches locais podem reter valores antigos:
- Cache do navegador: Típicamente 60 segundos
- Cache do SO: Minutos para horas
- Cache da aplicação: Varia por aplicação
Verificando Propagação de DNS
Verificadores de Propagação Online
whatsmydns.net: Mostra resolução de DNS de 20+ locais em todo o mundo dnschecker.org: Verifica registros A, AAAA, CNAME, MX, TXT globalmente Verificação de Saúde DomScan:curl "https://domscan.net/v1/health?domain=example.com"
# Shows current DNS configuration
Verificações de Linha de Comando
Verificar múltiplos resolvedores:# Google DNS
dig @8.8.8.8 example.com
# Cloudflare DNS
dig @1.1.1.1 example.com
# Your ISP (no @ server specified)
dig example.com
# Compare results
Consultar servidor de nomes autoritativo diretamente:
# Find nameservers
dig example.com NS
# Query authoritative NS directly
dig @ns1.example.com example.com
Isso mostra a "verdade" imediatamente — sem cache envolvido.
Verificar em Múltiplos Locais
# Using curl with DNS over HTTPS
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
Minimizando Tempo de Propagação
Antes de Fazer Mudanças
Etapa 1: Reduzir TTL (24-48 horas antes da mudança)Old: example.com. 3600 IN A 203.0.113.50
New: example.com. 300 IN A 203.0.113.50
^^^
Reduced to 5 minutes
Etapa 2: Aguardar TTL antigo expirar
Aguardar duração completa do TTL antigo (3.600s = 1 hora)
Etapa 3: Fazer mudança de DNSexample.com. 300 IN A 203.0.113.51
Etapa 4: Monitorar propagação
Verificar resolvedores globalmente
Etapa 5: Restaurar TTL (após confirmar sucesso)example.com. 3600 IN A 203.0.113.51
Durante Mudanças
Use DNS anycast: Provedores como Cloudflare usam redes anycast que atualizam quase instantaneamente em toda a rede global Monitore continuamente: Rastreie propagação entre regiões-chave e resolvedores Tenha plano de reversão: Mantenha infraestrutura antiga funcionando até propagação completaCenários Comuns de Propagação
Mudando Registro A
Tempo Esperado: 5-30 minutos (com base em TTL)# Before
example.com → 203.0.113.50
# After
example.com → 203.0.113.51
# Propagation: 1x TTL duration
Mudando Registro MX
Tempo Esperado: 5-30 minutos (com base em TTL) Risco: Email pode ser entregue ao servidor antigo durante propagação Mitigação: Manter servidor de mail antigo ativo por 24-48 horasMudando Nameservers
Tempo Esperado: 24-48 horasWhy so long?
- TLD registry caches NS records
- Registry TTL often 24-48 hours
- No control over registry cache
Melhor Prática: Configurar todos os registros no novo nameserver antes de mudar
Adicionando Novo Subdomínio
Tempo Esperado: Instantâneo para 1 hora Armadilha: Cache negativoIf subdomain was queried and didn't exist:
→ NXDOMAIN cached (SOA minimum TTL)
→ New subdomain won't resolve until cache expires
Mitigação: Reduzir TTL mínimo de SOA antes de adicionar novos registros
Solucionando Problemas de Propagação
Mudança Não se Propaga
Verificação 1: Verificar servidor de nomes autoritativodig @ns1.example.com example.com
# Should show new value
Verificação 2: Verificar TTL
dig example.com | grep -i ttl
Verificação 3: Verificar SOA para cache negativo
dig example.com SOA
# Look at minimum TTL field
Verificação 4: Limpar cache local
Limpar caches de navegador, SO e aplicação
Propagação Parcial
Sintoma: Alguns usuários veem novos registros, outros veem antigos Causa: Diferentes resolvedores em cache em momentos diferentes Solução: Aguardar duração máxima de TTL, depois limpar caches de clientePropagação Presa
Sintoma: Dias depois, alguns resolvedores ainda servem registros antigos Causa: Resolvedor de ISP ignorando TTL ou mal configurado Solução:1. Verificar servidor de nomes autoritativo está correto
2. Contatar ISP se persistente
3. Usuários podem mudar para DNS público (8.8.8.8, 1.1.1.1)
Propagação de DNS vs TTL de Cache
| Conceito | O que É | Duração |
|---|---|---|
| TTL | Quanto tempo um registro pode ser em cache | Definido pelo proprietário do domínio |
| Propagação | Tempo para todos os caches expirarem | Aproximadamente 2x TTL |
| TTL de Nameserver | Quanto tempo registros NS são em cache | Frequentemente 24-48 horas (registro) |
| Cache Negativo | Quanto tempo NXDOMAIN é em cache | TTL mínimo de SOA |
Melhores Práticas
1. Reduzir TTL antes de mudanças: Reduzir 24-48 horas antes de atualizações de DNS
2. Usar TTLs apropriados: Equilibrar desempenho (TTL alto) vs flexibilidade (TTL baixo)
3. Monitorar globalmente: Verificar DNS de múltiplas regiões geográficas
4. Manter serviços antigos funcionando: Manter servidores anteriores ativos até propagação completa
5. Documentar mudanças: Rastrear o que mudou e quando para solução de problemas
6. Testar completamente: Verificar que novos registros de DNS funcionam antes de mudar
7. Comunicar com usuários: Avisar sobre possíveis breves interrupções
8. Usar DNS gerenciado: Provedores com redes anycast minimizam tempo de propagação
9. Automatizar monitoramento: Configurar alertas para mudanças de DNS e status de propagação
10. Ter plano de reversão: Saber como reverter mudanças se problemas surgirem
Checklist de Propagação
☐ Lower TTL 24-48 hours before change
☐ Wait for old TTL to expire
☐ Make DNS change
☐ Verify on authoritative nameservers
☐ Check multiple public resolvers
☐ Test from multiple geographic locations
☐ Monitor for 2x TTL duration
☐ Verify no errors reported
☐ Restore higher TTL if desired
☐ Document change completion
A propagação de DNS é uma consequência natural do cache. Compreender o TTL e planejar as alterações com antecedência ajuda a obter atualizações suaves e previsíveis, com o mínimo de interrupção.