Errores de TTL DNS que acechan las migraciones — Cómo configurar el TTL como un profesional

TTL no es “propagación”: qué sucede realmente

TTL (time to live) es el número de segundos que una respuesta DNS puede vivir en caché. No es cuánto tarda “internet” en enterarse de tu cambio. Esa frase de “propagación DNS” es marketing para quien vende dominios y aspirinas.

Este es el flujo real en producción:

• DNS autoritativo aloja la verdad de una zona (tus registros, tu SOA, tu conjunto de NS).
• Resolutores recursivos (resolutores de ISP, corporativos, públicos) obtienen y cachean respuestas desde los servidores autoritativos.
• Resolutores stub en máquinas preguntan a un resolutor recursivo. También pueden cachear, según el SO, las librerías y los demonios locales.
• Cacheo a nivel de aplicación también ocurre. Java, Go, Envoy, navegadores, el edge de CDNs y SDKs misteriosos a veces cachean DNS de formas que no pediste.

Cuando cambias un registro en el nivel autoritativo, nada empuja ese cambio hacia afuera. El mundo aprende la nueva respuesta solo cuando las cachés expiran y los resolutores preguntan de nuevo. TTL es el permiso que indica a las cachés cuán perezosas pueden ser.

Una cosa más: TTL es por conjunto de registros en la respuesta. Eso incluye respuestas negativas (NXDOMAIN), que también se cachean. La gente lo olvida y luego se pregunta por qué el nombre recién creado “no existe” durante una hora.

Broma #1: “Propagación” DNS es como “vamos a hacer seguimiento” en los correos corporativos: significa “no en tu horario”.

Datos interesantes e historia breve (útiles en reuniones)

1. DNS reemplazó HOSTS.TXT porque un archivo mantenido centralmente no escalaba. TTL existe porque el cacheo es la única forma en que un sistema de nombres global sobrevive.
2. TTL ha estado en DNS desde los RFCs tempranos como un mecanismo central para controlar el comportamiento de caché. No es una perilla opcional de afinación; es un contrato.
3. El cacheo negativo se estandarizó más tarde, después de que los operadores se dieron cuenta de que preguntar repetidamente “¿existe este nombre?” derrite los resolutores durante fallas y ataques.
4. El registro SOA tiene dos conceptos diferentes de “mínimo” históricamente: semántica antigua vs uso moderno como TTL de cacheo negativo. La confusión aquí todavía causa dolores en migraciones.
5. Los resolutores pueden limitar los TTL (tanto mínimos como máximos) por política o rendimiento. Tu TTL de 30 segundos puede convertirse en 300 segundos en algunas redes.
6. Algunas plataformas ignoran el TTL en la práctica porque fijan las respuestas DNS o las cachean agresivamente. Eso no es DNS roto; es comportamiento de la aplicación.
7. Las CDNs y balanceadores globales a menudo dependen de DNS precisamente porque el TTL da un “movimiento eventual” controlado del tráfico. Usado bien, es confiable y predecible.
8. Históricamente se desaconsejaban TTLs bajos cuando los servidores autoritativos eran más débiles y el ancho de banda caro. Hoy en día importa menos el costo y más la disciplina operativa.
9. EDNS y características modernas de resolutores mejoraron rendimiento y robustez, pero no eliminaron el cacheo. El cacheo sigue siendo el objetivo.

Un modelo mental del TTL que sobrevive en redes reales

Si recuerdas solo un modelo, usa este:

Tiempo observado de corte = max(capas de caché) + tus propios errores.

Layer 1: Caché del resolutor recursivo

Este es el grande. Tus usuarios no consultan directamente tus servidores autoritativos; consultan a un resolutor. Ese resolutor típicamente obedece TTL, pero puede ajustarlo. Si el resolutor cacheó la respuesta antigua hace cinco minutos con un TTL de 1 hora, puedes cambiar el registro cuanto quieras: esos usuarios estarán pegados a la respuesta antigua hasta 55 minutos más.

Layer 2: Caché del resolutor stub y a nivel de host

