Resumen

  • El vencimiento del TTL no autoriza a ignorar al origen; obliga a consultarlo de nuevo. Serve-stale aparece cuando esa consulta no produce una actualización autoritativa y todavía existe un objeto antiguo elegible.
  • La excepción tiene cuatro relojes: respuesta útil al cliente, trabajo total de resolución, reintento después del fallo y edad stale máxima. Cada uno cambia un riesgo distinto y debe observarse en la versión desplegada.
  • El RRset antiguo, el fallo reciente, la validez RRSIG, el TTL corto de salida, el EDE, la actualización que continúa y el resultado de la aplicación son realidades distintas. Mezclarlas convierte una decisión local en una falsa declaración actual de la zona.

Un certificado nuevo detrás de una negación vieja

Una empresa prepara un cambio de certificado y publica un nuevo registro TLSA. Durante la ventana, uno de sus resolvers corporativos pierde acceso a todos los servidores autoritativos. En caché queda un NSEC expirado que cubría el nombre antes de que existiera el TLSA.

El resolver puede fallar de forma visible o usar la negación antigua. La segunda opción evita una demora y parece una respuesta DNS completa, pero impide ver el dato de seguridad recién publicado. La continuidad de una ausencia pasada puede frustrar precisamente la reparación que la autoridad intentaba introducir.

El ejemplo muestra por qué serve-stale no es sólo una técnica para conservar direcciones web. Una caché ejecuta afirmaciones positivas, inexistencia, delegaciones, alias y material de seguridad. Después del TTL, la pregunta de gobierno es qué historia puede seguir actuando mientras el presente no puede ser consultado.

El TTL marca el cambio de responsable

RFC 1035 describió el TTL como el intervalo antes de consultar de nuevo la fuente y descartar normalmente el RR. RFC 2181 lo aclaró como tiempo máximo de vida. RFC 8767 modifica la definición: una vez vencido, la fuente debe ser consultada; si no se puede refrescar autoritativamente, el registro puede usarse como no vencido bajo las condiciones del mecanismo.

La excepción no empieza al insertar el dato ni al activar una opción. Empieza después de una obligación concreta de refresco que no obtiene información útil. Responder siempre desde la caché antigua y preguntar luego convertiría la excepción en política ordinaria y haría irrelevante el TTL elegido por el editor.

TTL cero conserva su significado estricto: uso en la transacción en curso, sin caché y sin futuro stale. También hay que separar el límite aplicado al TTL original — RFC 8767 recomienda alrededor de siete días — del máximo stale posterior. Son dos decisiones de dos actores distintos.

Cuatro presupuestos temporales

El temporizador de respuesta del cliente decide cuánto tiempo se intenta una respuesta fresca antes de que el cliente deje de esperar. El ejemplo propone 1,8 segundos. Reducirlo favorece latencia, pero confunde lentitud con indisponibilidad; ampliarlo preserva frescura, pero puede producir una respuesta inútilmente tardía.

El temporizador de resolución limita el trabajo recursivo completo, normalmente del orden de diez a treinta segundos en la discusión del RFC. Debe continuar después de enviar la respuesta stale. Dar servicio y reparar estado son dos compromisos paralelos.

El temporizador de reintento del fallo evita que cada consulta repita un error conocido. Un fallo reciente permite consultar inmediatamente la caché antigua hasta el siguiente intento. El ejemplo habla de no reintentar más de una vez cada treinta segundos y de un techo de cinco minutos. RFC 9520 exige cachear fallos entre un segundo y cinco minutos y recomienda backoff.

El temporizador stale máximo limita cuánto sobrevive el objeto después del TTL. Se sugieren uno a tres días. Aumentarlo mejora resistencia a cortes largos, pero extiende la capacidad de una dirección abandonada, una delegación anterior o una negación antigua para producir efectos.

Los cuatro relojes necesitan instantes y resultados, no sólo valores. ¿Hubo intento antes de responder? ¿Se reutilizó un fallo ya cacheado? ¿Siguió el fetch en segundo plano? ¿El objeto fue reemplazado o expulsado? Dos nodos con la misma bandera pueden responder de manera opuesta.

Una actualización válida no es cualquier respuesta

RFC 8767 establece que una respuesta autoritativa con AA y RCODE NOERROR o NXDOMAIN refresca el estado. Otros RCODE normalmente representan fallo y dejan intacta la memoria anterior.

