Resumen

  • RFC 8767 permite conservar y devolver datos DNS caducados solo como alternativa acotada cuando un intento reciente y genuino no obtiene datos autoritativos utilizables.
  • El TTL original, el máximo de antigüedad, la espera del cliente, el TTL de la respuesta, la vigencia de la firma, EDE y los reintentos son relojes distintos; ninguno renueva al otro.
  • David C. Lawrence figura entre tres autores de la RFC. Esa contribución colectiva no concede autoridad operativa ni al autor ni al resolvedor que conserva la copia.

Un usuario abre una aplicación en el peor segundo posible. El registro que necesita acaba de agotar su TTL y los servidores autoritativos no responden dentro del tiempo disponible. La memoria del resolvedor aún contiene la dirección anterior. Borrarla produce un fallo inmediato; devolverla puede mantener el servicio. Ambas decisiones tienen coste.

El error conceptual aparece cuando la segunda opción se contabiliza como una respuesta corriente. El cliente recibe una dirección y el indicador de disponibilidad se mantiene verde, pero la fuente del nombre sigue ausente. El dato es útil y está vencido a la vez.

RFC 8767, publicada en marzo de 2020 y escrita por David C. Lawrence, Warren Kumari y Puneet Sood, convierte esa contradicción en una secuencia comprobable. No borra la función del TTL. Define cuándo la continuidad puede usar una copia sin convertir al caché en autoridad suplente.

El caché puede guardar más de lo que puede afirmar

RFC 1035 introduce el TTL como el período durante el cual un recurso puede conservarse en caché. RFC 2181 aclara que ese límite debe respetarse al usar el dato. Cuando vence, el resolvedor debe consultar de nuevo la fuente para afirmar actualidad.

La estructura interna puede conservar el RRset después de ese momento. Guardarlo permite diagnósticos, comparaciones y una salida de emergencia. Sin embargo, la posesión de los bytes no es permiso para responder. RFC 8767 crea una condición adicional que debe satisfacerse antes del uso.

Hay además una exclusión absoluta: un registro recibido con TTL cero no entra en serve-stale. La zona señaló que no debía reutilizarse. Darle después un período de gracia sería inventar una política contraria a la instrucción original.

Por eso la prueba empieza al insertar el dato, no durante la avería. Debe conservar el nombre, tipo, clase, servidor de origen, valor, TTL recibido, instante de entrada, expiración ordinaria y resultado DNSSEC. La frase «último dato bueno» carece de significado si no se puede identificar ese objeto y su edad.

La copia no gana una carrera que la fuente no tuvo ocasión de correr

RFC 8767 exige un intento reciente de buena fe. El resolvedor consulta el camino autoritativo y espera hasta el límite definido para el cliente. Solo si no obtiene una respuesta utilizable pasa al estado antiguo. Cuando otro intento muy reciente ya demostró el fallo ascendente, las siguientes consultas pueden evitar repetir toda la espera.

La regla impide que la comodidad del caché derrote cambios urgentes. Si la zona retira una dirección, mueve un servicio o modifica un desafío DNS, un resolvedor sano debe verlo cuando la fuente está disponible. Responder primero con el dato vencido aunque la autoridad funcione sería alargar unilateralmente el estado anterior.

El intento debe poder auditarse: destinos, transporte, hora, duración, respuesta, error, estado DNSSEC y memoria de fallo empleada. Un timeout no equivale a NXDOMAIN; SERVFAIL no equivale a una respuesta negativa firmada; una firma inválida no equivale a un servidor inalcanzable.

La entrega de una copia antigua tampoco termina el incidente. RFC 8767 ordena seguir resolviendo. La recuperación se demuestra cuando llega una respuesta autoritativa actual, se valida según la política y reemplaza el estado excepcional. Mientras tanto, la aplicación dispone de continuidad, pero la fuente no está reparada.

La política distribuye el tiempo entre relojes independientes

El primer reloj es el TTL que publicó la autoridad. Describe frescura ordinaria. El texto de RFC 8767 sugiere limitar a siete días el TTL recibido usado para ciertos cálculos, con el fin de que un valor enorme no dé lugar a retención indefinida.

El segundo es la duración máxima durante la que el resolvedor admite una copia vencida. Debe ser configurable y la RFC propone un orden de uno a tres días como valor inicial. Cruzar ese límite elimina la elegibilidad, aunque el almacenamiento físico siga intacto.

El tercero es la paciencia del cliente. Puede ser de unos segundos y determina cuándo el intento autoritativo cede el turno a la alternativa. Un umbral corto reduce la demora, pero también convierte más respuestas simplemente lentas en uso antiguo.

El cuarto es el TTL que acompaña a la respuesta servida. Debe ser mayor que cero y se recomiendan treinta segundos. Su función es acotar la reutilización descendente. No rejuvenece el registro ni desplaza su expiración original.

El quinto pertenece a DNSSEC. RRSIG tiene fechas propias. Una firma puede seguir siendo válida después de vencer el TTL del RRset, o caducar antes de agotar la ventana local de serve-stale. Ningún ajuste de caché amplía una firma.

El sexto gobierna los reintentos y su retroceso. Intentar con demasiada frecuencia agrava una caída autoritativa; esperar demasiado prolonga la sustitución. Una revisión correcta muestra los seis tiempos, no una sola columna llamada «TTL viejo».

DNSSEC prueba origen histórico, no intención presente

