Registros y TTL de DNS: prepare un cambio que pueda verificar
DNS indica a los clientes dónde buscar un servicio. No mueve datos de la aplicación, no instala un certificado ni deja listo un servidor nuevo. Un cambio fiable comienza con un inventario de registros y termina tanto con pruebas de DNS como con una aplicación en funcionamiento.
La conclusión práctica
Cambie los registros que realmente controlan el servicio, tenga en cuenta las duraciones de caché existentes, verifique por separado las respuestas autoritativas y recursivas y mantenga bajo control el punto de conexión anterior.
Sepa qué aporta cada registro
| Tipo | Propósito | Compruebe antes de un cambio de alojamiento |
|---|---|---|
| A | Asigna un nombre a una dirección IPv4 | El destino sirve el nombre de host y la configuración HTTPS previstos |
| AAAA | Asigna un nombre a una dirección IPv6 | IPv6 llega al mismo servicio operativo que IPv4 |
| CNAME | Crea un alias de un nombre a otro nombre | El destino es un nombre de host, no una dirección IP ni una URL completa |
| MX | Identifica los destinos de entrega de correo | Los cambios del sitio web no redirigen el correo entrante de forma involuntaria |
| TXT | Transporta verificaciones y otras políticas de texto | Los registros de propiedad y autenticación de correo requeridos permanecen intactos |
| CAA | Restringe la emisión por parte de autoridades de certificación | El emisor de certificados previsto es compatible con la política |
Por ejemplo, example.com puede tener un registro A y www.example.com puede crearle un alias mediante un CNAME. Revise ambos nombres de cara al usuario. Un cambio de dirección del primero puede afectar al alias, mientras que un nombre de host no relacionado puede seguir apuntando directamente al servidor antiguo. Las funciones de alias en el ápice de la zona varían según el proveedor DNS; siga su mecanismo documentado en lugar de suponer que toda interfaz acepta un CNAME normal en el ápice.
No deje un registro AAAA antiguo cuando se mueva el destino IPv4. Algunos clientes pueden seguir llegando al servicio IPv6 obsoleto mientras otros usan la nueva dirección IPv4. Confirme la disponibilidad IPv6 prevista antes de publicar esa ruta. Del mismo modo, mover un sitio web no es motivo para sustituir registros MX o TXT cuando el servicio de correo se queda donde está.
Planifique las respuestas que ya están en caché
El TTL otorga una vida útil en caché a una respuesta DNS. Reducirlo en el registro autoritativo no acorta una respuesta antigua que ya está en caché en otro lugar. Si el valor existente es de 86.400 segundos y desea un valor de 300 segundos para un cambio planificado, redúzcalo con suficiente antelación para que transcurra la vida útil anterior. Esos valores ilustran la planificación; las opciones disponibles dependen del servicio y el registro DNS.
DNS también puede almacenar en caché una respuesta que indica que un nombre no existe o no tiene el registro solicitado. Esa caché negativa se rige por las reglas de DNS y la información de la zona, no por el TTL de un registro que añada después. Evite descubrirlo durante un lanzamiento probando el nuevo nombre de host solo después de haberlo publicado deliberadamente y de haberlo previsto en el plan.
Un TTL no es una cuenta atrás hacia un cambio simultáneo en todo el mundo. Los clientes, los resolutores recursivos y las conexiones de aplicación existentes no se actualizan todos a la vez. Mantenga el endpoint anterior bajo control durante el solapamiento. Si la aplicación acepta escrituras, el plan de migración debe definir una única autoridad de datos mientras el tráfico aún pueda llegar a más de una dirección.
Verifique la respuesta DNS y después el servicio que hay detrás
- Anote el valor anterior y el reemplazo exacto previsto.
- Consulte cada servidor de nombres autoritativo para el nombre y el tipo de registro afectados.
- Compare las respuestas de más de un resolutor recursivo y anote los TTL restantes.
- Compruebe todos los nombres de host públicos y ambas familias de IP que estén realmente publicados.
- Pruebe HTTPS y el comportamiento representativo de la aplicación usando el nombre de host real.
- Observe el tráfico residual antes de aumentar el TTL o retirar el endpoint antiguo.
Distinga un error autoritativo de una respuesta antigua en caché. Si los servidores autoritativos no coinciden, investigue la publicación de la zona o la delegación. Si la autoridad es correcta pero un resolutor aún tiene una respuesta antigua, compare su vida útil restante antes de hacer otra edición no relacionada. Cambiar los valores repetidamente puede dificultar la interpretación de la ventana de observación.
Una respuesta de dirección correcta no demuestra un certificado válido ni un host virtual en funcionamiento. HTTPS usa el nombre de host solicitado, y la aplicación debe reconocerlo. Si un proxy o CDN forma parte del diseño, comprenda qué dirección devuelta representa a ese intermediario y qué ajuste de origen controla su backend. Mantenga el resultado de DNS y la prueba del servicio de origen como comprobaciones separadas.
Proteja la validación DNSSEC y mantenga una reversión realista
Si DNSSEC está habilitado, una migración de servidor de nombres o de proveedor de firma debe tener en cuenta el registro DS del padre y las nuevas claves de firma. Una discrepancia puede hacer que los resolutores de validación rechacen las respuestas. Siga el procedimiento de migración documentado tanto para los proveedores como para el registrador, incluidos los tiempos de caché aplicables. No elimine registros de confianza ni desactive la validación como primera respuesta improvisada ante un error web inexplicado.
Conserve los valores DNS anteriores con el registro del cambio, pero recuerde qué puede revertir. Restaurar una dirección antigua cambia el destino de las resoluciones futuras; no devuelve los datos de clientes aceptados por la nueva aplicación. Use el plan de migración independiente para decidir cuándo es segura la reversión del tráfico y cuándo se requiere una reconciliación de datos. Finalice solo después de haber comprobado la aplicación, las dependencias de correo y las copias de recuperación.
