Cómo auditar registros DNS antes de migrar un dominio

En pocas palabras: Antes de migrar un dominio hay que auditar SOA, NS, A, AAAA, CNAME, MX, TXT y CAA, y bajar el TTL a 300 segundos entre 24 y 48 horas antes del cutover: un AAAA residual puede desviar hasta el 40% del tráfico móvil al servidor viejo.

Si vas a migrar un dominio o cambiar de servidor, la mayoría de las caídas no pasan por el código: pasan porque nadie auditó los registros DNS completos antes de tocar la zona. Según el workflow documentado en esta guía técnica publicada en dev.to, un AAAA que quedó sin actualizar puede seguir derivando hasta un 40% del tráfico móvil hacia el servidor viejo, y un CAA mal configurado puede bloquear la emisión del certificado SSL nuevo, dejando a buena parte de los visitantes frente a una pantalla TLS rota.

La idea de fondo no es compleja, pero sí tediosa: antes de cambiar la IP o las nameservers hay que mirar cada tipo de registro de la zona, no solo el A apex. El problema casi nunca es “el dominio no resuelve”, sino “el dominio resuelve distinto según a quién le preguntes”, porque cada resolver tiene en caché una versión diferente de la zona vieja.

¿Por qué fallan las migraciones de dominio aunque el código esté bien?

Fallan porque el inventario DNS está incompleto, no porque el deploy esté mal. Un dominio que lleva un año en producción acumula registros que nadie documentó en ningún lado: subdominios de mail transaccional, CNAME de status pages, entradas de CDN y verificaciones de Google Search Console o Stripe metidas en algún TXT que alguien agregó hace dos años y se olvidó.

Cuando un equipo actualiza el A record y da por terminada la migración, se olvida de todo lo demás. El resultado es tráfico split-brain: una parte de los visitantes llega al servidor nuevo y otra sigue golpeando el viejo, dependiendo de qué registro consultó su resolver en ese momento puntual. Es la clase de falla que no aparece en ningún log claro, sino como quejas sueltas de usuarios a los que “a veces les anda y a veces no”.

¿Qué registros DNS hay que auditar antes del cutover?

Hay que auditar ocho tipos de registro antes de tocar producción: SOA, NS, A, AAAA, CNAME, MX, TXT y CAA. Cada uno tiene un modo de falla típico en una migración, y la mayoría no se nota hasta que el cutover ya está en marcha. Sobre eso hablamos en cómo funcionan los servidores DNS autoritativos.

Registro	Qué controla	Falla típica en migración
SOA	Serial de zona, nameserver primario, TTL de caché negativa	Cambiar nameservers con TTL negativo alto cachea NXDOMAIN en subdominios nuevos
NS	Nameservers autoritativos del dominio	Seguir editando el panel DNS viejo después de cambiar el glue record en el registrador
A (IPv4)	Mapea el apex o subdominio a una IP v4	TTL alto (3600-86400s) mantiene a los resolvers del ISP pegados a la IP vieja por horas
AAAA (IPv6)	Mapea el apex o subdominio a una IP v6	Actualizar solo el A y dejar el AAAA viejo manda tráfico móvil al host viejo
CNAME	Alias de subdominios (www, selectores DKIM)	Borrar CNAME de DKIM o romper el redirect de www al importar la zona
MX	Enrutamiento de correo entrante	El auto-import de un proveedor nuevo sobrescribe Google Workspace con mail default de cPanel
TXT	SPF, DMARC, DKIM, verificaciones de Google y Stripe	Sacar la IP vieja del SPF o borrar strings de verificación por accidente
CAA	Qué CA puede emitir SSL para el dominio	Un CAA viejo bloquea Let’s Encrypt o Cloudflare Universal SSL en el host nuevo

¿Cuándo conviene una auditoría completa y cuándo alcanza con lo básico?

No todas las migraciones pesan igual, y tratarlas todas con el mismo nivel de paranoia es un desperdicio de tiempo en algunos casos y un riesgo serio en otros. Antes de decidir cuánto esfuerzo meterle a la auditoría, conviene mirar tres cosas de tu dominio actual:

• Antigüedad del dominio: si tiene más de un año en producción, es casi seguro que acumuló registros que nadie recuerda por qué están. Un dominio de pocas semanas, en cambio, suele tener una zona chica y predecible.
• Cantidad de servicios conectados por TXT o CNAME: cada integración de terceros (pasarela de pago, CRM, herramienta de analítica, verificación de dominio) suele dejar un registro propio. Si acumulás varias entradas TXT distintas de integraciones separadas, ya estás en terreno de auditoría completa.
• Dependencia de correo transaccional: si la aplicación manda mails desde el propio servidor (reset de contraseña, confirmaciones de compra), el SPF y el DKIM pasan a ser tan críticos como el A record. Si solo usás Workspace o Microsoft 365 sin relay propio, el riesgo de email es menor.