En Linux podrías tener systemd-resolved, nscd, dnsmasq, o nada. En macOS existe el comportamiento de mDNSResponder. En Windows hay un servicio DNS Client. Algunos de estos respetan TTL, otros tienen lógica adicional, y algunas aplicaciones los evitan.

Layer 3: Cacheo en la aplicación y en el runtime

Los navegadores pueden cachear DNS, pero también lo puede hacer tu pila cliente HTTP. La JVM históricamente tuvo valores por defecto de “cachear para siempre” en ciertos modos. Algunos service meshes o sidecars cachean agresivamente por rendimiento. Y algunos equipos tienen su propia librería de “cache DNS” porque una vez fueron alertados por latencia del resolutor. Adivina qué: ahora te alertarán por las migraciones.

Layer 4: Reutilización de conexiones y sesiones de larga vida

Aunque DNS se actualice instantáneamente, el tráfico puede no moverse porque los clientes mantienen conexiones TCP existentes. HTTP/2, gRPC, WebSockets, pools de base de datos: están diseñados para ser pegajosos. DNS solo afecta conexiones nuevas (a menos que cierres/escales activamente). Durante la migración, la vida útil de las conexiones puede importar más que el TTL.

Por qué “configurar TTL a 60 segundos” no significa automáticamente “corte en 60 segundos”

Porque el registro puede ya estar cacheado con un TTL mayor, porque existe cacheo negativo, porque los resolutores ajustan TTL, porque existen cachés en aplicaciones y porque hay reutilización de conexiones.

TTL no es un cronómetro. Es una edad máxima desde el momento del cacheo. Si necesitas previsibilidad, planificas hacia atrás: baja el TTL con suficiente antelación para que las cachés se refresquen bajo el nuevo TTL antes de la ventana de corte.

Una cita para tener a mano en conversaciones de fiabilidad:

“La esperanza no es una estrategia.” — idea parafraseada atribuida a muchos ingenieros de fiabilidad y líderes SRE

Cómo configurar el TTL como un profesional (pre-corte, corte, post-corte)

Paso 0: Decide qué significa “corte” en tu sistema

El corte de DNS es solo una palanca. Antes de tocar TTLs, decide:

• ¿Vas a mover todo el tráfico o solo un subconjunto?
• ¿Necesitas rollback rápido (minutos) o son aceptables horas?
• ¿Los clientes son internos (resolutores corporativos que controlas) o externos (el zoológico del caos)?
• ¿Los servicios son stateful (bases de datos) o stateless (web/API)?
• ¿Tienes un segundo plano de control (pesos de balanceador, configuración de CDN, descubrimiento de servicios) que podría ser mejor que DNS?

DNS es excelente para movimientos de tráfico gruesos y failover cuando toleras ventanas de caché. Es una mala herramienta para enrutamiento segundo a segundo. Si lo tratas como un balanceador de carga, te recordará quién manda.

Pre-corte: baja los TTL temprano, no “justo antes”

La jugada profesional es bajar los TTLs al menos un periodo completo del viejo TTL antes del corte. Idealmente dos. Porque el mundo puede haber cacheado el registro en cualquier momento durante la ventana del TTL anterior.

Ejemplo: tu TTL actual es 3600 segundos (1 hora). Quieres una ventana de corte de 60 segundos. Baja el TTL a 60 al menos 1 hora antes del corte—y preferiblemente más temprano. Eso da tiempo a las cachés para refrescarse y empezar a obedecer el nuevo TTL bajo.

Elige valores de TTL sensatos (y no te pongas creativo)

Aquí un punto de partida con opinión que funciona para la mayoría de migraciones:

• Operaciones normales (estado estable): 300–900 segundos para la mayoría de registros A/AAAA; 900–3600 para registros que cambian raramente.
• Ventana de migración: 30–120 segundos para los nombres específicos que vas a cortar.
• Post-corte: sube de nuevo a 300–900 una vez estable; no dejes todo a 30 segundos para siempre a menos que hayas calculado la carga de consultas y auditado los resolutores.

Sí, TTLs de 30 segundos son posibles. No, no son gratis. Pagas en carga de resolutores, QPS autoritativas y complejidad en incidentes cuando tu proveedor DNS tiene un mal día.

