$ guides / bind-dns / bind-dns-managed-keys-trust-anchor ▌

Operations Guides

BIND managed-keys and trust anchors: KSK rollover, RFC 5011, and a stale root key

DNSSEC validation depends on a chain of trust anchored at the root zone’s Key Signing Key (KSK). BIND maintains that anchor automatically using RFC 5011 trust anchor management, stored in a managed-keys database. When it breaks, every signed domain on the internet fails validation simultaneously, and the resolver returns SERVFAIL for the majority of real-world queries.

The failure looks like total DNS failure because most major domains are signed. It is not a per-domain problem. One stale trust anchor breaks validation for every signed zone.

This article covers how BIND’s trust anchor mechanism works, what RFC 5011 does during a KSK rollover, and how to recognize and recover from a stale root key.

What it is and why it matters

A validating resolver with a stale trust anchor does not gracefully degrade. It returns SERVFAIL for every query to a signed domain. Unsigned domains still resolve, but since the vast majority of production domains are signed, the practical impact is indistinguishable from a total DNS outage.

The trust anchor is maintained automatically by RFC 5011. The protocol is designed so that root KSK rollovers propagate to resolvers without operator intervention, but it depends on the resolver being online and able to reach the root servers during specific windows in the rollover schedule. Miss those windows, and the trust anchor becomes permanently stale.

How it works

RFC 5011 defines a state machine for automated trust anchor rollover. When a validating resolver sees a new DNSKEY with the Secure Entry Point (SEP) bit set, it does not trust it immediately. It enters a hold-down period to prevent an attacker from injecting a rogue key during a brief compromise:

stateDiagram-v2
    [*] --> Start: New SEP key seen in DNSKEY RRset
    Start --> AddPending: Begin 30-day hold-down
    AddPending --> Trusted: Continuously present for 30 days
    AddPending --> Start: Key vanishes during hold-down
    Trusted --> Removed: Revoke bit observed on key
    Removed --> [*]: Trust anchor deleted

The key states:

Discovery: During normal validation, the resolver fetches the root DNSKEY RRset and notices a new key with the SEP bit that it has not seen before.
Add hold-down: The new key enters a pending state. RFC 5011 requires the key to be continuously present in the DNSKEY RRset for a minimum hold-down period (default 30 days). If the key disappears at any point, the timer resets.
Trusted: After surviving the hold-down, the key becomes a valid trust anchor. The resolver uses it to validate the root zone alongside any existing trusted keys.
Revocation: When a KSK is retired, the zone operator sets the revoke bit. Resolvers that observe the revoke bit on a trusted key immediately remove it from their trust anchor set.

BIND stores trust anchor state in a managed-keys database. On BIND 9.18 and later, the trust-anchors statement with the initial-key keyword bootstraps the process. The older managed-keys and trusted-keys configuration statements are deprecated.

The recommended configuration for most resolvers:

dnssec-validation auto;

This uses a built-in root trust anchor compiled into the BIND binary and updates it via RFC 5011. No external bind.keys file is needed. ISC discontinued distribution of that file, and all supported BIND releases have the root key compiled in.

The managed-keys database is stored as files in BIND’s working directory:

Without views: managed-keys.bind (with associated .jnl and related files)
With views: <viewname>.mkeys per view

The directory is controlled by the managed-keys-directory option, or falls back to the general directory option. It must be writable by the named process.

To inspect trust anchor state:

# Check trust anchor state for the default view
rndc managed-keys status

This shows each trust anchor, its key tag, and its RFC 5011 state (trusted, pending, etc.). For deployments with multiple views, check each view separately, as each maintains its own .mkeys file.

Where it shows up in production

The canonical production scenario is a root KSK rollover. The 2018 rollover (from KSK-2010 to KSK-2017, key tag 20326) was the first live root KSK rollover and caught many operators off guard. The current rollover cycle involves KSK-2024:

KSK-2017 (key tag 20326): currently active, signing the root zone
KSK-2024 (key tag 38696): published in the root DNSKEY RRset since January 11, 2025, but not yet signing
October 11, 2026: KSK-2024 scheduled to begin signing the root zone
January 11, 2027: KSK-2017 scheduled for revocation (revoke bit set)

During the publication phase (January 2025 through October 2026), RFC 5011-compliant resolvers that are online and querying the root should discover KSK-2024, complete the 30-day hold-down, and promote it to trusted status. By the time KSK-2024 begins signing in October 2026, those resolvers already trust it.

A resolver that was offline, had a corrupted managed-keys database, or could not fetch the root DNSKEY RRset during this window may never have acquired KSK-2024 as a trust anchor. When KSK-2017 is revoked in January 2027, that resolver loses its only valid trust anchor. Validation fails for every signed domain.

With the October 2026 signing transition approaching, resolvers that have not yet acquired KSK-2024 should be investigated now.

When this goes wrong: the stale root key

A stale trust anchor produces a distinctive failure pattern. The symptoms are unmistakable once you know to look for them:

