DNSSEC Signatures Expired: RRSIG Validity Period Exceeded

DNSSEC RRSIG signatures have a fixed validity period. When they expire, validating resolvers like Google Public DNS and Cloudflare 1.1.1.1 treat the zone as bogus and return SERVFAIL. This is a time-bomb failure: everything works until expiration, then all resolution breaks at once.

7 min readerrorsThomas Johnson

What This Error Means

DNSSEC uses RRSIG records to cryptographically sign every record set in your zone. Each RRSIG has an inception timestamp (when the signature becomes valid) and an expiration timestamp (when it stops being valid). Two error codes apply:

  • DNSSEC_RRSIG_EXPIRED — One or more RRSIG signatures in your zone have passed their expiration timestamp. The signatures are no longer valid. Validating resolvers treat all records covered by expired signatures as bogus and return SERVFAIL.
  • DNSSEC_RRSIG_EXPIRING — Signatures are still valid but will expire within 7 days. This is a warning. If no action is taken, the zone will break when the signatures reach their expiration timestamp.

This is a time-bomb failure mode. DNSSEC works perfectly until the moment signatures expire, then every signed record in the zone becomes unresolvable through validating resolvers — simultaneously, with no graceful degradation.

Why This Matters

Expired RRSIG signatures produce the same end result as a broken chain of trust: SERVFAIL from validating resolvers. The difference is the failure mode.

A broken chain of trust is typically caused by a configuration mistake and persists until someone notices and fixes it. Expired signatures are an operational failure — the signing pipeline stopped running, and the clock ran out. The zone was working correctly until it was not.

The consequences are identical to any DNSSEC validation failure:

  • Complete DNS resolution failure on validating resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9, OpenDNS)
  • Email delivery failure — MX, SPF, DKIM, and DMARC lookups all return SERVFAIL
  • Website and API downtime for clients using validating resolvers
  • Cascading failures in systems that depend on your domain's DNS records

The failure is particularly dangerous because it is time-delayed. You can make a change that breaks your signing pipeline today and not see the impact for days or weeks, depending on your signature validity period. By the time the zone goes dark, the root cause may be buried under other changes.

How to Diagnose

Check Signature Validity

Use the mxio DNSSEC Validator to inspect your zone's RRSIG records. The tool reports the inception and expiration timestamps for each signature and flags any that have expired or are approaching expiration.

You can also query directly:

dig A example.com +dnssec

Look for the RRSIG record in the response. The fifth and sixth fields after the type covered are the expiration and inception timestamps in YYYYMMDDHHmmSS format:

example.com. 300 IN RRSIG A 13 2 300 20260415120000 20260401120000 12345 example.com. <signature>

In this example, the signature expires on 2026-04-15 at 12:00:00 UTC. If the current time is past that, the signature is expired.

Determine Who Manages Signing

The fix depends entirely on whether your DNS provider manages DNSSEC signing automatically or whether you manage it manually.

Managed DNSSEC providers (signing is automatic):

  • Cloudflare
  • AWS Route 53
  • Google Cloud DNS
  • Azure DNS
  • NS1
  • DNSimple

If you use one of these providers and signatures have expired, something is wrong on their end — a zone configuration issue, an account suspension, or a service disruption.

Manual DNSSEC (you run your own signing):

  • BIND with dnssec-signzone or inline-signing
  • PowerDNS with DNSSEC enabled
  • Knot DNS
  • NSD with manual key management

If you manage signing yourself, your re-signing process has stopped or failed.

How to Fix

If Your DNS Provider Manages DNSSEC

When a managed provider's signatures expire, the issue is almost always on their side or in your account configuration:

  1. Check your account status. Suspended or expired accounts may stop zone signing. Verify your DNS hosting account is active and in good standing.
  2. Check zone status. Some providers disable DNSSEC if you modify zone settings or transfer the zone. Verify DNSSEC is still enabled in your provider's dashboard.
  3. Contact your provider. If DNSSEC is enabled and your account is active, this is a provider-side signing failure. Open a support ticket. Include the expired RRSIG details from the mxio DNSSEC Validator results.
  4. If the provider cannot resolve quickly, consider temporarily removing DNSSEC. Remove the DS record at your registrar first, wait for propagation, then disable DNSSEC at the provider. This restores unsigned resolution while the provider fixes the signing issue. Re-enable DNSSEC once the provider confirms their pipeline is healthy.

If You Manage DNSSEC Manually

When you control the signing infrastructure, expired signatures mean your re-signing process failed:

  1. Re-sign the zone immediately. For BIND:

    dnssec-signzone -A -N INCREMENT -o example.com -t db.example.com
    rndc reload example.com

    For BIND inline-signing, reloading the zone should trigger automatic re-signing if keys are accessible.

  2. Check your keys. Verify the private keys are still accessible to the signing process. Key file permissions, HSM connectivity, or expired key activation dates can all prevent signing.

  3. Check your cron job or automation. Manual DNSSEC zones typically re-sign on a schedule (daily or weekly cron job). If the cron job stopped running — server reboot, changed permissions, disabled crontab — signatures expire silently.

  4. Verify the new signatures. After re-signing, run the mxio DNSSEC Validator to confirm all RRSIG records have fresh inception and expiration timestamps.

If You Recently Migrated DNS Providers

DNS migrations are a common trigger for expired signatures. The sequence that causes problems:

  1. Old provider signed the zone and managed re-signing automatically.
  2. You migrated to a new provider that either does not support DNSSEC or requires explicit enablement.
  3. The old signatures propagated to the new provider's servers (via zone transfer or manual import).
  4. No new signatures were generated. The old ones expired.

Fix: Enable DNSSEC on the new provider and update the DS record at your registrar to match the new provider's keys. If the new provider does not support DNSSEC, remove the DS record at your registrar to disable DNSSEC cleanly.

Prevention and Ongoing Monitoring

Expired signatures are entirely preventable with monitoring. The zone does not go from healthy to broken instantly — signatures have a validity period measured in days or weeks, which gives you time to intervene.

  1. Monitor RRSIG expiration dates. Use mxio Domain Health Monitoring to track signature validity. The DNSSEC_RRSIG_EXPIRING warning fires 7 days before expiration, giving you a window to act.
  2. Use managed DNSSEC. If you are manually signing zones, consider migrating to a provider that handles signing automatically. Manual DNSSEC is operationally expensive and fragile — a single missed re-signing cycle takes your zone offline.
  3. Set signature validity periods appropriately. If you manage signing manually, use validity periods long enough to survive operational disruptions (30 days is common) but short enough that stale signatures do not linger. Re-sign well before the halfway point of the validity period.
  4. Audit after migrations. Any DNS provider migration should include a DNSSEC verification step. Check that the new provider is signing the zone and that signatures are being refreshed on schedule.
  5. Test your re-signing pipeline. If you use automated re-signing (cron, CI/CD), verify the automation is running. A signing pipeline that fails silently is indistinguishable from no pipeline at all until the signatures expire.
Was this article helpful?

Related Articles