Corte: cambia el registro correcto en el lugar correcto

La mayoría de migraciones fallan porque alguien cambió un registro, no el registro.

• Si tienes una cadena (CNAME a otro CNAME a A/AAAA), debes entender el TTL en cada salto.
• Si tienes DNS de horizonte dividido, debes cambiar las vistas interna y externa intencionalmente.
• Si usas DNS gestionado más una zona de anulación interna, sabe cuál prevalece para qué clientes.

Además: si usas un registro apex (example.com) y haces trucos parecidos a CNAME, ten mucho cuidado. El comportamiento específico del proveedor puede cambiar qué TTLs aparecen realmente en las respuestas.

Plan de rollback: TTL es tu control del radio de impacto

El tiempo de rollback también está controlado por las cachés. Si haces el corte y sale mal, revertir no es “instantáneo”, aunque seas rápido. Si quieres rollback rápido, necesitabas TTL bajo antes del corte, y debes considerar la reutilización de conexiones. De lo contrario, el rollback es otra migración, también sujeta a cachés.

Post-corte: sube los TTLs y vigila a los rezagados

Después de estabilizar, sube los TTLs a un valor que reduzca la carga de consultas y la fricción operativa. Pero no te apresures. Mantén los TTLs bajos el tiempo suficiente para soportar rollback mientras el nuevo entorno se asienta.

Y vigila clientes rezagados. Siempre hay unos pocos: dispositivos embebidos, JVMs antiguas, proxies corporativos y librerías “útiles” que fijan DNS.

Broma #2: Configurar TTLs a 5 segundos se siente poderoso hasta que llega la factura de DNS como una revisión de desempeño.

Tareas prácticas: 12+ comprobaciones y decisiones con comandos

Estas son las tareas que realmente ejecuto durante una migración. Cada una tiene: comando, qué significa la salida y qué decisión tomar.

Task 1: Verify what the world sees (authoritative answer via +trace)

cr0x@server:~$ dig +trace www.example.com A

; <<>> DiG 9.18.24 <<>> +trace www.example.com A
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms

www.example.com.      60      IN      A       203.0.113.42
;; Received 56 bytes from 198.51.100.53#53(ns1.example.net) in 22 ms

Meaning: The final answer shows TTL=60 at the authoritative source (as observed through trace). That’s the “truth” being served now.

Decision: If TTL here is not what you expect, stop. Fix the authoritative zone first. Don’t debug clients yet.

Task 2: Check the recursive resolver you actually use

cr0x@server:~$ dig @1.1.1.1 www.example.com A +noall +answer +ttlid

www.example.com.      47      IN      A       203.0.113.42

Meaning: Cloudflare’s resolver has cached the record and will keep it for 47 more seconds.

Decision: If the TTL remaining is huge, your earlier TTL-lowering didn’t “take” in time, or the resolver clamped it. Adjust expectations and rollback strategy.

Task 3: Compare multiple resolvers to detect clamping or stale caches

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do dig @$r www.example.com A +noall +answer +ttlid; done

www.example.com.      52      IN      A       203.0.113.42
www.example.com.      300     IN      A       203.0.113.42
www.example.com.      58      IN      A       203.0.113.42

Meaning: One resolver is effectively using 300 seconds. That could be a clamp, or it cached before TTL was lowered.

Decision: If external user experience matters, plan for the worst observed caching. Your “60-second” cutover is not globally 60 seconds.

Task 4: Inspect CNAME chains and TTL at each hop

cr0x@server:~$ dig www.example.com CNAME +noall +answer +ttlid

www.example.com.      60      IN      CNAME   app-lb.example.net.

cr0x@server:~$ dig app-lb.example.net A +noall +answer +ttlid

app-lb.example.net.   300     IN      A       198.51.100.77

Meaning: Even if the CNAME TTL is 60, the A record it points to may have TTL 300 and be cached independently.

Decision: During migrations, lower TTLs consistently across the chain, or change the record at the right level (often the CNAME target).

Task 5: Confirm AAAA behavior (IPv6 can surprise you)

cr0x@server:~$ dig www.example.com AAAA +noall +answer +ttlid

www.example.com.      60      IN      AAAA    2001:db8:10::42

