Resumen

  • RFC 8767 permite que un resolutor recursivo use determinados datos caducados si no logra actualizarlos desde una fuente autoritativa; los datos recibidos con TTL cero quedan fuera de esta excepción.
  • El beneficio de disponibilidad desplaza temporalmente una parte del control: el operador de zona publicó el TTL, pero el operador del resolutor define cuánto espera, qué considera un fallo y durante cuánto tiempo conserva la respuesta antigua.
  • Los códigos EDE pueden indicar que una respuesta es stale, aunque esa señal es diagnóstica, no autentica los datos y no sustituye una política explícita de riesgo.

Análisis

Supongamos que una organización retira una dirección IP y publica otra. Los resolutores que reciben el cambio a tiempo dejan de utilizar la antigua. Pero uno de ellos llega al final del TTL cuando todos los servidores autoritativos están inaccesibles. La dirección anterior puede seguir atendiendo tráfico y evitar una interrupción. También puede pertenecer ya a otra infraestructura o mantener abierto un camino que el titular del dominio intentó cerrar.

El TTL convierte esa incertidumbre en una frontera operativa. RFC 1035 lo describió como el intervalo durante el cual un registro puede permanecer en caché antes de volver a consultar su fuente y descartarlo. RFC 2181 aclaró que es un tiempo máximo, no una obligación de conservar el dato hasta el último segundo. En condiciones normales, la zona publica la duración y el resolutor deja de reutilizar la respuesta al terminarla.

RFC 8767 introduce una excepción para el fallo de actualización. Cuando el resolutor no puede obtener datos autoritativos actuales después del vencimiento, puede conservar el registro y tratarlo como si siguiera vigente. La excepción no convierte el caché viejo en la primera opción permanente. El resolutor debe haber realizado recientemente un intento de buena fe por actualizar y, aun después de contestar con datos stale, debe continuar la resolución hasta agotar su temporizador total.

Un TTL de cero sigue siendo una orden distinta. Ese registro sólo se puede usar en la transacción en curso y no puede guardarse como futuro respaldo. Si se devuelve un registro caducado, el mensaje debe asignarle un TTL superior a cero. El valor recomendado es 30 segundos, suficiente para evitar defectos conocidos alrededor de TTL cero y para limitar la repetición inmediata de consultas por cachés posteriores.

La arquitectura separa cuatro relojes. El temporizador de respuesta al cliente fija cuánto tiempo espera el usuario antes de que el resolutor considere una respuesta vieja; el método de ejemplo sitúa ese punto cerca de 1,8 segundos. El temporizador de resolución limita el trabajo total para hallar información nueva. El temporizador de reintento ante fallos controla la frecuencia con la que se vuelve a probar una autoridad problemática. El máximo stale establece cuánto tiempo puede conservarse un registro después de caducar, con un intervalo sugerido de uno a tres días.

No existe una única configuración obligatoria. RFC 8767 presenta serve-stale como una operación local y permite que cada implementación u operador elija sus variables. Dos resolutores conformes pueden tratar el mismo nombre de forma diferente durante la misma avería. Uno puede devolver la antigua dirección; otro, un error. La diferencia no es sólo técnica: expresa qué riesgo —interrupción u obsolescencia— se ha autorizado a asumir.

La respuesta autoritativa determina cuándo termina esa autoridad temporal. Una respuesta NoError o NXDomain con el bit AA actualiza el estado y sustituye la información anterior. Otros códigos de respuesta normalmente no afirman qué existe en ese nombre, por lo que se consideran fallos de actualización y dejan intacto el caché previo. SERVFAIL no confirma la validez de la dirección vieja. Sólo demuestra que no se obtuvo una respuesta actual útil.

El caché de fallos de resolución de RFC 9520 cumple otra función. El estándar obliga a guardar esos fallos al menos un segundo y como máximo cinco minutos, impidiendo que consultas coincidentes repitan trabajo ascendente mientras la entrada esté vigente. Allí se conserva el fracaso del proceso. En serve-stale se conserva una respuesta expirada. Uno reduce la tormenta de reintentos; el otro determina qué datos recibe el usuario. Medir ambos como una sola clase ocultaría la decisión sobre frescura.

RFC 8914 permite identificarla. El código Extended DNS Error 3 corresponde a Stale Answer y el 19 a Stale NXDOMAIN Answer. Son etiquetas operativas valiosas, pero no una fuente de autoridad adicional. EDE no está autenticado salvo que la transacción DNS esté protegida, y su contenido no debe cambiar el procesamiento del protocolo. La señal dice por qué el resolutor contestó; no demuestra que la respuesta antigua siga siendo segura.

El coste depende del tipo de registro y del momento. Un A o AAAA anterior puede sostener un servicio que no cambió, o enviar usuarios a un destino ya retirado. Un CNAME puede reactivar una dependencia eliminada. RFC 8767 advierte además que las firmas pueden vencer, que datos NSEC o NSEC3 stale pueden retrasar nuevos registros TLSA o DS y que un atacante capaz de impedir el acceso a las autoridades podría prolongar la vida práctica de información vieja.

Estos son límites documentados por los estándares, no pruebas sobre el comportamiento de un operador concreto. El paquete de hechos no atribuye adopción, configuración, ahorro de caídas ni daño a ninguna flota identificada. Sí permite reconstruir la cadena de control: la zona publica los datos y el TTL; el resolutor clasifica el fallo, configura los relojes y elige la excepción; el cliente recibe el resultado.

Fuentes