Según RFC 4035, el resolvedor validante comprueba la cadena y el intervalo temporal de la firma. Un RRset vencido puede continuar como Secure mientras la firma y su cadena sigan siendo válidas. Esa evaluación dice que el propietario firmó el dato; no dice que aún quiera publicarlo hoy.

RFC 8767 advierte que el envejecimiento aumenta la posibilidad de fallos de validación. También reconoce un ataque más sutil: quien mantiene fuera de servicio a la autoridad puede conseguir que otros continúen usando un dato anterior. No rompe la criptografía; explota el intervalo entre autenticidad y actualidad.

El consumidor cambia la gravedad. Para cargar temporalmente una página puede aceptarse una dirección anterior. Para emitir un certificado, conceder acceso o ejecutar una operación difícil de deshacer, la misma respuesta puede ser inadecuada. La RFC pide a las autoridades de certificación que no dependan de un resolvedor que sirva datos antiguos para su validación DNS.

La antigüedad también afecta a las ausencias. Una respuesta positiva vencida puede apuntar a un servicio retirado. Un NXDOMAIN vencido puede ocultar un nombre recién creado. RFC 8914 separa Stale NXDOMAIN Answer porque decir «no existe» también requiere actualidad.

EDE revela la excepción, pero no la justifica

RFC 8914, de la que Lawrence también es coautor, asigna el código 3 a Stale Answer y el 19 a Stale NXDOMAIN Answer. El resolvedor puede adjuntar esa información para que un cliente preparado sepa que recibió una alternativa vencida.

El código no modifica por sí solo el RCODE, no firma la respuesta, no prueba el motivo del fallo, no extiende RRSIG y no obliga a la aplicación a leerlo. Es habitual que el software consuma la dirección sin exponer el EDE al usuario.

Su valor está en actuar como testigo. Permite desglosar telemetría y aplicar políticas específicas. Pero necesita el resto del expediente: objeto de caché, intento autoritativo, edad, condición de elegibilidad, TTL de salida, validación y recuperación posterior.

Un operador que solo cuenta códigos 3 sabe cuántas veces declaró una excepción, no si cada declaración cumplió la regla. La relación causal debe conservarse por consulta o por decisión agregada verificable.

Los programas materializan decisiones que la norma no centraliza

RFC 8767 relata un parche inicial para BIND 9.7.0, uso de producción comunicado por Akamai desde 2011 y soporte posterior en BIND 9.12, Unbound y Knot Resolver. La experiencia acumulada mostró que una copia acotada podía mejorar resiliencia.

No estableció una configuración universal. La documentación vigente de Unbound dice que el comportamiento RFC 8767 es predeterminado desde la versión 1.23.0. Explica una espera de 1,8 segundos, el uso del dato vencido en lugar de SERVFAIL, un máximo predeterminado de un día, un TTL de treinta segundos y la continuación de las consultas.

Son elecciones de una implementación y una versión. El operador puede modificarlas; otros productos toman decisiones distintas. El nombre de la función no prueba su política efectiva.

La evidencia debe venir de la ejecución. Conviene registrar versión y parámetros y ensayar autoridad sana, silencio, SERVFAIL, fallo DNSSEC, recuperación antes y después del máximo, cambio del valor y TTL cero. La documentación fija expectativas; el paquete observado y la transición interna demuestran lo que ocurrió.

La trayectoria de Lawrence no sustituye el consenso

IETF Datatracker presenta a David C. Lawrence bajo el alias «tale» y enumera RFC 3425, 7871, 8767 y 8914. En la fecha revisada lo registra como copresidente de Adaptive DNS Discovery, enlace del IETF ante la Junta de ICANN y revisor en directorios relacionados con DNS e Internet.

La Junta de ICANN lo identifica como enlace sin voto desde el 14 de noviembre de 2024. Su biografía menciona RPI y Usenet, UUNET, el trabajo de reescritura de BIND en ISC, Nominum, trece años en Akamai, su selección en 2010 como Trusted Community Representative de la clave raíz DNSSEC, DNS-OARC y CVFiber.

El recorrido demuestra participación en implementación, estándares y coordinación. No demuestra invención individual, control de resolutores ni mando sobre decisiones de ICANN. Tres autores firman RFC 8767 y la adopción depende de muchas comunidades.

La precisión institucional coincide con la precisión técnica. Contribuir a un mecanismo no transfiere su operación; conservar una respuesta no transfiere la autoridad del nombre.

El último campo del recibo es la sustitución por dato fresco

El recibo comienza con el RRset y su historia: nombre, tipo, clase, origen, TTL, entrada, vencimiento, huella de contenido y estado DNSSEC. Continúa con el intento reciente: servidores, transporte, tiempos, resultado y cualquier memoria previa de fallo.

La decisión añade el máximo configurado, la fecha límite calculada, la edad, la espera del cliente, el TTL de respuesta, el EDE y el próximo reintento. Si una política excluye cierto tipo de consumidor, esa exclusión también debe aparecer.

El cierre contiene la primera respuesta fresca utilizable, su validación, la huella nueva, el instante de instalación, el retiro de la copia antigua y el efecto visible. Cuando el contenido cambia, no debe borrarse el hecho de que algunos clientes recibieron el valor anterior.

Así se protege el registro de decisiones en vez de investir al intermediario. El resolvedor mantiene la función durante una interrupción, pero la fuente sigue siendo la fuente. La continuidad es defendible mientras la copia conserve edad, procedencia, límite y camino de regreso.

Fuentes