DNSSEC root trust anchor

DNSSEC's chain of trust starts at the root. The root trust anchor is the public key that validating resolvers use to verify the entire signed DNS hierarchy.

DNSSEC 9 min read Reviewed 19 Sep 2026

The big picture

DNSSEC adds cryptographic signatures to DNS responses. Every signed zone can be verified by checking its signatures against keys published in the parent zone, all the way up to the root.

Root KSKTrust anchor
for everything

Root ZSKSigns root
zone data

TLD DSLinks TLD key
to root

Domain DNSKEYVerified by
chain above

Introduction

The Domain Name System was originally designed without authentication. Any server along the path could return forged answers, and the resolver had no way to detect the forgery. DNSSEC (DNS Security Extensions) was developed to address this by adding origin authentication and data integrity to DNS responses.

The entire DNSSEC trust model depends on a single starting point: the root trust anchor. This guide explains what the root trust anchor is, how resolvers use it, and how it is managed.

What DNSSEC does

DNSSEC adds four new record types to DNS that work together to create a verifiable chain of trust:

DNSKEY — contains the public key used to verify signatures for a zone.
RRSIG — contains a cryptographic signature over a set of DNS records.
DS (Delegation Signer) — published in a parent zone, contains a hash of a child zone's key, linking the trust chain between zones.
NSEC / NSEC3 — proves that a name or record type does not exist (authenticated denial of existence).

When a validating resolver receives a signed DNS response, it checks the RRSIG against the DNSKEY for that zone. It then checks that the DNSKEY is vouched for by a DS record in the parent zone. This chain continues upward until it reaches the root zone, where the trust anchor provides the final verification.

The root trust anchor

The root trust anchor is the public half of the root zone's Key Signing Key (KSK). It is the single cryptographic key that validating resolvers are configured to trust unconditionally.

The root KSK signs the root zone's DNSKEY RRset, which includes both the KSK itself and the Zone Signing Key (ZSK).
The ZSK signs all other record sets in the root zone, including the DS records for TLDs.
A validating resolver that trusts the root KSK can therefore verify any signed domain in the global DNS, provided every zone in the chain is properly signed.

The root zone was first signed with DNSSEC on 15 July 2010. Since then, validating resolvers worldwide have used the root trust anchor as their starting point for verification.

Trust anchor distribution

For a resolver to validate DNSSEC, it must have a copy of the root trust anchor. There are several ways this is distributed:

Built-in to resolver software. Major resolver implementations (BIND, Unbound, Knot Resolver, and others) ship with the current root trust anchor included in their default configuration.
RFC 5011 automated updates. RFC 5011 defines a protocol for resolvers to track trust anchor changes automatically. When a new KSK is published in the root DNSKEY RRset, resolvers following RFC 5011 can accept it after a hold-down period without manual intervention.
Manual configuration. Operators can download the trust anchor from IANA's website and configure it explicitly. IANA publishes the trust anchor in multiple formats including XML and DS record form.

The combination of built-in keys and RFC 5011 automated rollover means most resolvers stay current without operator action, though operators should verify their configuration periodically.

Key signing ceremonies

The root zone KSK is managed by ICANN through a formal, auditable process known as a Key Signing Ceremony (KSC). These ceremonies are conducted quarterly at two secure facilities in the United States.

Each ceremony involves Trusted Community Representatives (TCRs) — volunteers from the Internet community who hold physical credentials (smart cards and safe deposit box keys) required to access the key signing hardware.
The KSK private key is stored in Hardware Security Modules (HSMs) that never expose the key material in software.
During a ceremony, the HSMs sign the root zone's DNSKEY RRset for the upcoming quarter, producing the RRSIG records that make root zone DNSSEC validation possible.
The entire process is scripted, witnessed, and recorded. Ceremony logs and video are published by ICANN for transparency.

This ceremony process ensures that no single person or organization can unilaterally sign or modify the root zone's DNSSEC keys.

KSK rollover

Cryptographic keys have a finite operational lifetime. Eventually the root KSK must be replaced with a new key — a process called a KSK rollover.

The first (and so far only) root KSK rollover occurred on 11 October 2018:

The original root KSK (key tag 19036) had been in use since the root was signed in 2010.
A new KSK (key tag 20326) was generated in 2016 and published in the root DNSKEY RRset in July 2017.
Resolvers using RFC 5011 had over a year to pick up the new key automatically.
The rollover was originally scheduled for October 2017 but was postponed by one year after analysis showed a significant number of resolvers had not yet picked up the new key.
When the rollover was executed in October 2018, the old KSK was removed from active signing duty, and resolvers that had the new key continued to validate without disruption.

The rollover demonstrated both the viability of the RFC 5011 mechanism and the operational challenges of coordinating a global trust anchor change. ICANN continues to monitor resolver readiness and plan for future rollovers.