Meaning: Clients preferring IPv6 will use this path. If you only updated A, half your traffic may ignore you.

Decision: Treat A and AAAA as a pair. Migrate both, or intentionally disable one (with full awareness of impact).

Task 6: Check negative caching (NXDOMAIN) before creating new names

cr0x@server:~$ dig newservice.example.com A +noall +answer +authority

example.com.          900     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300

Meaning: No answer section; the authority section shows SOA with a minimum/negative caching TTL behavior (commonly 300 here).

Decision: If you’re about to create a brand-new name during cutover, check and tune negative caching in advance. Otherwise “it doesn’t exist” can persist.

Task 7: Verify authoritative NS set and delegation correctness

cr0x@server:~$ dig example.com NS +noall +answer

example.com.          3600    IN      NS      ns1.example.net.
example.com.          3600    IN      NS      ns2.example.net.

Meaning: These are the authoritative servers clients should reach (after delegation).

Decision: If you’re migrating DNS providers, mismatched NS sets or partial delegation will create “some users see old, some new” chaos for days.

Task 8: Check SOA serial and whether secondaries picked up changes

cr0x@server:~$ dig @ns1.example.net example.com SOA +noall +answer
example.com.          900     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123102 3600 600 1209600 300

cr0x@server:~$ dig @ns2.example.net example.com SOA +noall +answer
example.com.          900     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300

Meaning: ns2 is behind (serial differs). Your “change” isn’t globally served yet.

Decision: Fix zone transfer/propagation between authoritative servers before cutover. Otherwise resolvers will get different answers depending on which NS they hit.

Task 9: Observe TTL from a specific client host (system resolver path)

cr0x@server:~$ resolvectl query www.example.com

www.example.com: 203.0.113.42                    -- link: eth0
                 (A) --> 47s

Meaning: systemd-resolved shows remaining TTL in its cache for that host.

Decision: If the host cache is sticky or wrong, you may need to flush local caches for critical systems (or restart a service) as part of cutover.

Task 10: Identify which resolver a host is using (you’d be amazed)

cr0x@server:~$ cat /etc/resolv.conf
nameserver 10.0.0.53
search corp.example
options timeout:1 attempts:2

Meaning: This host uses a corporate resolver, not public DNS. Your external tests might be irrelevant.

Decision: Run cutover validation against the resolvers your clients actually use. If you don’t know them, you don’t have a plan.

Task 11: Confirm the resolver’s cache status (BIND example)

cr0x@server:~$ sudo rndc dumpdb -cache
cr0x@server:~$ sudo grep -n "www.example.com" /var/cache/bind/named_dump.db | head
12451:www.example.com. 47 IN A 203.0.113.42

Meaning: The local recursive resolver has the record cached with 47 seconds remaining.

Decision: If the resolver cache is stale during cutover and you control it, consider flushing the specific name (not the entire cache unless you enjoy self-inflicted outages).

Task 12: Measure whether users are stuck on old IPs via logs

cr0x@server:~$ sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
  912 203.0.113.10
  301 198.51.100.77
  118 203.0.113.11

Meaning: Requests are arriving at multiple frontends/IPs. If 198.51.100.77 is the “old” endpoint, some clients haven’t moved.

Decision: Keep the old endpoint healthy until the tail dies down, or actively drain/redirect. Don’t turn it off “because DNS.”

Task 13: Validate that the new endpoint answers correctly (don’t trust DNS yet)

cr0x@server:~$ curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" --resolve www.example.com:443:203.0.113.42 https://www.example.com/healthz
200 203.0.113.42

Meaning: You forced the connection to the new IP while keeping the hostname for TLS/SNI. Health is good.

Decision: If this fails, do not cut DNS. Fix the new endpoint first. DNS is not a test tool; it’s a steering wheel.

Task 14: Check for long-lived connections that ignore DNS changes

cr0x@server:~$ ss -antp | grep ':443' | head
ESTAB 0 0 203.0.113.42:443 198.51.100.25:52144 users:(("nginx",pid=2210,fd=44))
ESTAB 0 0 203.0.113.42:443 198.51.100.25:52145 users:(("nginx",pid=2210,fd=45))

