CVE-2023-50868

What it actually does

This flaw affects DNSSEC validation of NSEC3 closest-encloser proofs. A remote, unauthenticated attacker can send or induce DNS queries for large volumes of random, nonexistent subdomains under DNSSEC-signed zones that use NSEC3. Vulnerable resolvers may perform excessive SHA-1 hashing while validating negative DNSSEC responses, consuming CPU and reducing resolver capacity. The practical impact is denial of service or severe latency for DNS resolution; it does not provide code execution or direct data access.

Why it matters to the business

DNS resolvers are a critical dependency for application access, authentication, email delivery, monitoring, and outbound connectivity. Exploitation can make otherwise healthy services appear unavailable because clients cannot resolve names reliably. The EPSS score is high at 0.81729, indicating elevated likelihood of exploitation activity even though this is not currently listed in CISA KEV and no ransomware use is reported. Because the issue has been public for 909 days, internet-facing recursive resolvers and DNSSEC-validating infrastructure should be treated as priority remediation targets.

How an attack unfolds

An attacker identifies or targets DNS resolvers that perform DNSSEC validation and can be reached directly or indirectly. They then generate many DNS lookups for random, likely nonexistent subdomains in DNSSEC-signed zones that use NSEC3. Each query causes the resolver to request and validate negative DNSSEC proofs. In vulnerable implementations, the closest-encloser proof validation path can require large numbers of SHA-1 computations. By sustaining this query pattern, the attacker drives high CPU usage on the resolver, causing slow responses, dropped queries, timeouts, cache inefficiency, and potential DNS service outage for dependent systems.

How to fix it

Upgrade affected DNS software to a vendor-supported release that includes the upstream fixes. For source-based builds, ensure PowerDNS/pdns includes commit a06ef30be67538e93f8cc08ccac78eaefbbfd4cc and ISC BIND9 includes commit 0dab57e15f7d02d8b0c9bff513fe1c735f499322, or use packaged releases that incorporate those changes. Remove exposure of recursive resolvers to untrusted networks where not required, disable open recursion, and enforce access control lists for recursion. Apply DNS response-rate limiting, query-rate limiting, and upstream network filtering where appropriate. For authoritative zones under organizational control, prefer current DNSSEC guidance: avoid high NSEC3 iteration counts, use conservative NSEC3 parameters, or use NSEC where operationally acceptable. If immediate patching is not possible, reduce attack surface by limiting who can query validating resolvers and monitor for random-subdomain floods.

How to confirm the fix worked

Confirm installed BIND9 and PowerDNS builds are vendor releases containing the fixes or source builds containing the listed commits. Verify recursive DNS servers are not open resolvers by testing from untrusted networks and confirming recursion is refused. Review DNSSEC configuration and authoritative zone parameters for excessive NSEC3 iteration counts. In a controlled test environment, generate limited queries for nonexistent randomized subdomains under DNSSEC-signed NSEC3 zones and confirm resolver CPU remains bounded and DNS latency does not spike. Monitor production resolver metrics after remediation for reduced CPU saturation, lower timeout rates, stable query latency, and normal NXDOMAIN volumes.

Typical attack path

1. Identify DNSSEC-validating recursive resolvers or infrastructure that can be queried directly or through open resolver exposure.
2. Select DNSSEC-signed domains using NSEC3 where negative responses trigger costly closest-encloser proof validation.
3. Generate high volumes of queries for randomized nonexistent subdomains to avoid cache hits.
4. Force the resolver to repeatedly validate NSEC3 negative responses and perform excessive SHA-1 computations.
5. Sustain traffic until resolver CPU is exhausted, DNS latency increases, and clients experience lookup failures or application outages.

How to detect it

Look for evidence of DNS resource-exhaustion activity rather than host compromise. Primary sources are recursive resolver query logs, DNS response logs, resolver statistics channels, system CPU metrics, network flow records, and service logs from BIND9 or PowerDNS. Hunt for abrupt increases in NXDOMAIN or NODATA responses, unusually high volumes of unique random-looking subdomains under the same parent domains, low cache-hit ratios, DNSSEC validation latency, SERVFAIL spikes, client timeout increases, and resolver CPU dominated by DNS processes. On hosts, check whether named, pdns_server, pdns_recursor, or related resolver processes consumed sustained high CPU during DNS query surges. In packet captures or DNS telemetry, look for many queries with high-entropy leftmost labels and repeated DNSSEC negative responses containing NSEC3 records. If netflow is available, identify source IPs producing disproportionate UDP/TCP 53 query volumes against recursive resolvers. Because exploitation does not require malware deployment, file-system artifacts are not expected unless the attack was accompanied by separate compromise activity.

• NSEC3
• closest encloser
• NXDOMAIN
• NODATA
• SERVFAIL
• RRSIG
• DNSKEY
• random subdomain
• high NXDOMAIN rate
• high SERVFAIL rate
• named
• pdns_server
• pdns_recursor
• /var/log/named/
• /var/log/bind/
• /var/log/pdns.log
• /var/log/pdns-recursor.log
• query-errors
• resolver priming query complete
• validating
• SHA1
• SHA-1
• udp/53
• tcp/53

What your security team should do

• Prioritize patching internet-facing and high-volume DNSSEC-validating recursive resolvers because the EPSS score is high and the issue has been public for an extended period.
• Inventory BIND9 and PowerDNS deployments, including containers, appliances, source builds, and embedded resolver services.
• Disable open recursion and restrict recursive DNS service to trusted client networks only.
• Apply vendor updates containing PowerDNS commit a06ef30be67538e93f8cc08ccac78eaefbbfd4cc and BIND9 commit 0dab57e15f7d02d8b0c9bff513fe1c735f499322, or later supported releases.
• Add monitoring and alerting for resolver CPU saturation, DNS timeout increases, NXDOMAIN spikes, and surges in randomized subdomain queries.
• Review DNSSEC-signed authoritative zones for NSEC3 configuration and reduce high iteration counts where present.
• Prepare operational runbooks for DNS degradation, including failover to patched resolvers and temporary network filtering of abusive sources.