Resumen

  • En RFC 9664 el solicitante propone una duración, pero la respuesta del servidor autoritativo fija el LEASE y el KEY-LEASE que gobiernan renovación y caducidad.
  • El vencimiento limita la publicación en la autoridad; no certifica que el servicio funcione, que todos los servidores coincidan ni que una caché haya olvidado su respuesta.

Un dispositivo solicita, a modo de ejemplo, media hora para publicar un servicio. La actualización pasa sus prerrequisitos, la firma de transacción es válida y el servidor responde NOERROR. En la misma respuesta concede cuatro horas. A los veinte minutos el dispositivo se apaga sin enviar borrado ni renovación.

La dirección sigue siendo una respuesta autoritativa legítima durante el plazo concedido, aunque no haya ninguna aplicación detrás. No es un incidente histórico ni una cifra por defecto. Es una forma sencilla de ver dónde está la potestad temporal: la petición expresa lo deseado; la respuesta exitosa expresa lo otorgado. RFC 9664 permite que sea menos, igual o más.

La aceptación de la escritura no demuestra la vida del destino

Update Lease no inventa una vía nueva para editar zonas. Viaja como opción EDNS(0) dentro de un DNS UPDATE de RFC 2136. La operación conserva las secciones Zone, Prerequisite, Update y Additional Data. Los prerrequisitos se evalúan contra el estado actual y la modificación es atómica.

Esa decisión responde si una identidad puede efectuar un cambio concreto. La concesión responde cuánto tiempo lo publicará el servidor si no hay renovación. La disponibilidad del destino requiere otra prueba.

TSIG y SIG(0) protegen la transacción y permiten identificar al solicitante según la política de claves. No observan el puerto, el proceso, la ruta ni el resultado de una operación de usuario. Tampoco convierten la duración pedida en duración concedida. Por eso la custodia debe guardar el paquete exacto, la identidad criptográfica, el veredicto de política, los valores solicitados, el RCODE y los valores devueltos.

Un campo genérico llamado “lease=ok” elimina justo lo que habrá que reconstruir durante un fallo.

Dos formatos y dos clases de persistencia

La opción corta lleva cuatro octetos: un LEASE de 32 bits aplicable a todos los RR de la sección Update. La opción larga lleva ocho: LEASE para los registros ordinarios y KEY-LEASE para los KEY.

La separación tiene un uso claro en el Service Registration Protocol de RFC 9665. Un servicio puede dejar de anunciarse mientras la KEY conserva durante más tiempo el derecho del mismo poseedor criptográfico sobre el nombre. La reserva impide una reasignación inmediata; no dice que el equipo siga conectado.

La interoperabilidad con implementaciones antiguas puede unir ambos plazos. Quien recibe cuatro octetos debe aplicar el único valor también a la KEY. Incluso un solicitante que envió ocho y obtuvo cuatro tiene que aceptar esa interpretación. La intención local de “servicio breve, nombre duradero” solo está probada si la forma efectiva de la respuesta la mantiene.

Los RR eliminados explícitamente no esperan al fin del alquiler: quedan eliminados de manera permanente. Caducar y borrar son decisiones distintas.

Renovar es otra operación observable

Un servidor compatible que acepte una actualización con la opción debe devolverla con la duración real. El cliente programa la renovación al 80 % de lo concedido más un componente aleatorio de 0 a 5 %. La dispersión reduce oleadas sincronizadas y deja aproximadamente entre 15 y 20 % del tiempo para reintentos.

El temporizador calculado no acredita una renovación. Hacen falta la hora prevista, el desplazamiento aleatorio, los envíos, la respuesta autenticada y la nueva concesión. Si el servidor cambia su política entre ciclos, el próximo reloj también cambia.

Una respuesta sin Update Lease indica que el servidor no ofrece la función. RFC 9664 aconseja que el cliente continúe renovando como si se hubiese devuelto lo pedido. Esta tolerancia es útil para compatibilidad, pero no prueba que el servidor vaya a retirar el RR al vencer. Debe quedar marcado como “renovación cliente activa; caducidad servidor no demostrada”.

Registro y renovación tampoco son sinónimos. El primero agrega información que se supone ausente; el segundo prolonga una inscripción sin cambiarla. Si un reinicio hizo perder estado al servidor, una renovación construida con cuidado puede volver a añadir los RR. Entonces cambia el contenido de la zona y debe cambiar el serial. Cuando no cambia el contenido, el serial no debe incrementarse.

Cuatro relojes para una sola respuesta

Al agotarse el plazo sin renovación, el servidor debe dejar de devolver el RR. Puede borrar físicamente los datos, pero no está obligado. Una consulta negativa no prueba que los bytes hayan desaparecido; una fila almacenada tampoco prueba que todavía sea publicable.

El TTL funciona en otra capa. Un recursor que recibió la respuesta poco antes de caducar el alquiler puede reutilizarla hasta consumir su TTL restante. El servidor autoritativo no puede retirar esa copia. Del mismo modo, un TTL de segundos no hace expirar el registro que la autoridad ha arrendado por horas.

La investigación debe separar: vencimiento concedido; ventana de renovación y reintentos; actualización del serial, firmante y secundarios; y TTL observado por cada caché. Si el registrador es un primario oculto, su tabla interna no demuestra lo que responde cada nodo público o sitio anycast.

La última capa es el servicio. Una consulta DNS correcta solo prueba publicación. Hay que conectar al protocolo, dirección y puerto anunciados y ejecutar una comprobación significativa.

La política de duración pertenece al operador

Un plazo excesivo deja datos viejos casi indefinidamente. Uno demasiado corto sobrecarga renovaciones y convierte un retraso normal en desaparición prematura. RFC 9664 recomienda límites máximos por defecto de 24 horas para LEASE y siete días para KEY-LEASE; exige un mínimo por defecto y recomienda 30 segundos, aunque señala que normalmente convienen valores mucho mayores, como una hora. Los operadores pueden modificarlos.

No son derechos del solicitante ni un SLO universal. Son una invitación a hacer explícita la política local. La misma prudencia vale para las claves: deben poseer autoridad limitada. Un alquiler acaba; una clave excesivamente poderosa puede alterar mucho más que un registro transitorio.

Fuentes