Summary

  • RFC 9718 separates the DNSSEC root-key material from the mechanisms that authenticate its distribution; the ICANN CA and Web PKI can help verify a file, but neither is the DNSSEC trust anchor.
  • A usable anchor is the result of five distinct judgements: authentic file, eligible time window, internally consistent representation, supported parsing and deliberate local acceptance.

A chain of trust is easiest to describe from the top down. A validator begins with a trusted key, verifies the root, and follows signed delegations. The awkward question points upward: who verified the first key?

RFC 4033 answers without disguising the boundary. A trust anchor is a DNSKEY or DS digest configured in a validating resolver, and its initial value must arrive through a secure or trusted means outside DNS. DNSSEC authenticates what follows the anchor. It does not authenticate the decision that made the anchor trusted.

That distinction is the durable contribution behind RFC 9718, co-authored by Joe Abley and published as an IETF Informational RFC in January 2025. The document obsoletes RFC 7958 and specifies how IANA publishes root-zone trust-anchor information. Its importance is not that it eliminates out-of-band trust. It labels the seams around it.

The first seam is between an object and its envelope. IANA publishes an XML document containing KeyDigest records. A detached CMS signature can chain to an ICANN-controlled certificate authority, while HTTPS can authenticate delivery under the Web PKI. Those mechanisms help a relying party decide whether the document came from the expected publisher and remained intact.

But RFC 9718 states the point that operational shorthand often erases: the ICANN CA is not a DNSSEC trust anchor. The certificate chain authenticates the publication object. The key digest or public-key material inside that object is what may become a DNSSEC anchor after processing and acceptance. Calling both things “the root of trust” collapses two different systems and hides where an operator changed state.

The revision from RFC 7958 makes this separation sharper. The older publication design included per-key PKIX certificates and certificate-signing requests, and described a detached OpenPGP mechanism. RFC 9718 removes those paths. Its explanation is unusually candid: they mixed out-of-band trust in authentication keys with out-of-band trust in DNSSEC root keys. More cryptographic packaging had not removed the bootstrap decision; it had made the decision harder to name.

The XML itself carries several independent states. validFrom and validUntil describe the interval in which a KeyDigest is eligible for use. They are not a prediction that every resolver has installed the key, nor a command to do so. A processor should not use an entry outside that interval. Time is therefore part of the evidence, and a stale but correctly signed file is not automatically an acceptable current configuration.

RFC 9718 also permits optional publickeyinfo, containing a DNSKEY public key and flags alongside digest data. The extra representation enables a processor to construct DNSKEY material directly. It also creates a consistency obligation: if the public-key information and the digest do not agree, that KeyDigest must not be used. A valid CMS signature cannot cure an internal contradiction.

Support for that optional field is itself local capability. Two conforming processors can read the same authentic XML and produce different candidate sets if one understands publickeyinfo and another does not. Provenance of the input does not guarantee uniform interpretation. Software version, parser behavior and output representation belong in an operational record.

Even the XML source attribute is deliberately modest. RFC 9718 treats it as advisory. A URL can say where a document may be found; it does not confer authority by appearing inside the document. This is the difference between a locator and a mandate.

Finally comes acceptance. The RFC says a validator operator may decide whether to accept the published anchors under whatever policy the operator chooses. That sentence leaves responsibility where running code actually lives. IANA publishes; certificate systems support origin checks; implementers parse; vendors package; operators decide what enters a resolver's trust state.

RFC 5011 does not abolish this first decision. It provides a method for a validator that already trusts an anchor to learn successors in-band after observation and hold-down conditions. Existing trust authenticates the transition. It cannot reach backward and authenticate the original installation that made the method possible.

The current IANA trust-anchor page makes the distribution surfaces concrete: root-anchors.xml carries the anchor data, root-anchors.p7s carries the detached signature, and icannbundle.pem supplies certificates used to validate that signature. The page also notes that vendors differ in how and when they distribute updates. One published set can therefore pass through many institutional release policies before reaching a resolver.

IANA's November 2024 format notice asked users to retrieve the XML regularly and test whether their systems could process the revised format. That advice exposes the practical boundary: publication success is not deployment success. An artifact may be authentic and timely while a downstream parser rejects it, a package remains old, or an operator declines it.

The live root-anchors.xml is the machine-readable publication, not a declaration that any particular resolver has accepted its entries.

NSRC's biography records Abley's work leading ICANN DNS Operations and participating in root DNSSEC deployment. That experience matters because RFC 9718 reads like an operator's refusal to let adjacent proofs impersonate one another. It does not make Abley sovereign over the root, and the RFC is not his unilateral policy. Its value lies in describing a system where no single signature owns the entire conclusion.

A defensible trust-anchor receipt should therefore preserve five answers. Was the file origin and content verified, and by which mechanism? Was the entry within its validity interval? Did digest and public-key representations agree? What parser and transformation produced the candidate anchor? Who accepted that candidate into which validator under what policy? “Signature valid” answers only the first question.