How to Monitor DNSSEC Validation with a Web Cron Job

Excerpt: DNSSEC failures can make a correctly hosted domain intermittently unreachable or silently remove validation protection. This guide shows how a scheduled web cron job can test the complete trust chain, detect expiring signatures, and alert before users encounter resolution errors.

DNS Security Extensions add cryptographic proof to DNS answers. A validating resolver follows a chain from the root zone through the top-level domain to your zone. If a delegation, key, signature, or denial-of-existence record is wrong, strict resolvers may return SERVFAIL even though the web server and TLS certificate are healthy.

What a DNSSEC monitor should verify

Secure delegation: the parent zone publishes the expected DS record.
Key availability: the authoritative nameservers return the active DNSKEY set.
Signature validity: RRSIG records verify and cover the records your service depends on.
Signature lifetime: inception and expiration timestamps provide enough safety margin.
Algorithm support: DS and DNSKEY algorithms match and remain accepted by common validators.
Authenticated denial: NSEC or NSEC3 proves that a deliberately missing name does not exist.
Resolver agreement: multiple validating resolvers return the same security state.

Run these checks alongside DNS record change monitoring. A zone may contain the correct A, AAAA, MX, and TXT values while its DNSSEC chain is still broken.

Understand the chain of trust

The parent zone does not publish your full public key. It publishes a DS digest that identifies the key-signing key in your child zone. Your zone publishes DNSKEY records, and signatures connect those keys to signed record sets. A monitor must evaluate the chain as a whole rather than merely checking that a DNSKEY record exists.

Record the zone name, nameserver, resolver, DS key tag, digest type, DNSKEY key tag, algorithm, signature inception, signature expiration, and final validation state. Those details turn an alert into an actionable diagnosis.

Build a validation endpoint

Create a small server-side endpoint that performs DNSSEC-aware queries and exits with a non-success HTTP status when a critical assertion fails. The web cron service only needs the endpoint URL and a clear status; keep credentials and diagnostic internals on the server.

load monitored zones
for each zone:
  query parent DS records
  query every authoritative server for DNSKEY
  validate DS against the key-signing key
  query important signed record sets
  verify signatures and expiration margin
  test a known-nonexistent name
  compare results through two validating resolvers
return 200 only when required checks pass

Use a DNS library that exposes DNSSEC records and validation results. A normal stub resolver may hide the chain or report only a generic lookup failure. Keep the monitor independent from the application path so a broken application does not mask the DNS diagnosis.

Check every authoritative nameserver

Query each authoritative server directly. During a deployment, one server may serve an old DNSKEY set or stale signatures while the others are current. A recursive resolver can cache the healthy answer and conceal the inconsistency until traffic reaches the stale server.

Compare SOA serials, DNSKEY sets, RRSIG expiration times, and responses for representative A, AAAA, MX, and TXT records. Differences during a short, planned propagation window may be expected; persistent differences should alert.

Monitor signature expiration as a countdown

Do not wait for a signature to expire. Calculate the remaining lifetime and warn well before the next planned signing cycle. A practical policy is a warning when less than twice the normal resigning interval remains and a critical alert when less than one interval remains.

Track the shortest remaining lifetime across important record sets. Include the exact record type and authoritative server in the notification. This is similar to SSL certificate expiration monitoring, but DNS signatures often rotate more frequently and can differ between record sets.

Detect unsafe key rollovers

A safe rollover has an overlap period: the new key is published before it is used, caches have time to learn it, and the old key remains available until dependent records expire. Monitor the sequence rather than treating every key-set change as an incident.

Alert when a parent DS points to no matching child DNSKEY.
Alert when active signatures reference a missing key tag.
Warn when a new key begins signing without the expected publication overlap.
Warn when the old key disappears before its signatures and cached DS data can expire.

Correlate unexpected changes with certificate transparency monitoring and TLS configuration checks when investigating a broader domain-control event.

Test authenticated denial of existence

Query a randomized label that should not exist beneath the zone. A signed zone should return an authenticated NSEC or NSEC3 proof. Confirm that validators treat the response as secure NXDOMAIN rather than insecure or bogus. Randomize carefully so negative caching does not make every run identical.

Avoid false alarms

Retry a timeout against the same server once, then compare another network path.
Respect DNS TTLs when evaluating an intentional rollout.
Distinguish insecure zones from bogus validation; insecure may be intentional, bogus is usually an outage.
Keep warnings for short expiration margins separate from critical validation failures.
Group multiple failed record types caused by the same broken trust chain into one incident.
Require agreement from two consecutive runs before escalating a transient resolver disagreement.

Schedule and alerting

Run the complete chain check every 15 to 60 minutes for production domains and immediately after registrar, DNS provider, or signing-policy changes. A daily inventory can confirm algorithms, key sizes, nameserver membership, and long-term expiration trends.

Alerts should include the domain, failing step, queried server, resolver, expected key tag, observed key tag, signature expiration time, and last known-good result. Link to the operational runbook rather than embedding secrets in the message.

Domain ownership and delegation problems may also surface through domain expiration monitoring. Mail-related incidents benefit from the separate checks described in SPF, DKIM, and DMARC monitoring.

Implementation checklist

List the production zones and business-critical record types.
Validate from the parent DS record to signed child data.
Query every authoritative nameserver directly.
Track the minimum RRSIG lifetime and planned rollover windows.
Test NSEC or NSEC3 denial with a nonexistent label.
Compare at least two validating resolvers.
Expose a protected health endpoint with no secret in its public output.
Schedule it, prevent overlapping runs, and test a deliberate failure safely.

Final takeaway

DNSSEC monitoring protects a layer that ordinary uptime checks cannot see. By validating delegation, keys, signatures, denial proofs, and resolver agreement on a schedule, you can detect a broken trust chain before it becomes a widespread SERVFAIL incident.