Meaning: Active sessions exist. If you change DNS, existing clients may keep talking to the old endpoint until these connections close.

Decision: Plan draining and connection lifetime controls (keepalive timeouts, graceful shutdown) alongside TTL changes.

Task 15: Confirm DNSSEC status if you’re changing providers

cr0x@server:~$ dig www.example.com A +dnssec +noall +answer +adflag

www.example.com.      60      IN      A       203.0.113.42

Meaning: If you see the AD flag in some resolver contexts, validation succeeded. If validation fails after changes, clients may treat answers as bogus.

Decision: During provider migrations, manage DS records and signing carefully. DNSSEC failures look like random outages with “but DNS looks fine for me” sprinkled on top.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando el tráfico no se mueve y la ventana de migración se consume, necesitas un orden de triage que funcione.

Primero: ¿es correcta la verdad autoritativa?

• Ejecuta dig +trace para el nombre y tipo exactos (A, AAAA, CNAME).
• Verifica TTL, destinos y que la respuesta coincida con el destino previsto.
• Revisa el serial SOA en todos los servidores autoritativos si tienes varios.

Si lo autoritativo está mal, detente. Arregla la zona. Todo lo demás es ruido.

Segundo: ¿los resolutores devuelven respuestas obsoletas?

• Consulta los resolutores que usan tus clientes (resolutores corporativos, públicos, regionales).
• Compara TTL restante y las IPs devueltas.
• Busca clamps (TTL inesperadamente alto) o comportamiento dividido (algunos resolutores viejos, otros nuevos).

Si los resolutores están obsoletos, esperas a que las cachés expiren a menos que controles los resolutores y puedas vaciarlos selectivamente.

Tercero: ¿el tráfico está atascado por razones no relacionadas con DNS?

• Comprueba si los clientes mantienen conexiones existentes hacia endpoints antiguos.
• Revisa el comportamiento de cacheo DNS en runtimes de cliente (JVM, sidecars, proxies).
• Revisa LB/chequeos de salud: puede que DNS haya cambiado pero el nuevo backend esté unhealthy y la lógica de failover vuelva al antiguo.

Si DNS es correcto pero el tráfico no se mueve, estás lidiando con la vida de las conexiones, caché en aplicaciones o enrutamiento upstream—no con TTL de DNS.

Tres mini-historias corporativas (anonimizadas, dolorosamente plausibles)

1) El incidente causado por una suposición equivocada

Estaban migrando un portal de clientes desde un colo a un balanceador en la nube. El plan decía: “Bajar TTL a 60 segundos el día antes, luego volcar el registro A a medianoche.” Limpio y civilizado.

El ingeniero de turno bajó el TTL—en el registro equivocado. Había una cadena CNAME bonita: portal.example.com apuntaba a portal.edge.example.net, y ese tenía el A apuntando al VIP antiguo. Bajaron el TTL en portal.example.com, pero dejaron portal.edge.example.net en 3600.

A medianoche cambiaron el A en el nombre objetivo, pero las cachés alrededor del mundo aún tenían el A antiguo por hasta una hora. Algunos clientes llegaron al nuevo portal, otros al antiguo, y las sesiones rebotaban según el resolutor que obtuvieras. Soporte lo vio como “desconexiones aleatorias.” Ingeniería lo vio como “imposible de reproducir.” Todos estaban equivocados al mismo tiempo.

El postmortem no fue sobre “DNS es poco fiable.” DNS hizo exactamente lo que se le pidió. El fallo fue asumir que el nombre visible era el que controlaba el comportamiento de caché. Las cadenas CNAME son pequeñas máquinas del tiempo de TTL. Si no las mapeas, ellas te mapearán a ti.

2) La optimización que salió mal

Otra empresa que corría una API de alto tráfico decidió que la latencia DNS era demasiado cara. Introdujeron un cache DNS in-process en su librería cliente con un TTL mínimo de 10 minutos. El objetivo declarado: reducir QPS de resolutor y mejorar p99.

Funcionó. Las gráficas de resolutores bajaron. La latencia mejoró un poco. Todos se olvidaron porque el tablero estaba en verde y a nadie le gusta leer RFCs durante un buen trimestre.

