Summary

  • RFC 9083 defines delegationSigned as true when DS records exist in the parent, while zoneSigned and the DS or key data are separate parts of the RDAP secureDNS object.
  • The field is registration evidence, not a live validation result. A defensible DNSSEC conclusion also needs current parent DS, child DNSKEY and RRSIG data, authoritative reachability, time validity and an identified validator's result.

A precise boolean with a narrow scope

The sampled LACNIC response for 84.7.200.in-addr.arpa is unambiguous about what it currently exposes. The object is a domain record. It lists three nameservers and a secureDNS object whose zoneSigned and delegationSigned values are both false, with an empty dsData array.

That is useful evidence about the record returned by LACNIC at the observation time. It is not permission to generalize about every reverse zone in the LACNIC region, nor does it report the live condition of the listed servers. The response contains neither a resolver trace nor the packets needed to reconstruct one.

Parent DS presence is one link in the chain

RFC 9083 keeps the field meanings deliberately separate. zoneSigned indicates whether the zone has been signed. delegationSigned indicates whether DS records exist in the parent. dsData can describe the key tag, algorithm, digest and digest type of a DS record, while keyData can carry DNSKEY material.

Those fields describe registration data. DNSSEC validation is an operation performed against a chain of live DNS answers at a particular time. A validator must obtain the parent DS, retrieve the child's DNSKEY and signed records, compare digests and algorithms, check signatures and time bounds, and handle reachability or response failures. An RDAP boolean cannot silently perform those steps.

True and false both require disciplined wording

When delegationSigned is true, the defensible statement is that the RDAP representation says DS records are present in the parent. It does not prove that the child publishes the matching DNSKEY, that signatures are current, that the chain reaches a trust anchor, or that a particular resolver validates successfully.

When the value is false, the RDAP representation says that parent DS records are absent under the field's definition. That does not by itself establish why they are absent, whether a change is pending, or whether another observation made at another time will agree. The observation must retain its URL, response bytes and collection time.

Build a two-surface evidence record

The registry surface should preserve the exact RDAP domain URL, ldhName, nameserver list, secureDNS values, DS or key arrays, response hash and retrieval time. The operational surface should separately preserve parent and child DNS queries, server addresses, response codes, authoritative flags, DNSKEY, DS and RRSIG records, validator output and clock context.

Only after the two surfaces are compared should an analyst describe current validation. Even then, the result belongs to the identified observation point and time. It does not establish ownership, contractual authority or control of the hosts merely because the cryptographic chain succeeds.

Sources