Monitor DNSSEC Validation: Detect DNS Manipulation

What DNSSEC Delivers - and Where the Limits Are

Classic DNS was designed in the early 1980s, long before manipulation was a concern. It has no built-in protection against someone injecting a forged answer. DNSSEC adds digital signatures to DNS: each resource record is signed with a private key (RRSIG), the matching public key sits in the DNSKEY record, and the parent zone confirms that key through a DS record. This creates a continuous chain of trust from the root zone via the top-level domain down to your own domain.

The distinction matters: DNSSEC provides integrity and authenticity, not confidentiality. It does not encrypt the DNS query - that is the job of DNS over HTTPS and DNS over TLS, which Google Public DNS and Cloudflare's 1.1.1.1 resolver offer in addition (Cloudflare 1.1.1.1 Docs; Google Public DNS FAQ). Instead, DNSSEC ensures that the answer that arrives comes unaltered from the authoritative source. On a successful check, a validating resolver sets the so-called AD bit (Authenticated Data) in the response - a direct signal that the chain is intact.

The protective effect is considerable, but it has a built-in breaking point: if something in the chain is wrong - an expired signature, a non-matching DS record, a failed key rollover - then a validating resolver returns no answer but an error (SERVFAIL). From a security standpoint that is correct: better no answer than a possibly forged one. From an operations standpoint it is a trap, because the domain becomes simply unreachable for all users whose resolver validates. DNSSEC thus turns a silent misconfiguration into a hard outage.

What DNS Manipulation Looks Like in Practice

DNS manipulation is no niche topic. According to the IDC / EfficientIP Global DNS Threat Report, 90% of organisations suffered at least one DNS attack, on average 7.5 attacks per year, with damage costs of around 1.1 million US dollars per attack (IDC / EfficientIP Global DNS Threat Report 2023). In the US, the average cost of a DNS attack now exceeds 1.27 million US dollars (EfficientIP 2024). The attack patterns fall roughly into three categories.

The most dangerous aspect: in a successful hijack the attacker can even have a valid TLS certificate issued for your domain, because many certificate authorities verify domain control via DNS. The US agency CISA explicitly warned in its Emergency Directive 19-01 that attackers can in this way obtain valid encryption certificates for foreign domains and conduct man-in-the-middle attacks (CISA Emergency Directive 19-01). In 2024, attackers compromised DNS servers managing around 70,000 domains and redirected traffic to malicious sites (LastPass Threat Blog 2025). Spotting such changes early lets you intervene before visitors are harmed - and that is exactly the job of continuous DNS monitoring.

Why DNSSEC Validation Breaks So Often

Paradoxically, the biggest threat to a DNSSEC-protected domain is usually not an attacker but your own operational routine. Signatures have an expiry date, keys must be rotated regularly, and something can go wrong at each of these points. Expired signatures are considered the most common cause of DNSSEC outages worldwide (ianix DNSSEC Outages). The overview below shows the typical breaking points.

The key rollover is especially treacherous. If the old key is removed before the new DS record has fully propagated to the parent zone, the DS record no longer matches the current KSK - and every validating resolver refuses trust (NameSilo Security Blog 2025). This delay between change and propagation is why precisely planned, supposedly clean maintenance work leads to outages. A related pattern with certificates - the silent expiry of TLS validity - is covered in the article on hardening TLS cipher suites.

On top of that, responsibility for signature maintenance is often split across several parties. The DNS provider signs the zone, the registrar manages the DS record at the TLD, and your own team decides on key rotations - three parties that rarely share the same overview. If a provider automates re-signing, it usually runs reliably; with manually managed or self-hosted zones, however, a forgotten expiry date happens quickly. Caching makes it worse: an expired signature does not surface everywhere at once but spreads through the network as cached answers expire, so the problem at first hits only individual users and is easily misread as a one-off. It is exactly this staggered visibility that makes a central, externally measuring check so valuable.

What XICTRAQ Continuously Monitors

