Resumen

  • RFC 8767 permite que un resolver recursivo entregue una copia vencida cuando no logra actualizarla de buena fe desde la autoridad; la continuidad es una decisión local del resolver, no una prórroga de la vigencia declarada por la zona.
  • Para auditarla hay que conservar por separado el TTL original, la edad vencida, el límite máximo, el TTL de la respuesta, la validez DNSSEC, la clase de fallo, el grupo de resolvers afectado y la recuperación.

La retirada ya consta en la zona. Un equipo ha eliminado la dirección de un servicio comprometido y el TTL anterior llega a cero. Sin embargo, una parte de los usuarios sigue recibiendo la dirección vieja. Sus resolvers no han ignorado necesariamente la actualización: no han podido llegar a los servidores autoritativos y han preferido una respuesta vencida al error.

Es un caso hipotético. No atribuye el comportamiento a un operador ni afirma que una configuración concreta sea habitual. Sirve para hacer visible una decisión que normalmente queda dentro de la caché.

RFC 8767 llama Serve Stale al uso excepcional de datos expirados para sostener la resolución cuando falla la actualización autoritativa. La idea protege disponibilidad ante cortes y ataques. Pero el hecho de que una copia siga siendo útil no significa que el editor de la zona siga respaldando su actualidad.

La caducidad no desaparece: cambia el dueño de la decisión

Mientras el TTL está vigente, el resolver reutiliza el RRset dentro del plazo ordinario publicado por la zona. Al vencer, debe volver a consultar la fuente. RFC 8767 permite que, si no consigue una actualización autoritativa, use la copia retenida como si aún no hubiera expirado.

Ese “como si” describe una excepción operativa. No reescribe el TTL que publicó la autoridad. El operador recursivo asume la facultad de prolongar el uso y, por tanto, debe asumir su alcance, observabilidad y salida.

Hay dos topes diferentes. El TTL máximo de caché puede reducir un valor recibido demasiado alto; el RFC recomienda un orden de días o semanas y menciona siete días. El temporizador máximo de datos vencidos empieza al terminar la vida normal y limita cuánto tiempo más se conserva la copia como candidata. El texto lo deja configurable y explica que uno a tres días puede cubrir muchas interrupciones. Ninguna de esas cifras es una política obligatoria para todos.

Por eso no basta con capturar el TTL que ve el cliente. Una respuesta stale suele salir con un nuevo TTL corto. La evidencia debe incluir el instante de inserción, el TTL original, la hora de vencimiento, la edad exacta, el máximo configurado y el TTL enviado. Sin esa cadena, treinta segundos visibles pueden parecer datos recién publicados cuando en realidad describen la pausa concedida a una copia de horas o días.

Cuatro relojes protegen intereses distintos

RFC 8767 evita imponer un algoritmo único y ofrece un método de ejemplo con cuatro temporizadores.

El temporizador de respuesta al cliente limita cuánto se espera antes de acudir a lo vencido; propone 1,8 segundos como valor cercano pero inferior a un timeout frecuente de dos segundos. El temporizador de resolución limita todo el trabajo iterativo, a menudo entre diez y treinta segundos. El de nueva comprobación evita repetir demasiado rápido una consulta ya fallida y recomienda treinta segundos en el ejemplo. El máximo stale decide cuándo la copia deja de ser elegible aunque el fallo continúe.

Un único indicador de “stale habilitado” oculta esos compromisos. Reducir la espera del cliente mejora la experiencia, pero puede servir información vieja cuando la autoridad solo responde despacio. Espaciar las comprobaciones contiene la carga durante una caída, pero retrasa el reconocimiento de la vuelta. Alargar la retención salva incidentes prolongados, pero amplía la vida de configuraciones abandonadas.

Antes de servir la copia debe existir un intento reciente y honesto de actualización. El mecanismo no convierte toda respuesta en “usar primero la caché vieja y preguntar después”. Y si la respuesta vencida sale al agotarse el reloj del cliente, el proceso de resolución debe seguir hasta su propio límite. La continuidad no cancela la obligación de recuperar la fuente.

Un fallo de actualización necesita apellido

Según RFC 8767, una respuesta autoritativa NOERROR o NXDOMAIN con AA actualiza el estado. La segunda posibilidad puede resultar contraintuitiva: si antes había un nombre y ahora la autoridad afirma que no existe, el resolver no debería conservar indefinidamente la respuesta positiva porque le parezca más útil. No puede distinguir de forma general una retirada legítima de un error editorial.

Los demás fallos tampoco son equivalentes. Un timeout, una ruta inalcanzable, SERVFAIL, REFUSED, un mensaje inválido, una delegación rota o un fallo DNSSEC señalan superficies diferentes. RFC 2308 limita además a cinco minutos la memoria de indicaciones de servidor fallido o muerto.

El expediente debe registrar cada destino autoritativo, dirección, transporte, momento, RCODE, AA, validación y error de red. También debe conservar RD, CD y DO, el nombre, tipo y clase, la clave de caché y si se trataba de una respuesta positiva, NODATA o NXDOMAIN. Dos resolvers con políticas e historiales diferentes pueden producir respuestas distintas sin que ninguno haya violado su configuración.

Treinta segundos no convierten lo viejo en nuevo

Un resolver que devuelve registros expirados debe asignarles un TTL mayor que cero; RFC 8767 recomienda treinta segundos. El cero ha causado problemas de interoperabilidad y un valor diminuto puede provocar una avalancha de reintentos. El pequeño TTL sirve para frenar la demanda aguas abajo.

No renueva el compromiso del editor. Si un forwarder recibe la respuesta y la guarda, el TTL visible ya no revela la edad real. Para reconstruir la decisión hacen falta la identidad del resolver que originó la respuesta stale, el momento de su copia y su último intento de actualización.

RFC 8914 aporta los errores DNS extendidos. El código 3 identifica una respuesta stale; el 19, un NXDOMAIN stale; el 22, la ausencia de autoridad alcanzable. Pueden acompañar incluso a NOERROR y ofrecen contexto útil.

Pero un EDE no modifica el RCODE ni obliga a una aplicación a cambiar el procesamiento. Un intermediario puede no reenviarlo o crear otro. Sin una transacción o canal protegido, tampoco está autenticado. Es una declaración diagnóstica del emisor, no una prueba independiente de la edad de la caché ni de los intentos realizados.

La firma sigue otro calendario

La validación DNSSEC que tuvo éxito al insertar un RRset no dura por memoria. Los tiempos de inicio y expiración del RRSIG son independientes del TTL y de la ventana máxima stale. Al conservar una copia más allá de su vida ordinaria aumenta la posibilidad de que la firma ya no sea válida.

El bit AD debe representar la validación actual. El historial debería guardar tiempos del RRSIG, instante de comprobación, anclas de confianza y estado CD/DO. Y aun una dirección vieja con firma válida puede conducir a infraestructura que el editor ya no controla: autenticidad criptográfica y seguridad presente del destino son afirmaciones distintas.

Los negativos multiplican el riesgo. Un NXDOMAIN vencido puede ocultar un nombre recién creado. Un NSEC o NSEC3 antiguo puede retrasar la aparición de DS o TLSA. RFC 8198 permite sintetizar respuestas desde pruebas negativas validadas que aún están dentro de su régimen de caché. Serve Stale plantea el paso adicional: si el material ya expiró, ¿puede seguir utilizándose porque la actualización falla?

Fuentes