A DNSSEC downgrade attack attempts to make a validating resolver accept an unsigned (or improperly signed) DNS response for a domain that has DNSSEC enabled. If successful, the attacker bypasses the cryptographic verification that DNSSEC provides, enabling cache poisoning, response forgery, or other manipulation that DNSSEC was designed to prevent.
DNSSEC was built to solve DNS's fundamental trust problem — the original protocol accepts any response without verification. A downgrade attack undermines that solution by convincing the resolver that verification is not needed for a particular response.
How the DNSSEC Chain of Trust Works
To understand the downgrade, you need to understand what it breaks.
DNSSEC creates a chain of trust from the root zone down to the individual domain:
Root (.) → Signs the .com DS record
└─ .com → Signs the example.com DS record
└─ example.com → Signs its own A, MX, TXT records with RRSIG
Each level signs a Delegation Signer (DS) record that authenticates the next level's key. A validating resolver follows this chain:
- It trusts the root zone's key (built into the resolver)
- It verifies the
.comkey using the DS record signed by the root - It verifies
example.com's key using the DS record signed by.com - It verifies the actual DNS response using the key for
example.com
If any step in the chain is broken or missing, the resolver should reject the response.
How Downgrade Attacks Work
Response Stripping
A man-in-the-middle attacker intercepts DNS traffic between the resolver and upstream servers. When the resolver queries for a DNSSEC-signed domain, the attacker:
- Intercepts the legitimate response (which contains RRSIG signatures and DS records)
- Strips the DNSSEC records (RRSIG, NSEC/NSEC3, DS)
- Forwards the stripped response to the resolver
If the resolver falls back to accepting the unsigned response instead of treating the missing signatures as an error, the downgrade succeeds.
Resolver → Query: example.com A +dnssec
↓
MITM Attacker intercepts
↓
Authoritative Server → Response with RRSIG, NSEC, etc.
↓
Attacker strips RRSIG and NSEC records
↓
Resolver receives: example.com A record (no DNSSEC)
↓
Vulnerable resolver: "No signatures? I'll accept it anyway."
Secure resolver: "SERVFAIL — expected DNSSEC but signatures missing."
Delegation Manipulation
A more sophisticated approach targets the DS record at the parent zone. If the attacker can forge a response from the .com TLD servers that omits the DS record for example.com, the resolver may conclude that example.com is not DNSSEC-signed at all.
This is harder to execute because TLD servers are typically well-protected, but it is the theoretical basis for the most dangerous downgrade scenarios.
Exploiting Algorithm Rollover
When a domain transitions between DNSSEC algorithms (e.g., from RSA to ECDSA), there is a period where both old and new keys may be valid. If the resolver does not properly handle algorithm rollover, an attacker may be able to present responses signed with a weaker or deprecated algorithm.
Why Resolvers Are Vulnerable
Not all resolvers handle DNSSEC validation equally:
Permissive validation (vulnerable): The resolver performs DNSSEC validation when signatures are present but accepts unsigned responses silently if they are missing. This is the default behavior of some resolvers, especially when DNSSEC validation is only partially configured.
Strict validation (secure): The resolver checks the chain of trust. If a DS record exists at the parent zone (indicating the domain should be signed) but the response lacks valid signatures, the resolver returns SERVFAIL. It does not fall back to an unsigned response.
The difference between these two modes is the difference between DNSSEC that protects you and DNSSEC that only provides a false sense of security.
How Attackers Discover This Weakness
An attacker tests a resolver's DNSSEC validation behavior:
# Query a domain with intentionally broken DNSSEC
dig sigfail.verteiltesysteme.net A @target-resolver
# Secure resolver: returns SERVFAIL (validation failed)
# Vulnerable resolver: returns an answer (accepted despite bad signatures)
If the resolver returns an answer for a known DNSSEC-failure domain, it is not performing strict validation and is vulnerable to downgrade attacks.
The attacker can also test whether the resolver requests DNSSEC data at all:
# Check if resolver asks for DNSSEC records
dig example.com A +dnssec @target-resolver
# Look for RRSIG records in the response
# If absent, the resolver may not be DNSSEC-aware
How to Test Your Own Resolver
Test Validation Strictness
# This domain has intentionally broken DNSSEC
dig sigfail.verteiltesysteme.net A @your-resolver
Secure result: SERVFAIL (the resolver rejected the invalid signatures) Vulnerable result: An A record is returned (the resolver ignored the validation failure)
Test Port Randomization
dig +short porttest.dns-oarc.net TXT @your-resolver
Source port randomization is a complementary defense. Even if DNSSEC is not deployed on a particular domain, port randomization makes cache poisoning harder.
Verify DNSSEC-Signed Domain Resolution
dig example.com A +dnssec @your-resolver
Look for RRSIG records in the response and the ad (Authenticated Data) flag in the response header. The ad flag indicates the resolver validated the DNSSEC signatures.
You can also use the DNS Inspector to examine DNSSEC records for any domain.
How to Defend Against It
Configure Strict DNSSEC Validation
Ensure your resolver performs strict validation — rejecting responses that should be signed but are not:
Unbound:
server:
# Enable DNSSEC validation
module-config: "validator iterator"
# Use the root trust anchor
auto-trust-anchor-file: "/var/lib/unbound/root.key"
BIND:
options {
dnssec-validation auto;
};
The auto setting tells BIND to use the built-in root trust anchor and perform full validation.
Monitor for DNSSEC Failures
Set up monitoring that alerts you to DNSSEC validation failures for your own domains. A sudden increase in SERVFAIL responses from validating resolvers may indicate an attack in progress or a misconfiguration.
Encrypt DNS Transport
Use DNS over TLS (DoT) or DNS over HTTPS (DoH) between your resolver and upstream servers. This prevents man-in-the-middle stripping of DNSSEC records because the attacker cannot intercept and modify the encrypted traffic.
Keep Resolver Software Updated
Resolver software is regularly updated with fixes for DNSSEC validation edge cases. Running outdated software may leave you vulnerable to known downgrade techniques.
Maintain DS Records During Key Rollover
When rotating DNSSEC keys, follow the proper rollover procedure (RFC 7583). Ensure that DS records at the parent zone are updated in the correct sequence to prevent a window where validation fails legitimately, which could mask a downgrade attack.
Mitigation Checklist
- DNSSEC validation is enabled in strict mode on all resolvers
- Resolver correctly returns SERVFAIL for domains with invalid DNSSEC
- Root trust anchor is up to date and automatically maintained
- DNS transport is encrypted (DoT/DoH) between resolver and upstream
- Resolver software is patched and current
- DNSSEC key rollover procedures are documented and tested
- Monitoring tracks DNSSEC validation failure rates
- DS records are verified at the parent zone for all signed domains
Common Misconfigurations
- DNSSEC validation set to "permissive" instead of "strict" — the resolver accepts unsigned responses silently
- Root trust anchor not updated after KSK rollover — the resolver cannot validate any DNSSEC chain, so it falls back to accepting unsigned responses
- NAT or middlebox stripping DNSSEC records — some network devices strip DNS extension fields, removing DNSSEC data from responses
- Mixed validation policy — some resolvers in the fleet validate strictly while others do not, creating inconsistent behavior
- Not testing with known-bad DNSSEC domains — administrators assume validation works without verifying
Ethical Note
DNSSEC downgrade testing should only be performed against your own resolvers. Set up a test resolver, configure DNSSEC validation, and test it against known DNSSEC-failure domains. Do not attempt to strip DNSSEC records from traffic on networks you do not own — this is a man-in-the-middle attack and is illegal without authorization.
This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Cache Poisoning, What Is DNSSEC.