A one-off check with an online tool is a snapshot - it says nothing about whether your signature is still valid tomorrow or whether someone changes a record next week. Effective protection only emerges through repeated, automated checking that compares the current state against a released target state and alerts only on real deviations. XICTRAQ checks the registered domains regularly and reports every relevant change.

The decisive point is the comparison against a baseline. Not every DNS change is an incident - you adjust records deliberately, rotate keys, migrate name servers. Monitoring therefore does not alert on every movement, but on deviations from the released state. Anyone who makes a change deliberately releases the new baseline; everything else remains a reportable signal. The same principle of continuous state checking underlies the monitoring of CORS configuration errors and the monitoring of API rate limits and 429 responses.

Checking DNSSEC Status Technically

Anyone who wants to trace the state themselves can query the chain with standard tools. A validating resolver sets the AD bit on a successful check; if it is missing despite active DNSSEC, the chain is most likely broken. The simplified output below shows what a detected problem looks like.

Target (last clean baseline):
  DNSKEY   257  KSK   present          ok
  DNSKEY   256  ZSK   present          ok
  DS @TLD        matches KSK           ok
  RRSIG    valid for +12 days         ok
  AD bit   set                        ok
  NS       ns1/ns2.example-dns.net    ok

Observed on the current scan:
  DNSKEY   257  KSK   present          ok
  DS @TLD        matches KSK           ok
+ RRSIG    expires in 18 h            ALERT
+ NS       ns3.foreign-host.tld NEW   REVIEW

=> 1 expiring signature + 1 unexpected NS entry

It is important that the check runs against several validating resolvers and over time - a single query at your desk may show an outdated picture due to caching. This repetition and comparison over time is exactly what XICTRAQ DNS monitoring handles automatically, instead of relying on a manual spot check.

• Chain top to bottom - root, TLD and domain are checked as a connected chain of trust, not in isolation
• Expiry before outage - RRSIG remaining lifetimes are monitored so re-signing can be triggered before the SERVFAIL
• Rollover accompanied - DS and DNSKEY consistency is monitored especially closely during a rollover
• Record baseline - NS, A and MX records are compared against the released state
• Multiple viewpoints - the check runs repeatedly and not just from a single network perspective

DNS Monitoring as Part of Overall Monitoring

DNSSEC monitoring does not stand alone. It is one building block of continuous availability and security control that spans from reachability through encryption to the functionality of individual pages. A broken link in DNS renders every other safeguard ineffective, because the request does not even reach the right server in the first place - which is why the DNS layer belongs at the start of any monitoring strategy.

An undetected DNS manipulation or a DNSSEC outage often shows up to visitors as what they take to be a different problem: a page that does not load, a form that runs into the void, or a script error. Anyone who also runs JavaScript error monitoring in the frontend and the automated monitoring of broken links and 404 pages in parallel sees more quickly whether the cause lies in the application - or one layer deeper, in DNS. Combining several layers narrows troubleshooting from hours to minutes.

The practical value lies in the time factor. An expiring signature date can be spotted weeks in advance and fixed calmly, instead of being surprised by failed services in the middle of the night. An unexpected record change becomes visible while it is still fresh - not only once traffic has already been redirected. This shortening of the response window is the real protection that continuous monitoring delivers.

For regulated sectors there is a further aspect: supervisory frameworks such as NIS2 require demonstrable technical and organisational measures as well as a prompt response to security incidents. Documented, continuous DNS and DNSSEC monitoring is concrete evidence that the availability of your own services is actively controlled and that deviations are noticed in good time. In an audit you can then show that a detected problem did not go unnoticed for months but was addressed within hours. This turns a purely technical measure into a building block of organisational due diligence at the same time - a point that carries weight precisely in how you present yourself to customers and auditors.

DNSSEC is a strong tool against manipulation - but only as long as the chain is maintained. It is not a device you switch on once and forget, but an ongoing process with expiry dates and key rotations. DNS monitoring turns this silent, invisible process into a visible, alertable signal and helps ensure that the protection you built still holds tomorrow.

Frequently Asked Questions on DNSSEC and DNS Monitoring