Resumen

  • RFC 10037 define el miembro opcional ttl0_data para objetos de dominio y servidor de nombres en RDAP.
  • El TTL publicado procede de la configuración del registro; no es la vida restante observada en una consulta DNS.

El mismo número puede responder preguntas distintas

RDAP ya podía mostrar servidores de nombres, direcciones glue y registros DS asociados a un dominio. No ofrecía los TTL de esos RRsets. Esa ausencia impedía ver una parte de la intención operativa: cuánto tiempo se permite reutilizar un conjunto antes de volver a consultarlo.

La nueva extensión incorpora un objeto ttl0_data. Dentro de él, values relaciona mnemónicos de tipos DNS con valores TTL, y el servidor puede añadir observaciones de RDAP. La publicación es voluntaria. Cuando aparece, la respuesta debe declarar ttl0 en rdapConformance.

La regla central evita una interpretación equivocada. El valor debe reflejar el TTL aprovisionado en la base del registro, no el contador restante de una respuesta obtenida del DNS. Ver 3.600 significa que el registro representa una hora para ese RRset. No demuestra que todos los servidores autoritativos ya la sirvan, que las cachés hayan recibido el cambio ni que queden exactamente 3.600 segundos.

La utilidad surge de mantener separadas esas capas. En una avería, un operador puede comparar el estado registrado, las respuestas autoritativas y lo retenido por un resolutor recursivo. Si discrepan, la investigación puede distinguir entre aprovisionamiento, publicación, propagación y caché. RDAP aporta evidencia fuera de banda; no se convierte en telemetría del DNS.

La norma fija el significado, no obliga a publicar

El operador del registro conserva la decisión de exponer ttl0_data. Una vez expuesto, el formato queda delimitado: los tipos deben estar registrados en IANA y escribirse en mayúsculas; el TTL pertenece al RRset; y el valor JSON debe ser un entero de cero a 2.147.483.647, sin fracciones ni exponentes.

Esa distribución de autoridad importa. El estándar define el vocabulario y la señal de conformidad. El registro controla la disponibilidad del dato y el valor representado en su base. El cliente decide cómo interpretarlo. Ninguno obtiene control sobre el DNS en vivo por el mero hecho de intercambiar la información.

Registradores, titulares, proveedores DNS y equipos de incidentes ganan una referencia común sin acceso privilegiado al sistema interno del registro. Sin embargo, RFC 10037 no certifica que la base esté actualizada, que el cambio fuese autorizado ni que la zona publicada coincida con ella.

Un esquema abierto exige clientes menos rígidos

Los clientes deben aceptar cualquier tipo DNS válido que aparezca en values, también los registrados en el futuro. Los marcos que convierten JSON en clases cerradas pueden rechazar una respuesta correcta. Por eso la especificación recomienda aislar este mapa dinámico y mantener actualizada la lista de tipos válidos de IANA.

La extensión RDAP también es independiente de la extensión EPP de RFC 9803. Un registro puede publicar el valor sin implantar el mecanismo EPP para aprovisionarlo. La visibilidad no revela quién eligió el TTL ni quién puede modificarlo. Las implicaciones de determinar, asignar o cambiar esos valores quedan fuera del alcance de RFC 10037.

Evidencia, contrafactual e incógnitas

Sin la extensión, RDAP seguiría mostrando registros DNS relacionados, pero no los TTL configurados por el registro. Los operadores dependerían del DNS en servicio o de canales propios del registro y carecerían de una referencia normalizada fuera de banda. Es un contrafactual derivado del alcance de las especificaciones, no un resultado medido.

Las fuentes primarias no establecen cuántos registros usan ttl0_data, si reduce el tiempo de los incidentes, si la exposición es uniforme entre objetos ni si modifica la conducta de clientes o registros. Tampoco prueban la exactitud de una implementación concreta en un momento determinado. Esos resultados siguen siendo desconocidos.

Fuentes