DNS e infraestructura
Checklist de propagación DNS al cambiar A, CNAME o MX
TTL, orden de cambios y cómo validar resolvers públicos sin asumir que «ya propagó».
12 min de lectura · Actualizado 2026-07-22
Por qué «ya propagó» es una trampa
DNS no es un switch global instantáneo. Cada resolver (ISP, Google 8.8.8.8, Cloudflare 1.1.1.1, el DNS corporativo del cliente) cachea respuestas según TTL y políticas propias. Tras cambiar un A record, tu laptop puede ver la IP nueva mientras un servidor en Bogotá sigue en la antigua durante horas.
Confundir propagación con fallo de hosting genera rollbacks innecesarios y doble downtime. El sitio «funciona para ti» porque flushiste cache local o usas el DNS del panel; el cliente ve error 522 o certificado viejo porque su resolver aún apunta al origen anterior.
Migraciones de correo (MX), web (A/CNAME) y autenticación (TXT SPF/DKIM) compiten en el mismo apex. Un cambio parcial — MX nuevo pero A viejo — produce síntomas cruzados difíciles de depurar sin checklist sistemático.
Regla operativa: nunca des por cerrada una migración DNS con una sola consulta dig desde tu máquina. Valida múltiples resolvers y tipos de registro.
Preparación 48 horas antes
Inventaria registros actuales: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, verificaciones), SRV si aplica. Exporta zona desde el panel o usa /toolbox/dns-suite. Guarda copia offline para rollback.
Reduce TTL a 300 segundos (5 min) mínimo 24–48 h antes del cutover. TTL alto (86400) mantiene respuestas viejas hasta un día completo aunque cambies el valor en el authoritative DNS.
Prepara destino: servidor web respondiendo en IP/host final, certificado TLS emitido para hostname canónico, buzones de correo creados en proveedor nuevo, SPF/DKIM listos pero MX aún sin cambiar si quieres recepción dual temporal.
Comunica ventana de mantenimiento a equipos internos y clientes críticos. Documenta hora T0 del cambio y responsable de monitorización.
Ejecución del cutover
Orden sugerido en migración full-stack: (1) bajar TTL ya hecho, (2) publicar registros nuevos en paralelo donde sea posible (TXT DKIM nuevo sin quitar viejo), (3) cambiar A/CNAME web, (4) validar HTTPS con /toolbox/web-check, (5) cambiar MX, (6) prueba Mail Tester.
Evita editar apex y subdominios críticos en la misma ventana sin prueba intermedia. Si mueves www a CDN, valida www antes de tocar @ o mail.
Tras publicar, espera al menos 2–3 ciclos de TTL antiguo (si tenías 3600, una hora mínimo de observación intensiva). Con TTL 300, revisa cada 10–15 minutos en /toolbox/dns-propagation durante la primera hora.
No apagues origen viejo hasta confirmar mayoría de resolvers públicos en valor nuevo Y tráfico real estable (logs del servidor nuevo, recepción de correo test).
Validación multi-resolver
/toolbox/dns-propagation consulta resolvers distribuidos (Google US, Cloudflare, OpenDNS, Quad9, regiones varias). Busca convergencia >90% en el valor esperado antes de declarar éxito.
Complementa con consultas manuales: dig @8.8.8.8 A tudominio.com +short, dig @1.1.1.1 MX tudominio.com, dig TXT tudominio.com para SPF. En Windows: Resolve-DnsName en PowerShell.
Valida desde red móvil (4G) distinta a oficina — otro cache ISP. Pide a un colega en otra ciudad que pruebe si el servicio es público.
Para TLS post-migración, /toolbox/web-check confirma certificado, cadena y redirect HTTP→HTTPS en el hostname que resuelve públicamente, no solo en curl local contra IP directa.
Post-cutover y rollback
Cuando estabilidad confirmada 24–48 h, sube TTL a 3600 o 14400 para reducir carga de consultas y mejorar latencia percebida. No subas TTL mientras aún observas stragglers en propagation checker.
Rollback plan: restaurar registros exportados en paso 1, mantener TTL bajo, comunicar. Si el servidor viejo aún está vivo, rollback DNS es minutos; si ya lo destruiste, rollback es imposible — otro motivo para no apagar pronto.
Errores comunes: dos DNS authoritative activos (registrador + Cloudflare sin delegación clara), olvidar AAAA en IPv6 dejando parte de usuarios en origen viejo, borrar TXT de verificación Google al limpiar «registros viejos».
Migraciones complejas (multi-región, zero-downtime blue/green) merecen acompañamiento DevOps. Checklist básico aquí cubre el 80% de cambios en pymes y corporativos medianos.
Ponlo en práctica ahora
Usa las herramientas gratuitas del Toolbox para validar tu configuración en minutos.
¿Necesitas que lo resolvamos contigo?
Un ingeniero de Conecta puede aplicar esto en tu operación: servicio relacionado o conversación directa.