Fixing DNS SERVFAIL Caused by Expired DNSSEC RRSIG Records
Published: 22 Aug, 2026

blog_GgyKasu0NoWRvdIPturQgQ0_thumb.jpg

Understanding DNSSEC Validation Failures

A SERVFAIL (Server Failure) RCODE returned by a validating recursive resolver often indicates a cryptographic verification failure rather than an authoritative nameserver outage. When DNSSEC is enabled for a domain, validating resolvers enforce strict chain-of-trust verification from the root zone down to the leaf resource records. If an authoritative zone's RRSIG (Resource Record Signature) validity period lapses, or if there is a mismatch between the parent zone's DS (Delegation Signer) record and the child zone's active DNSKEY, recursive resolvers intentionally reject the response and emit SERVFAIL.

Root Causes of RRSIG Validation Failure

  • Automated Re-signing Pipeline Failure: Cron jobs or internal daemons (such as named automatic zone signing or OpenDNSSEC) fail to regenerate signatures before the signature_expiration epoch.
  • Parent-Child Desynchronization: Modifying the Key Signing Key (KSK) without updating the corresponding DS record at the domain registrar.
  • Authoritative Server Clock Drift: An out-of-sync Network Time Protocol (NTP) daemon on authoritative nameservers causes newly generated signatures to be generated with invalid inception or expiration timestamps relative to UTC.
  • Zone Transfer (AXFR) Desynchronization: Secondary nameservers serving stale signed zone data with expired RRSIGs due to notify or firewall misconfigurations.

Diagnostic Steps

To confirm whether a SERVFAIL is triggered by DNSSEC validation failure, run a comparison query using dig with and without the +cd (Checking Disabled) flag:

# Query against a validating resolver (expecting SERVFAIL)
dig @1.1.1.1 example.com A

# Bypass DNSSEC validation using the CD bit
dig @1.1.1.1 example.com A +cd

If the query returns SERVFAIL normally but returns NOERROR with an answer section when +cd is passed, the issue is strictly isolated to DNSSEC validation.

Inspect the cryptographic validity and signature timestamps using delv:

delv @1.1.1.1 example.com A +vtrace

To manually inspect expiration timestamps on authoritative servers, retrieve the RRSIG directly:

dig @ns1.example.com example.com A +dnssec

Examine the RRSIG record fields: the 4th and 5th fields represent the Signature Expiration and Signature Inception in YYYYMMDDHHMMSS format. Compare these against current UTC system time using date -u +%Y%m%d%H%M%S.

Step-by-Step Remediation

1. Emergency Mitigation: Disable DS Record at Registrar

If authoritative keys are corrupted and immediate resolution is required for production traffic, remove the DS record at your domain registrar. This converts the domain from a secure zone to an insecure zone, allowing resolvers to return records without cryptographic validation while you repair the keys.

2. Resign the Zone on Authoritative Servers (BIND 9)

If maintaining an authoritative BIND 9 cluster, verify whether dynamic signing is active. Force a zone re-sign using rndc:

rndc sign example.com
rndc reload example.com

For manually signed zones using dnssec-signzone, regenerate signatures with valid duration parameters:

dnssec-signzone -A -3 $(head -c 16 /dev/urandom | sha1sum | cut -b 1-16) -N INCREMENT -o example.com -t -e +2592000 /var/named/db.example.com /var/named/keys/Kexample.com.+013+12345.private

The parameter -e +2592000 sets the new signature expiration to 30 days from the current execution time.

3. Fix Clock Synchronization Across Authoritative Fleet

Ensure that all authoritative primary and secondary servers synchronize time accurately via chrony or systemd-timesyncd:

systemctl restart chronyd
chronyc tracking

4. Synchronize DS Records Post-Rollover

If you rotated your Key Signing Key (KSK), extract the new DS record from your DNSKEY set:

dig @ns1.example.com example.com DNSKEY | dnssec-dsfromkey -2 -f - example.com

Log in to your registrar management console and update the Key Tag, Algorithm, Digest Type, and Digest to match the output from the command above.

Verification

Flush resolver caches and verify resolution across external resolvers:

delv @8.8.8.8 example.com A
dig @8.8.8.8 example.com A +dnssec

A successful resolution will return status NOERROR with the ad (Authenticated Data) flag present in the response header.