Ejemplo hipotético (situación ilustrativa, no un caso real): pensemos en una tienda online que factura por e-commerce propio y manda confirmaciones de pedido desde su propio servidor, con un dominio que tiene cuatro años de antigüedad. Ahí la auditoría completa no es opcional: hay que revisar SPF con la IP del servidor saliente, confirmar que no quede un AAAA apuntando al host viejo, y verificar el CAA antes de pedir el certificado nuevo. Si en cambio se tratara de un sitio institucional chico, armado hace tres meses, sin mail transaccional propio y con DNS en un solo proveedor, probablemente alcance con chequear A, AAAA y CAA, sin necesidad de pasar por todo el checklist de email.

¿Cómo exportar y verificar la zona DNS actual con dig?

Se exporta el zone file BIND completo del proveedor actual (Cloudflare, Route 53, DigitalOcean) y se consulta directo al nameserver autoritativo, no al resolver local, para ver los valores reales sin caché de por medio.

El primer paso es confirmar quién responde hoy: dig +short NS example.com y dig +short SOA example.com. Después se guarda el primer nameserver en una variable y se consulta directo, así nadie se confunde con lo que devuelve el resolver de su propia red:

• Consultá NS y SOA primero: confirma qué nameservers están respondiendo en este momento, antes de tocar nada.
• Guardá el nameserver autoritativo en una variable: AUTH_NS=$(dig +short NS example.com | head -n 1).
• Consultá A, AAAA, MX, TXT y CAA directo contra ese nameserver: dig @${AUTH_NS} +noall +answer example.com A example.com AAAA example.com MX example.com TXT example.com CAA, así evitás que la caché de tu propio ISP te muestre un resultado viejo.

¿Cuándo hay que bajar el TTL antes de migrar?

Hay que bajar el TTL a 300 segundos entre 24 y 48 horas antes de la ventana de mantenimiento, nunca en el mismo momento que cambiás la IP. El orden es lo único que importa acá: primero el TTL bajo, después esperar que el TTL viejo termine de expirar, y recién ahí mover la IP. Cubrimos ese tema en detalle en otras migraciones que requieren planificación cuidadosa.

Ponele que tu registro @ tiene TTL de 86400 segundos (24 horas) y lo bajás a 300 al mismo tiempo que cambiás la IP. Ese resolver que consultó cinco minutos antes va a seguir devolviendo la IP vieja durante casi 24 horas, aunque tu zona ya tenga el valor correcto. El error no es técnico, es de secuencia: bajar el TTL no tiene efecto retroactivo sobre lo que ya está cacheado.

Para verificar el TTL activo en cualquier momento, dig +noall +answer example.com A muestra en la segunda columna los segundos que quedan en caché.

¿Qué registro CAA puede bloquear el certificado SSL del nuevo servidor?

Un registro CAA actúa como lista blanca de autoridades certificantes: si existe y no incluye a tu CA nueva, la emisión del certificado falla sin aviso previo. El ejemplo típico es un CAA heredado tipo 0 issue "sectigo.com", que bloquea cualquier intento de emitir con Let’s Encrypt en el servidor nuevo.

Lo incómodo de este fallo es el momento en que aparece: justo cuando el sitio ya está apuntando a la IP nueva y necesitás que el certificado se emita sin fricción. Por eso conviene correr dig +short CAA example.com antes de migrar, y si aparece algo, agregar 0 issue "letsencrypt.org" (y 0 issuewild "letsencrypt.org" si usás wildcard). Una vez instalado el certificado, se puede probar el host nuevo sin tocar DNS todavía usando curl -Iv --resolve example.com:443:203.0.113.50 https://example.com/. Tema relacionado: migrar una base de datos sin tiempo de inactividad.

¿Cómo evitar que el email se caiga durante la migración (SPF, DKIM, DMARC, MX)?

El email se cae por dos motivos puntuales: la IP del servidor nuevo no está en el SPF antes del corte, o el auto-scan del proveedor DNS nuevo no detecta selectores DKIM personalizados. Ninguno de los dos aparece en los logs de tráfico web, así que suelen pasar desapercibidos hasta que empiezan los rebotes y alguien se pregunta por qué los clientes no reciben la confirmación de pedido.

Si tu aplicación manda mail transaccional desde la IP del propio servidor (algo tipo ip4:198.51.100.24 en el SPF), hay que agregar la IP nueva antes de migrar y dejar la vieja hasta que la cola de correo del servidor anterior termine de vaciarse. El otro problema es más silencioso: cuando agregás el dominio a un proveedor DNS nuevo usando su “escaneo automático”, esa herramienta adivina nombres comunes (www, mail, _dmarc) pero no puede adivinar un selector DKIM custom como 202610._domainkey.example.com salvo que importes el zone file completo.

Checklist pre y post cutover para la migración DNS

Antes de tocar producción, conviene tener esta lista a mano durante toda la ventana de deployment:

