Elige TTL DNS para una migración: registra los supuestos

Elige una expectativa antes que un número

Nombra registro/tipo permitido, motivo temporal, proveedor DNS, modo y responsable de evidencia. Separa valor actual, candidato y predeterminado heredado. Marca cada campo editable, fijo o desconocido con referencia fechada. Ver un TTL no significa que sea un ajuste editable del registro.

Esta ficha es más acotada que un plan de cambio. Secuencia, controles operativos y reversión pertenecen a ese plan; dependencias de correo, a su revisión. No cambies registros ajenos ni delegación para hacer que una propuesta parezca más rápida.

Empieza con una ficha TTL en blanco

Portada: propósito/alcance ____; referencia y fecha de proveedor/modo/plan ____; responsable ____; ventana/zona horaria ____; dependencias protegidas ____; responsable del plan de cambio ____. Usa referencias aprobadas, no credenciales ni valores privados de zona. Repite por registro o expectativa.

Vacío o desconocido expresa un límite. Una hora propuesta y una fórmula no prueban que se operó. Si después se autorizan observaciones, registra fuente, hora y alcance propios.

Separa duración y control del proveedor

La sección 4 de RFC 8767 describe TTL como duración en segundos antes de volver a consultar la fuente; cero corresponde a la transacción en curso. Permite uso condicionado de datos vencidos si falla la actualización autoritativa. El documento de marzo de 2020 no convierte TTL en plazo incondicional de frescura ni dice que todos los resolutores usen serve-stale.[1]

Cloudflare, en su página actualizada el 16 de abril de 2026, documenta Auto 300 segundos fijo para registros con proxy, opciones según plan para solo DNS y una función separada de TTL de servidores de nombres. Advierte sobre demora por cachés locales. Verifica modo y opciones vigentes: Auto y editabilidad no son universales.[2]

Trata la ausencia como rama independiente

Las secciones 3–5 de RFC 2308 describen duración negativa acotada usando el menor entre TTL del SOA y SOA.MINIMUM. Distinguen clave nombre/clase en NXDOMAIN de nombre/tipo/clase en NODATA. Tiempo de espera, otro error o respuesta vacía no equivalen automáticamente a esos casos. Pide al responsable la evidencia pertinente; aquí no hay consulta.[3]

El documento de marzo de 1998 separa también $TTL del archivo maestro, predeterminado para registros posteriores sin TTL explícito, de SOA.MINIMUM. Un candidato A/AAAA positivo o $TTL no sustituye evidencia negativa. No se adoptan detalles históricos de firmas ni recomendaciones numéricas de resolutores, ni se supone acceso a esos ajustes.[3]

Birch Lantern Migration ficticia: revisa el adelanto

T1 propone publicar la reducción a las 08:00 y cambiar a las 09:30. 7200 segundos = 2 horas: horizonte simplificado 08:00 + 2 horas = 10:00. Hay 90 minutos de adelanto, faltan 30: REVISAR. Ni las 10:00 demuestran expiración global o preparación. El candidato 600 no reemplaza retroactivamente 7200 en respuestas almacenadas.

T3: min(1800,900) = 900 segundos = 15 minutos. Si un resolutor ficticio guardó ese NXDOMAIN acotado a las 14:05, el modelo ordinario llega a las 14:20. Usarlo a las 14:10 da 5 minutos, faltan 10. Es independiente del candidato 600 de T1; no comparten almacenamiento ni se acredita ausencia real. NODATA y otros errores mantienen clasificación propia.

Tres filas: 1 configurable con revisión de adelanto + 1 rechazo de edición fija + 1 caso negativo independiente = 3. No se elige TTL universal ni se publica, vacía caché o retira un destino. Mira, responsable ficticia, revisará T1 tras evidencia de aceptación autorizada por separado, aún no aportada.

Redacta una expectativa condicionada

Un candidato menor puede reducir duración normal de respuestas futuras con un equilibrio entre caché y consultas de actualización. No resuelve destino fallido, delegación, caché local ni fallo de actualización. Conserva TTL anterior y publicación prevista separados del candidato futuro.[2]

Declara lo desconocido sobre actualizaciones previas y política serve-stale condicional. El horizonte simplificado detecta adelantos insuficientes, pero no expiración final en todos lados, límite efectivo de datos vencidos ni aceptación. No se deduce receta automática de 60/300 segundos o 24–48 horas.[1]

Asigna evidencia pendiente y revisión

Entrega candidato compatible y motivo, controlabilidad, supuesto anterior, rama negativa separada, preguntas y expectativa condicionada. Define quién revisa el TTL temporal tras aceptar el cambio y con qué disparador. Restaurar un valor mayor crea otra expectativa; esta ficha no lo ejecuta ni permite retirar servicios.