Resumen

  • RFC 9083 define delegationSigned como verdadero cuando existen registros DS en el padre; zoneSigned y los datos DS o de clave son componentes separados del objeto RDAP secureDNS.
  • El campo es evidencia registral, no un resultado de validación en vivo. Una conclusión DNSSEC defendible también necesita el DS actual del padre, DNSKEY y RRSIG de la zona hija, disponibilidad autoritativa, validez temporal y el resultado de un validador identificado.

Un booleano preciso con alcance estrecho

La respuesta de LACNIC examinada para 84.7.200.in-addr.arpa es clara sobre lo que expone. Es un objeto de clase domain. Enumera tres servidores de nombres y un objeto secureDNS donde zoneSigned y delegationSigned son falsos, con un arreglo dsData vacío.

Ese contenido es evidencia útil sobre el registro devuelto por LACNIC en el momento de observación. No permite generalizar a todas las zonas inversas de la región ni describe el estado operativo actual de los servidores listados. La respuesta no contiene una traza de resolución ni los paquetes necesarios para reconstruirla.

La presencia del DS padre es solo un eslabón

RFC 9083 mantiene separados los significados. zoneSigned indica si la zona está firmada. delegationSigned indica si existen registros DS en el padre. dsData puede describir la etiqueta de clave, el algoritmo, el resumen y su tipo, mientras que keyData puede incluir material DNSKEY.

Esos campos describen datos de registro. La validación DNSSEC es una operación sobre una cadena de respuestas DNS en vivo y en un momento determinado. El validador obtiene el DS del padre, recupera la DNSKEY y los registros firmados de la zona hija, compara resúmenes y algoritmos, comprueba firmas y ventanas temporales y procesa errores de alcance o de respuesta. Un booleano RDAP no ejecuta esos pasos de forma implícita.

Tanto verdadero como falso exigen cautela

Si delegationSigned es verdadero, la afirmación sustentable es que la representación RDAP informa DS en el padre. No demuestra que la zona hija publique la DNSKEY correspondiente, que las firmas estén vigentes, que la cadena alcance un ancla de confianza ni que un resolvedor concreto valide con éxito.

Si el valor es falso, la representación informa la ausencia de DS en el padre según la definición del campo. No establece por qué están ausentes, si existe un cambio pendiente ni si otra observación hecha más tarde coincidirá. Deben conservarse la URL, los bytes y la hora de la respuesta.

Dos superficies para una prueba reproducible

La superficie registral debe guardar la URL exacta del dominio RDAP, ldhName, la lista de servidores, los valores secureDNS, los arreglos DS o de claves, el hash de la respuesta y la hora de obtención. La superficie operativa debe conservar por separado las consultas DNS al padre y a la zona hija, las direcciones de servidor, códigos de respuesta, banderas de autoridad, registros DNSKEY, DS y RRSIG, salida del validador y contexto de reloj.

Solo después de comparar ambas superficies puede describirse la validación actual. Incluso entonces, el resultado corresponde al punto y al momento de observación identificados. Que la cadena criptográfica funcione no prueba propiedad, autoridad contractual ni control de los equipos.

Fuentes