Luego vino una migración regional. Planearon un desplazamiento gradual usando una configuración ponderada detrás de un CNAME. En papel, un TTL de 60 segundos les daba control rápido. En realidad, clientes grandes ejecutando la librería cliente se quedaron con respuestas antiguas durante 10 minutos a la vez, y el cambio se comportó como una escalera testaruda.

Peor: el rollback no fue real. Cuando un subconjunto de peticiones empezó a fallar en la nueva región, “revirtieron” DNS, pero el cache siguió enviando tráfico a la región rota por minutos. Los ingenieros empezaron a dudar de sus propias herramientas. El negocio empezó a dudar de ingeniería. Así es como quemas credibilidad, no solo uptime.

La solución no fue “nunca cachear DNS.” La solución fue respetar TTL y hacer observable y configurable el comportamiento de cacheo. Los hacks de rendimiento que anulan contratos siempre te cobran durante las migraciones.

3) La práctica aburrida pero correcta que salvó el día

Un equipo empresarial tenía un ritual. Antes de cualquier migración mayor, ejecutaban un simulacro de preparación DNS 48 horas antes. No una reunión—un simulacro. Verificaban los TTLs actuales, los bajaban en un cambio controlado, y luego validaban desde múltiples puntos (resolutores corporativos, resolutores públicos y un par de regiones en la nube).

También tenían una política: no “crear nombres nuevos” durante la ventana de migración. Si se necesitaba un hostname nuevo, se creaba una semana antes, se consultaba repetidamente y se monitoreaba específicamente para quemar cacheo negativo y comportamientos raros de resolutores.

En la noche de la migración aún encontraron un problema: un secundario autoritativo no estaba recogiendo actualizaciones de forma fiable debido a una regla de firewall que había sido “temporalmente” cambiada durante otro proyecto. El simulacro lo había detectado dos días antes. Lo arreglaron en horario laboral con tiempo de sobra.

El corte fue sin incidentes. No porque fueran genios. Porque hicieron DNS aburrido a propósito. Las mejores migraciones parecen que no pasó nada, que es exactamente el objetivo.

Errores comunes: síntoma → causa raíz → arreglo

1) “Cambiamos DNS pero algunos usuarios siguen llegando al sitio antiguo por horas”

Síntoma: Tráfico mixto a endpoints antiguos y nuevos mucho después del corte.

Causa raíz: El TTL antiguo era alto y lo bajaste demasiado tarde; o los resolutores cachearon antes del cambio de TTL; o un resolutor ajustó el TTL hacia arriba.

Arreglo: Baja el TTL al menos un periodo completo del TTL antiguo antes del corte (preferiblemente dos). Valida TTL en múltiples resolutores. Planea mantener el endpoint antiguo vivo para la cola.

2) “Usuarios internos ven nuevo, usuarios externos ven antiguo”

Síntoma: Empleados de la compañía reportan éxito; clientes reportan fallas (o al revés).

Causa raíz: DNS de horizonte dividido, zonas de anulación internas o resolutores diferentes con estados de caché distintos.

Arreglo: Documenta qué resolutores y zonas sirven a qué clientes. Prueba el corte desde dentro y fuera. Actualiza ambas vistas intencionalmente.

3) “El hostname dice NXDOMAIN, luego más tarde funciona”

Síntoma: Nombres recién creados aparecen intermitentemente rotos.

Causa raíz: Cacheo negativo de NXDOMAIN por el TTL negativo del SOA; o el nombre fue consultado antes de existir y se cacheó como “no existe”.

Arreglo: Pre-crea nombres mucho antes de la ventana; mantiene razonable el TTL de cacheo negativo; verifica parámetros SOA; evita introducir nombres nuevos en el corte.

4) “Bajamos TTL pero los clientes aún no lo respetan”

Síntoma: Algunos clientes se mantienen en una IP mucho más allá del TTL.

Causa raíz: Cacheo DNS en aplicaciones/runtime (configuraciones JVM, caches personalizados, sidecars), o conexiones de larga duración.

