CME-405

DNSSEC Validation

Harden Network Unquantified evidence Preventive

Description

Enables DNSSEC validation on the local resolver to cryptographically verify DNS response authenticity using the RRSIG/DNSKEY/DS chain of trust rooted at the DNS root zone. For DNSSEC-signed zones, the resolver verifies that each DNS record carries a valid RRSIG signature produced by the zone's signing key (DNSKEY), and that the signing key is authenticated by a DS record in the parent zone, chaining up to the root trust anchor. Spoofed or modified DNS responses for signed zones are rejected because they lack valid cryptographic signatures — this prevents DNS cache poisoning (Kaminsky attack), DNS spoofing, and DNS-based redirection for services in signed zones. Critical scope limitation: DNSSEC validation only protects lookups for zones that have deployed DNSSEC signing — unsigned zones (still the majority of domains) receive no protection, and the resolver accepts their responses without cryptographic verification. DNSSEC provides data integrity (the response hasn't been modified) and origin authentication (the response came from the authoritative zone), but NOT confidentiality — DNS queries and responses are still visible on the wire unless combined with DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH). Configured via systemd-resolved (DNSSEC=yes), unbound (auto-trust-anchor-file, val-permissive-mode: no), BIND (dnssec-validation auto), or Windows DNS Server (DNSSEC validation settings).

CVSS Vector Impacts

Metric	Transition	Rationale
Attack Complexity (AC)	L → H	Without DNSSEC validation, a network attacker can poison DNS caches or spoof DNS responses with forged records (Kaminsky attack, on-path modification) — the resolver has no way to distinguish legitimate from forged responses. With DNSSEC validation enabled, the resolver rejects any response for a signed zone that lacks a valid RRSIG signature chaining to the root trust anchor. The attacker must compromise a zone signing key or find a collision in the DNSSEC hash algorithm (SHA-256) — both fundamentally harder than forging an unsigned UDP packet. Scope limitation: for unsigned zones (still the majority of domains), DNSSEC validation provides no protection and the attacker's complexity is unchanged. The AC shift applies only to lookups for DNSSEC-signed zones

CWE Relationships

CWE-350 CWE-345

Verification

Verify DNSSEC validation is enabled in the local resolver and that signed zones are validated with the AD flag

$ resolvectl status 2>/dev/null | grep -i 'DNSSEC' | grep -ci 'yes'
# Expected: >=1

Platform: linux

$ grep -E '^[^#]*val-permissive-mode' /etc/unbound/unbound.conf 2>/dev/null | grep -c 'no'
# Expected: 1

Platform: linux

$ grep -E '^[^#]*dnssec-validation' /etc/named.conf /etc/bind/named.conf.options 2>/dev/null | grep -ci 'auto\|yes'
# Expected: >=1

Platform: linux

$ dig +dnssec +short SOA gov. 2>/dev/null | head -1 | grep -c '.'
# Expected: 1

Platform: any

$ Get-DnsServerSetting -All 2>$null | Select-Object -ExpandProperty EnableDnsSec
# Expected: True

Platform: windows

Remediation

linux Enable DNSSEC validation in systemd-resolved


mkdir -p /etc/systemd/resolved.conf.d && printf '[Resolve]\nDNSSEC=yes\n' > /etc/systemd/resolved.conf.d/99-cme-405-dnssec.conf
systemctl restart systemd-resolved

linux Enable strict DNSSEC validation in Unbound resolver


printf 'server:\n    auto-trust-anchor-file: "/var/lib/unbound/root.key"\n    val-permissive-mode: no\n' > /etc/unbound/conf.d/cme-405-dnssec.conf
unbound-anchor -a /var/lib/unbound/root.key || true
systemctl restart unbound

windows Enable DNSSEC validation on Windows DNS Server


Set-DnsServerSetting -EnableDnsSec $true; Add-DnsServerTrustAnchor -Name '.' -CryptoAlgorithm RsaSha256 -KeyTag 20326 -DigestType Sha256
Restart-Service DNS

Applicability (CVE 5.2.0 Schema)

Vendor	Product	CPEs	Platforms	Status
redhat	enterprise_linux	`cpe:2.3:o:redhat:enterprise_linux:8:::::::` `cpe:2.3:o:redhat:enterprise_linux:9:::::::` `cpe:2.3:o:redhat:enterprise_linux:10:::::::*`	All	applicable