• Backup completo de la zona BIND: exportá todos los registros del proveedor actual, con atención a subdominios custom (_dmarc, *_domainkey, status, cdn, api).
• Chequeo cruzado de A y AAAA: confirmá si existe un AAAA y actualizalo a la IP v6 nueva, o borralo si el host nuevo es solo IPv4.
• TTL bajo con anticipación: bajá el TTL a 300 segundos al menos 24 horas antes del corte, nunca en el mismo momento.
• CAA verificado: confirmá que la CA del servidor nuevo esté permitida y probá HTTPS con curl --resolve antes del cambio.
• Propagación global confirmada: después de cambiar el registro, consultá varios resolvers (dig @1.1.1.1, dig @8.8.8.8, dig @9.9.9.9) para ver que todos respondan igual.
• TTL restaurado después de 24 horas: una vez que tráfico, SSL y logs de correo estén limpios por un día entero, subí el TTL otra vez a 3600 segundos.

Si estás evaluando migrar de proveedor de hosting o de dominio, vale la pena coordinar este checklist con quien administra tu infraestructura. En donweb.com se puede gestionar dominios y hosting desde un mismo panel, lo que simplifica bastante el control de los registros antes de un cutover de este tipo.

Errores comunes al auditar registros DNS para una migración

• Confiar solo en el dashboard web del proveedor: las capturas de pantalla no reemplazan un export real del zone file. Si el dashboard tiene un bug o no muestra todos los registros, nadie lo nota hasta que falta algo en producción.
• Bajar el TTL el mismo día del cambio de IP: el TTL viejo sigue vivo en los resolvers que consultaron antes, así que el “ahorro de tiempo” de no esperar termina costando horas de tráfico mixto.
• Dejar el AAAA sin revisar porque “no usamos IPv6”: muchos proveedores lo activan por default. Si existe y apunta al servidor viejo, buena parte del tráfico móvil lo va a seguir usando aunque el A esté perfecto.
• Poner un CNAME en el apex del dominio: el RFC 1034 lo prohíbe porque el apex tiene que convivir con SOA y NS. Si necesitás alias en la raíz, hay que usar ALIAS o ANAME, no CNAME directo.

Preguntas Frecuentes

¿Qué registros DNS hay que revisar antes de migrar un dominio?

Hay que revisar SOA, NS, A, AAAA, CNAME, MX, TXT y CAA, en ese orden de criticidad. El AAAA y el CAA son los que más fallas silenciosas generan porque suelen quedar fuera del chequeo rápido que hace la mayoría de los equipos. Complementá con qué costos implica mover tu infraestructura a la nube.

¿Cómo bajo el TTL antes de una migración sin que se rompa el sitio?

Bajás el TTL a 300 segundos entre 24 y 48 horas antes del cutover, y esperás que ese plazo termine de vencer antes de cambiar la IP. Si cambiás ambas cosas al mismo tiempo, el TTL anterior sigue cacheado en los resolvers que ya consultaron.

¿Por qué mi email deja de funcionar después de migrar el servidor?

El email se rompe cuando el SPF no incluye la IP del servidor nuevo o cuando el auto-scan de un proveedor DNS nuevo no detecta selectores DKIM personalizados. Ambos problemas se evitan importando el zone file completo en vez de usar el escaneo automático.

¿Qué es un registro CAA y por qué bloquea el certificado SSL nuevo?

Un CAA es una lista blanca de autoridades certificantes autorizadas a emitir TLS para ese dominio. Si tiene un valor como 0 issue "sectigo.com" y tu servidor nuevo usa Let’s Encrypt, la emisión del certificado falla porque esa CA no está en la lista.

¿Cómo verifico si la propagación DNS ya terminó en todos los resolvers?

Consultando varios resolvers públicos por separado con dig @1.1.1.1, dig @8.8.8.8 y dig @9.9.9.9, y comparando que todos devuelvan el mismo valor nuevo. Si alguno sigue mostrando la IP vieja, todavía está sirviendo desde caché y conviene esperar antes de dar por cerrada la migración.

Conclusión

Auditar registros DNS antes de una migración no es un paso opcional, es lo que separa un cutover silencioso de una tarde apagando incendios. La fuente es clara en un punto: el problema casi nunca es el A record, es todo lo que nadie miró alrededor (AAAA residual, CAA restrictivo, selectores DKIM que el auto-scan no detecta).

Lo que se puede aplicar hoy mismo no depende del tamaño del proyecto: exportar la zona completa, bajar el TTL con dos días de anticipación, confirmar el CAA antes de pedir el certificado nuevo, y no dar por cerrado el proceso hasta que varios resolvers públicos muestren el mismo valor. La diferencia está en cuánto tiempo dedicarle a cada paso según la antigüedad del dominio y la cantidad de servicios conectados, como vimos en el ejemplo hipotético de la tienda online. Lo que esta guía no permite afirmar es un porcentaje exacto de downtime evitado, porque eso depende de cada zona y de cuántos registros huérfanos acumuló cada dominio en particular.

Fuentes

• How to Audit DNS Records Before a Domain Migration (Without Downtime) – guía técnica original con el workflow completo de auditoría