Cambiar un registro DNS con una vía de retroceso: reducción del TTL, corte y verificación

Objetivo

Trasladar un nombre de host a una nueva dirección o proveedor sin que exista un período en el que algunos usuarios lleguen a un destino caído, y poder revertir el cambio en minutos, no en horas.

Requisitos previos

Acceso de escritura a la zona autoritativa, una forma de consultar directamente tanto a los servidores autoritativos como a resolutores públicos (dig @server name type), y el nuevo destino ya en servicio y probado por dirección o bajo un nombre temporal.

Pasos

1. Consulta el TTL actual. La RFC 1035 lo define como el intervalo de tiempo durante el cual el registro puede permanecer en caché antes de volver a consultar la fuente; cualquier caché que tenga el registro lo conservará hasta ese tiempo después del cambio.
2. Reduce el TTL a unos pocos minutos (por ejemplo, 300 segundos) y espera al menos un período completo del TTL antiguo, de modo que todas las cachés que tenían el TTL largo lo hayan agotado y vuelto a obtener el registro con el TTL corto. Saltarse esta espera es un motivo habitual por el que un cambio parece «propagarse» durante todo un día.
3. Prepara el retroceso: anota el registro antiguo exacto y mantén el destino anterior en funcionamiento durante todo el proceso.
4. Realiza el cambio. Comprueba primero los servidores autoritativos, después los resolutores públicos y, por último, un resolutor de la red local.
5. Observa en los registros del nuevo destino cómo llega el tráfico, y en los del destino anterior cómo se va apagando a lo largo del TTL corto. No detengas el destino anterior hasta que lleve más tiempo en silencio que el TTL. La RFC 8767 permite que un resolutor recursivo que no puede contactar con los servidores autoritativos siga respondiendo con datos cuyo TTL ha caducado, y sugiere un temporizador máximo de datos caducados de entre 1 y 3 días; esto solo importa si los servidores autoritativos están inaccesibles, lo cual es un argumento más para no cambiar el DNS durante un incidente del proveedor.
6. Una vez que el destino anterior queda en silencio, vuelve a subir el TTL a su valor normal. El retroceso es la misma edición a la inversa y tarda un TTL corto en surtir efecto, razón por la cual el TTL se mantiene bajo hasta la confirmación.
7. Registra ambos valores del registro y las marcas de tiempo en el calendario de cambios.

Resultado esperado

El tráfico se traslada en cuestión de minutos tras el cambio, ningún usuario llega a un destino caído, y revertir el cambio consiste en editar un único registro con un retraso máximo conocido.

Límites y base de verificación

Algunos clientes ignoran los TTL: conexiones de larga duración, cachés de direcciones en tiempo de ejecución, proxies corporativos; estos necesitan un reinicio o su propio vencimiento. El almacenamiento en caché negativo de un nombre que aún no existía tiene su propio TTL: la RFC 2308 lo fija como el mínimo entre el campo MINIMUM del registro SOA y el propio TTL del SOA. El procedimiento sigue las RFC citadas; no se afirma ningún tiempo de propagación más allá de la aritmética del TTL.