Arreglo: Audita el comportamiento DNS del cliente. Configura caches para respetar TTL. Establece edades máximas de conexión, drena conexiones y planifica la afinidad de sesiones por separado de DNS.

5) “Cambiamos el registro A pero nada cambió”

Síntoma: Monitorización y usuarios siguen yendo al endpoint antiguo.

Causa raíz: Cambiaste el nombre/tipo equivocado (cadena CNAME, registro diferente en uso), o existe una anulación interna.

Arreglo: Mapea la ruta de resolución (dig CNAME + trace). Confirma el nombre y tipo consultado por los clientes. Elimina o actualiza anulaciones.

6) “Después de migrar de proveedor DNS, algunos usuarios no pueden resolver”

Síntoma: SERVFAIL o timeouts para un subconjunto de resolutores.

Causa raíz: Desajuste de delegación, registros faltantes, zona parcial o desajuste DS/signado de DNSSEC.

Arreglo: Valida delegación NS, completitud autoritativa y la cadena DNSSEC antes del corte de NS. Mantén al proveedor antiguo sirviendo durante overlap si es posible.

7) “El rollback no revirtió”

Síntoma: Revertiste DNS pero el tráfico sigue yendo al nuevo target roto.

Causa raíz: Las cachés ahora tienen la nueva respuesta; conexiones de larga duración persisten; algunos clientes fijaron DNS.

Arreglo: Trata el rollback como un movimiento planificado con su propia ventana de caché. Mantén TTL bajo antes del corte y gestiona drenado/tiempos de conexión.

Listas de verificación / plan paso a paso

Planifica hacia atrás desde la ventana de corte

1. Inventario los nombres involucrados (cara al cliente, internos, API, callbacks, endpoints de webhook, SANs de certificados).
2. Mapea la resolución: A/AAAA vs cadenas CNAME, vistas de horizonte dividido, anulaciones internas.
3. Registra los TTLs actuales para cada registro en la cadena. Este es tu “TTL antiguo” que debes esperar.
4. Decide el TTL de migración (usualmente 30–120 segundos) y requisitos de rollback.
5. Baja los TTLs al menos un periodo del TTL antiguo antes del corte (dos si quieres dormir).
6. Verifica en múltiples resolutores que el TTL bajo es ahora lo que están cacheando.
7. Valida nuevos endpoints forzando resolución (curl --resolve) y corriendo chequeos de salud.
8. Corta DNS en el tiempo planeado. Registra el cambio exacto, hora y serial.
9. Monitorea la cola: el tráfico al endpoint antiguo debería decaer en unas pocas ventanas de TTL; vigila tasas de error y patrones regionales.
10. Mantén viable el rollback mientras estés en el periodo de “unknown unknowns”.
11. Sube los TTLs de nuevo a estado estable una vez se cierre la ventana de rollback.
12. Postmortem del proceso: qué te sorprendió (clamps, caches de apps, anulaciones internas), y añade eso al siguiente runbook.

Lista operativa de la noche de corte (lo que realmente haces)

• Confirma la respuesta autoritativa con dig +trace justo antes del cambio.
• Consulta resolutores corporativos y públicos y registra TTL restante.
• Verifica respuestas A y AAAA (o IPv6 deshabilitado intencionalmente) que coincidan con tu plan.
• Prueba forzada del nuevo endpoint con curl --resolve para TLS y salud.
• Confirma observabilidad: logs, métricas y alertas para ambos endpoints, viejo y nuevo.
• Realiza el cambio DNS; incrementa serial SOA si aplica.
• Vuelve a comprobar respuestas autoritativas y de resolutores inmediatamente después.
• Observa tasas de error de clientes y tráfico al endpoint antiguo. No apagues el endpoint antiguo temprano.
• Si necesitas rollback, ejecútalo rápido, pero espera la cola de caché—comunica esa realidad.

Lista de políticas (las reglas aburridas que previenen outages “creativos”)

• No introduzcas hostnames completamente nuevos durante una ventana de corte.
• No establezcas TTLs extremadamente bajos globalmente; limita el alcance a registros críticos de migración.
• No confíes en el comportamiento de un solo resolutor para validación.
• No asumas que “TTL=60” equivale a “los usuarios se mueven en 60 segundos”.
• Documenta de dónde vienen las respuestas DNS (proveedor autoritativo, vistas internas, anulaciones).
• Audita el cacheo DNS en aplicaciones y la reutilización de conexiones antes de migraciones.

