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 deletedThe 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.jnland related files) - With views:
<viewname>.mkeysper 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 answerdig @resolver example.com(validation enabled) returns SERVFAILValFailcounter 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, andValFailcounters from the BIND statistics channel. A sudden spike inValFailacross multiple views is the earliest quantitative signal of a trust anchor problem. - SERVFAIL rate correlation: Netdata tracks
QrySERVFAILas both a raw counter and a ratio of total responses. Correlating a SERVFAIL spike with aValFailspike 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
ValFailincreases 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
ValFailspikes identifies managed-keys initialization failures.
Related guides
- BIND cache eviction storms: DeleteLRU, an undersized max-cache-size, and the pressure spiral
- BIND cache hit ratio dropping: the leading edge of recursive pain
- BIND clients-per-query and max-clients-per-query: duplicate recursion for popular names
- BIND cold cache after restart: the warming storm and elevated upstream load
- BIND dynamic update failures: UpdateFail, denied updates, and TSIG drift
- BIND forwarding loops: recursion that never terminates and burns recursive slots
- How BIND actually works in production: a mental model for operators
- BIND journal (.jnl) corruption: dynamic-update and IXFR failures that block zone load
- BIND lame delegations: ’lame server resolving’ and nameservers that are not authoritative
- BIND max-cache-size: sizing the resolver cache without triggering the OOM killer
- BIND monitoring checklist: the signals every production resolver and authoritative server needs
- BIND monitoring maturity model: from survival to expert