SERVFAIL for most queries to signed domains (google.com, github.com, cloudflare.com)
Unsigned domains resolve normally
dig @resolver example.com +cd (checking disabled) returns NOERROR with a valid answer
dig @resolver example.com (validation enabled) returns SERVFAIL
ValFail counter spikes across many unrelated domains

The +cd test is the definitive diagnostic. If queries succeed with validation disabled and fail with it enabled, the problem is in the DNSSEC validation chain. If it affects all signed domains rather than one zone, the trust anchor is the suspect, not upstream signing.

What triggers a stale anchor

Cause	What it looks like	First thing to check
Resolver offline during rollover window	Only old KSK (20326) in managed-keys status; new KSK (38696) absent	`rndc managed-keys status`
Corrupted managed-keys database	BIND starts with managed-keys warnings; global validation failure	BIND startup logs for managed-keys errors
Cannot fetch root DNSKEY RRset	“Unable to fetch DNSKEY set ‘.’: timed out” at startup	Root server reachability, especially IPv6

The third cause is more common than operators expect. BIND fetches the root DNSKEY RRset to validate and update trust anchors. If this fetch fails at startup, the managed-keys database cannot initialize. A frequent trigger is IPv6: BIND attempts to fetch the DNSKEY over IPv6, and if IPv6 connectivity is broken or firewalled, the fetch times out. The workaround is either fixing IPv6 connectivity or starting named with the -4 flag to force IPv4 for the initial fetch.

A read-only working directory also prevents the managed-keys database from being updated. If the directory specified by managed-keys-directory or directory is not writable by the named process, BIND cannot persist trust anchor state and may not report the error clearly.

Reinitializing the trust anchor database

If rndc managed-keys status shows only the old KSK and the new key is missing, the trust anchor database needs reinitialization. The standard recovery is:

Stop named.
Back up the existing managed-keys files (managed-keys.bind* or <viewname>.mkeys* in the working directory) before removing them.
Remove the managed-keys database files.
Restart named. BIND reinitializes the trust anchor from its compiled-in key and begins RFC 5011 processing from scratch.

Warning: This restart is disruptive. named will flush its cache and interrupt active queries during the restart window. If the resolver is a production forwarder or recursive resolver for live traffic, plan a maintenance window.

This recovery depends on BIND being able to fetch the root DNSKEY RRset on restart. If the network is down or IPv6 is broken, reinitialization fails with the “timed out” error. Fix connectivity first.

On BIND 9.20, dnssec-validation yes; now requires an explicit trust-anchors configuration statement. Previously it could fall back to built-in keys. If you have upgraded to 9.20 and validation suddenly fails after the change, check whether the configuration still relies on the old implicit behavior.

Signals to watch in production

Signal	Why it matters	Warning sign
`ValFail` counter (per-view resolver stats)	Spikes when DNSSEC validation fails globally	Sustained increase across unrelated domains
SERVFAIL rate (`QrySERVFAIL`)	The user-visible effect of validation failure	Sustained rate above 0.1% of classified responses
`rndc managed-keys status` output	Shows which KSKs are trusted and their RFC 5011 state	Missing expected key tag (e.g., 38696 for KSK-2024)
System clock offset (NTP)	DNSSEC signatures have inception and expiration times	Clock drift greater than 30 seconds
`dig +cd` vs `dig` comparison	Definitive test for DNSSEC vs non-DNSSEC failure	Works with `+cd`, fails without
BIND startup logs	Managed-keys corruption or fetch failures appear here	“Unable to fetch DNSKEY set” or managed-keys warnings

NTP deserves emphasis. DNSSEC depends on accurate time because RRSIG records have inception and expiration timestamps. Significant clock drift can cause validation failures that look identical to a stale trust anchor, especially near inception or expiration boundaries. Always verify clock accuracy before assuming the trust anchor is the problem. Check with timedatectl status or chronyc tracking.

How Netdata helps

ValFail tracking: Netdata collects per-view ValAttempt, ValOk, ValNegOk, and ValFail counters from the BIND statistics channel. A sudden spike in ValFail across multiple views is the earliest quantitative signal of a trust anchor problem.
SERVFAIL rate correlation: Netdata tracks QrySERVFAIL as both a raw counter and a ratio of total responses. Correlating a SERVFAIL spike with a ValFail spike confirms a DNSSEC validation failure rather than an upstream or zone-specific issue.
Recursive client impact: A global validation failure causes recursive client slots to fill as clients retry failing queries. Netdata’s recursive client monitoring shows the secondary pressure from validation failures.
NTP clock offset: Netdata monitors system clock offset. Correlating clock drift with ValFail increases distinguishes a time synchronization problem from a stale trust anchor.
Process restart detection: If BIND restarts with a corrupted managed-keys database, Netdata’s process monitoring captures the restart event. Correlating restarts with subsequent ValFail spikes identifies managed-keys initialization failures.