Esto protege el último valor útil frente a SERVFAIL transitorio. También impide que el resolver se convierta en juez de una eliminación: un NXDOMAIN nuevo y autoritativo puede sustituir una respuesta positiva antigua. No hay señal fiable para distinguir una retirada intencionada de un error operativo.

REFUSED puede significar política, ACL defectuosa o servidor que ya no es autoridad. El RFC permite decidir si un REFUSED de todas las autoridades debe impedir stale. Esa semántica debe registrarse por producto y release.

RFC 9520 añade otro objeto: el fallo de resolución cacheado. Mientras vive, suprime consultas salientes equivalentes. No afirma nada sobre la existencia del nombre. El ledger debe mostrar a la vez el dato expirado y el fallo vigente que justifica no volver a consultar en cada petición.

El TTL de treinta segundos es una proyección local

La respuesta stale debe asignar a cada RR expirado un TTL mayor que cero; se recomiendan treinta segundos. No es tiempo autoritativo recuperado. Es la breve facultad que el resolver concede a cachés downstream para reutilizar su propia proyección antigua.

Por eso una captura con TTL=30 no basta. Debe relacionarse con TTL original, inserción, vencimiento ordinario, edad stale, causa del fallback y reloj de salida. El mismo número puede pertenecer a un dato fresco casi vencido o a un dato antiguo de horas.

RFC 8914 define EDE 3 para Stale Answer y EDE 19 para Stale NXDOMAIN. EDE 7 describe Signature Expired. La información añade diagnóstico, pero no modifica el RCODE ni obliga al stub a tomar una acción. Si un forwarder elimina la opción, el cliente sólo verá éxito o negación. La trazabilidad debe seguir la EDE por cada salto.

Lo negativo también ejecuta política

Una respuesta A antigua conserva un destino. Un NXDOMAIN antiguo impide uno nuevo. Un NSEC o NSEC3 stale puede ocultar un DS o TLSA recién publicado. El fallo visible se transforma en una negación rápida, de modo que los equipos pueden buscar el problema en la aplicación y no en el resolver.

La elegibilidad debe reconocer clases de cambio. Migración de contenido, revocación, validación de certificado, delegación y creación de un nombre de emergencia tienen costes stale distintos. Si la implementación sólo ofrece un control global, la decisión prudente puede ser no habilitarlo en resolvers que sirven flujos de alta consecuencia.

La observación necesita positivos, NXDOMAIN y NODATA por separado. “Stale answer” como contador único oculta si el mecanismo mantiene reachability o prolonga inexistencia.

DNSSEC no acepta el reloj del caché

RFC 4035 exige que el tiempo actual del validador se encuentre entre inception y expiration del RRSIG. Mantener bytes después del TTL no amplía esa ventana. El objeto puede ser stale y aún validable, o stale con firma ya vencida.

Registrar sólo AD o “DNSSEC enabled” es insuficiente. Se necesitan estados separados: stale con firma vigente, stale con firma expirada, fallo de validación cacheado y cualquier excepción insegura local. El máximo stale y la fecha de la firma pueden terminar en órdenes distintos.

Un adversario que mantiene inaccesibles las autoridades puede intentar prolongar una dirección o negación antiguas. RFC 8767 advierte sobre direcciones ya fuera del control del titular y fraude de certificados validados por dominio. El mecanismo no crea el abandono, pero cambia cuánto puede actuar durante el fallo.

BIND y Unbound convierten el nombre en comportamientos distintos

La documentación actual de BIND separa retención, respuesta, TTL de salida, máximo stale, intervalo de refresco y control runtime mediante rndc serve-stale. Documenta treinta segundos de TTL de respuesta y un día de retención máxima cuando está activo. Su opción de espera al cliente está desactivada por defecto y la versión documentada sólo admite cero al activarla, es decir, respuesta inmediata.

Unbound usa serve-expired-* para edad, TTL de respuesta, espera y reset tras fallo. Su documentación distingue el modo inmediato del modo que primero intenta resolver. Los defaults y cambios de release son parte de la evidencia de producto.

La matriz canary debe incluir autoridad rápida, lenta, inalcanzable, SERVFAIL, REFUSED, NXDOMAIN; dato positivo y negativo; RRSIG vigente y vencido; TTL cero; presión de caché; reinicio; override. Se observa el paquete recibido y enviado, no el éxito del comando.

Fuentes