Preguntas frecuentes (las que recibirás cinco minutos antes del corte)

1) ¿Qué TTL debemos usar para una migración?

Para los nombres específicos que vas a cambiar: 30–120 segundos durante la ventana. Pero solo después de bajar el TTL con suficiente antelación para que las cachés se refresquen.

2) ¿Con cuánta antelación debemos bajar el TTL?

Al menos un TTL antiguo completo antes del corte; dos si quieres comportamiento más consistente. Si el TTL antiguo es 86400, bájalo días antes, no “esta noche”.

3) ¿Por qué la “propagación DNS” tarda más que el TTL?

Porque el registro pudo haber sido cacheado antes bajo un TTL mayor, algunos resolutores ajustan TTL y algunas aplicaciones cachean independientemente. TTL es la edad máxima de caché desde cuando se cacheó.

4) ¿Debemos poner TTL a 0?

No. Muchos sistemas tratan 0 de maneras sorprendentes y dispararás la carga de consultas DNS drásticamente. Si necesitas direccionamiento casi instantáneo, usa un balanceador de carga o un mecanismo de descubrimiento diseñado para eso.

5) ¿Es más seguro un CNAME que un registro A para migraciones?

Los CNAME son buenos para indireccionamiento, pero añaden otra capa de caché. Si usas CNAMEs, gestiona TTLs en toda la cadena o tendrás cortes inconsistentes.

6) ¿Podemos “vaciar la caché DNS de internet”?

No. Puedes vaciar cachés que controlas (tus resolutores, tus hosts, tus apps), pero no las de todos. Planea para la cola y mantiene el endpoint antiguo activo.

7) ¿Por qué algunos usuarios siguen llegando al endpoint antiguo incluso después de que expiren las cachés?

Conexiones de larga duración. Los clientes pueden reutilizar conexiones TCP por minutos u horas. Los cambios de DNS solo afectan a nuevas conexiones salvo que drenes/cierres conexiones.

8) ¿Cómo validamos el nuevo endpoint sin cambiar DNS aún?

Usa resolución forzada (para HTTPS, conserva el hostname para SNI): curl --resolve. O edita el hosts file de un cliente controlado para pruebas, pero no confundas eso con comportamiento real del mundo.

9) ¿Qué pasa con DNSSEC durante migraciones?

DNSSEC está bien hasta que cambias claves de firmado o proveedores. Un desajuste DS puede causar SERVFAIL extendidos. Trata los cambios DNSSEC como una migración separada y cuidadosamente escalonada.

10) Después del corte, ¿cuándo subimos de nuevo los TTL?

Después de observar estabilidad y cerrar la ventana de rollback. Comúnmente: mantiene TTLs bajos por unas horas a un día según el riesgo, luego súbelos a 300–900 segundos.

Conclusión: pasos prácticos siguientes

Si el TTL de DNS sigue acechando tus migraciones, usualmente no es porque DNS sea inestable. Es porque el TTL fue tratado como un ajuste de último minuto en lugar de un calendario.

Haz lo siguiente:

1. Elige un hostname crítico en tu entorno y mapea su cadena completa de resolución (incluyendo AAAA).
2. Registra los TTLs actuales y decide tu objetivo de TTL para migración (30–120 segundos para nombres de corte).
3. Realiza un simulacro: baja el TTL temprano, confirma vía dig +trace y múltiples resolutores, y mide qué tan rápido se mueve realmente el tráfico.
4. Audita el cacheo DNS en aplicaciones y la vida de las conexiones. Arregla los casos de “fijan DNS para siempre” antes de que ellos te fijen a ti a las 3 AM.
5. Escribe la guía de diagnóstico rápido en tu runbook de on-call y haz que alguien la ejecute una vez antes de la noche real.

Configura el TTL como un profesional y DNS se convierte en una parte predecible de tu migración, no en una historia de fantasmas que cuentas a los nuevos contratados.