CONCEPT Cited by 3 sources

Trust anchor

Definition

A trust anchor is a public key (or its fingerprint) that a verifier trusts a priori — not because something else vouches for it, but because it was preconfigured into the verifier out of band. It is the top of a chain of trust: the one key with no parent to confirm it, from which all downstream trust is derived.

Examples:

• The root CAs in a browser or OS root store (Web PKI).
• The root KSK a DNSSEC-validating resolver starts from.
• The root-of-trust key fused into hardware for secure boot.

Because an anchor is trusted unconditionally, acquiring and distributing it is a privileged, high-ceremony operation (joining a browser root program; shipping the DNS root KSK in resolver software).

The anchor-distribution problem

Everything below an anchor can be re-keyed by having its parent re-sign it. The anchor itself cannot — nothing above it exists to vouch for a replacement. So anchor changes require out-of-band distribution, which is the hardest part of any trust-system migration:

• DNSSEC root KSK — distributed via RFC 5011 automatic update (new key published alongside the old, verified, held ≥ 30 days, then accepted) or baked into resolver software as a built-in anchor. Cloudflare added KSK-2024 to Big Pineapple's built-in anchors in July 2024 rather than rely on resolvers retaining RFC-5011-learned state across upgrades. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
• Browser/OS root stores — distributed via software updates; adding or removing a root CA ships as a client update.

Verifying the anchor a verifier holds

A subtle operational gap: after distributing a new anchor you need to confirm resolvers/clients actually retained it. For DNSSEC, RFC 8509 root-key sentinels let a user query a resolver for which root keys it trusts — closing the "did it keep the key?" gap that caused silent trust loss during the 2017 rollover. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)

Seen in

• sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready — the DNS root KSK as trust anchor: "a resolver checking DNSSEC starts with a root public key, or its fingerprint, that it already trusts. This is called a trust anchor." KSK-2024 distribution via RFC 5011 + built-in anchors, and RFC 8509 verification.
• sources/2026-09-10-cloudflare-1111-post-quantum-dnssec — the trust anchor as the top of the "break once, forge everywhere" chain, hence the first target of a PQ migration.
• sources/2026-10-30-cloudflare-emudhra-patching — the Web PKI side of the anchor-distribution problem: after the eMudhra distrust, trust stores in the long tail (Android WebView, bots, old browsers) still accepted the weak chain a week later; the proposed fix is a trust store that is a fast-update channel (upki), not a static list of roots.

Related

• concepts/chain-of-trust — the structure a trust anchor roots.
• concepts/dnssec — DNS validation starts from the root KSK anchor.
• concepts/key-rotation — rotating an anchor is the hard case.
• systems/cloudflare-1-1-1-1-resolver — ships KSK-2024 as a built-in anchor.