Unbound CVE-2025-11411 Patch: Stop DNS Delegation Poisoning

NLnet Labs has released an emergency patch for Unbound after researchers disclosed CVE-2025-11411, a cache‑poisoning class vulnerability that lets crafted responses carrying promiscuous NS resource record sets (RRSets) in the DNS authority section trick resolvers into updating delegation data — effectively enabling domain hijacking of non‑DNSSEC zones unless mitigated.

Background / Overview​

Unbound is a widely used open‑source recursive DNS resolver maintained by NLnet Labs. On October 22, 2025 the project published version 1.24.1 specifically to address CVE‑2025‑11411, describing a scenario where unsolicited NS RRSets returned in the authority section of otherwise positive DNS replies can be accepted and used to overwrite the resolver’s delegation information for a zone. This acceptance enables an attacker who can inject or spoof a reply — for example via packet spoofing, fragmented packet manipulation, or on‑path interception — to introduce malicious NS records and associated address records that cause future queries to be routed to attacker‑controlled name servers.
This vulnerability is important because it targets a core operational assumption in some resolvers: that certain authority‑section data accompanying otherwise legitimate replies should be trusted and may be used to update cached delegation state. When resolvers accept promiscuous NS RRSets without strong provenance checks — and when DNSSEC is not in use for the affected zones — those updates can be poisonous. The Unbound team fixed the problem by scrubbing unsolicited NS RRSets (and their address records) from replies in Unbound 1.24.1, preventing this unexpected acceptance path.

---

Technical anatomy: what “promiscuous” NS RRSets mean and why they matter​

How DNS delegation and the authority section normally work​

When a resolver queries for a domain it does not know, delegation information — the NS records for the next zone — is crucial. A normal DNS reply can include:

• an answer section (the requested RR),
• an authority section (delegation NS RRs and related SOA), and
• an additional section (glue A/AAAA records).

Resolvers historically use authority and additional sections to build and refresh delegation knowledge. For zones not covered by DNSSEC, resolvers must rely on heuristics and protocol semantics to decide what to record. If a resolver accepts unsolicited NS records as authoritative when they appear in a response that otherwise appears trustworthy, attackers can inject NS RRSets that steer queries to attacker name servers.

The specific weakness in Unbound​

CVE‑2025‑11411 arises because Unbound up to and including 1.24.0 could accept and cache NS RRSets that complemented positive answers in the authority section — even when those NS sets were not solicited or otherwise linked to a legitimate, provable delegation update. The problem becomes exploitable when an attacker can place malicious NS RRSets into a resolver’s received packet (via spoofing, traffic interception, or fragmentation attacks that allow injection). Because those RRSets look like in‑zone delegation data and carry sufficient apparent trust, Unbound could update its cached delegation information, causing subsequent queries for the affected zone to be sent to the attacker's name servers. NLnet Labs’ release notes state that 1.24.1 mitigates the issue by scrubbing unsolicited NS RRSets and their address records from replies.

Why DNSSEC would have stopped this but is not universal​

DNSSEC protects the authenticity and integrity of DNS data by enabling resolvers to cryptographically validate RRs. If the target zone and its delegation are DNSSEC‑signed and the resolver enforces validation, injected NS RRSets lacking valid signatures will fail validation and be ignored. In practice, however, many zones and segments of the DNS are not DNSSEC‑signed (or DNSSEC validation is not enforced in a resolver’s configuration), leaving them vulnerable to this class of poisoning. The Unbound advisory implies this is a multi‑vendor cache‑poisoning pattern for non‑DNSSEC protected data, reinforcing that the absence of DNSSEC is a root factor in exploitability.

---

Exploitation scenarios and attacker model​

Preconditions for exploitation​

• The attacker must be able to inject or spoof DNS responses to the target recursive resolver. This can be achieved by:
• on‑path network position (e.g., compromised router, MitM between resolver and authoritative server);
• injection via fragmented packet reassembly tricks or maliciously crafted fragments that cause authoritative responses to be augmented; or
• IP‑spoofing where the attacker sends forged responses and the network permits spoofed packets to reach the resolver.
• The affected zone must not be validated with DNSSEC on the resolver.
• The resolver must be using a vulnerable Unbound version (≤ 1.24.0) or another resolver implementation that exhibits the same wrong trust‑acceptance behavior.

These preconditions make the attack feasible for targeted, opportunistic, or on‑path adversaries, less so for remote attackers with no network position; nevertheless network‑level spoofing and fragmentation attacks have been used historically to poison caches at scale.

What an attacker achieves​

• Persistent control of a resolver’s delegation cache for the targeted zone(s), redirecting queries to attacker‑controlled authoritative servers.
• Ability to serve forged resource records (A/AAAA/MX/TXT) for victims of the poisoned delegation, enabling credential capture, targeted phishing, interception of mail flow, or issuance of fraudulent TLS certificates via misissued ACME/CA flows for the hijacked domain.
• Because delegation poisoning persists in caches until expiry, the impact can be longer‑lived than a single packet attack and can massively amplify user redirection from multiple clients using the poisoned resolver. Historical DNS hijacking incidents underline the high operational impact of such delegations.

Likely targets and impact profile​

• Public resolvers and ISP resolvers that handle high volumes of client queries are high‑value targets because poisoning them affects many end users.
• Enterprise resolvers that forward queries for critical business domains (email, authentication endpoints) are strategic targets for data interception and credential theft.
• Non‑DNSSEC zones, widely used legacy services, and misconfigured delegations are the weakest links.

---

Verification — what the advisories and vulnerability trackers confirm​

Multiple independent sources confirm the core facts:

• NLnet Labs’ advisory and release notes state Unbound ≤ 1.24.0 is vulnerable and that 1.24.1 scrubs unsolicited NS records from replies.
• Public CVE aggregators and trackers (NVD, CVEDetails, Debian security tracker) reproduce the same description and list fixed package versions and distribution mappings.
• Vendor and security vendors (Tenable, SUSE trackers) have indexed the CVE and assigned mid‑range to high severity depending on scoring schema, reflecting the integrity impact and realistic attack vectors for adjacent network threat models. Note: CVSS v3/v4 scores vary by tracker; rely on vendor and local risk modeling for prioritization.

If any other public claims appear (for example around in‑the‑wild exploitation or public PoCs), treat them cautiously until multiple reputable telemetry sources corroborate active exploitation. At the time of writing, the authoritative vendor fix and advisory are the canonical sources for remediation.

---

Practical mitigation and remediation checklist (for WindowsForum readers and admins)​

Immediate actions (within 24–72 hours)

• Upgrade Unbound to 1.24.1 or later on all resolvers under your control. The Unbound release explicitly fixes CVE‑2025‑11411 by scrubbing unsolicited NS RRSets and their address records.
• If you cannot immediately upgrade, harden network controls to reduce the resolver’s exposure to spoofed responses:
• Filter and block IP‑spoofing by enforcing ingress/egress BCP‑38 (source validation) at your edge routers and upstream provider.
• Drop fragmented DNS responses from untrusted paths where possible, since fragmentation reassembly attacks are a practical injection vector.
• If you operate recursive resolvers for clients, consider temporarily restricting recursion to authenticated/known clients and applying rate‑limits and query controls.

Short‑term defensive controls (1–2 weeks)

• Enable DNSSEC validation in your resolver configuration where feasible and validate critical delegations. DNSSEC will reject forged records that lack valid signatures. Note: enabling DNSSEC requires that the upstream zones are signed and that resolution chains are complete.
• Pin delegation information for the most critical services via static stub zones or configured forwarders where business needs allow — this avoids dynamic delegation updates for those domains.
• Monitor certificate transparency (CT) logs and public CT monitoring for unexpected certificate issuance for your domains as a sign of hijacked delegations being abused by certificate authorities or ACME bots.

Longer‑term operational changes

• Adopt DNSSEC for zones you control and verify chain of trust end‑to‑end.
• Evaluate resolver hardening settings that reject unsolicited authority data and require stronger provenance checks before modifying delegation cache entries.
• Coordinate with ISPs and upstream network providers to ensure anti‑spoofing best practices are enforced.

---

Detection, logging and incident response: how to hunt for poisoning​

Indicators to watch for

• Sudden changes in authoritative name servers recorded in your resolver’s cache for a zone, especially if they point to unexpected IP addresses or new domains.
• Increased query failures or redirect patterns for services that previously resolved to known IPs.
• Unexpected TLS/HTTPS certificate issuance for your domains visible in CT logs, which can indicate that an attacker has succeeded in redirecting ACME/CA validation traffic.

Hunting recipes

• Compare resolver answers from multiple vantage points (e.g., your resolver vs. public resolvers like 1.1.1.1 / 8.8.8.8) for critical domains to spot inconsistent delegations.
• In your DNS query logs, search for authority section changes: store and diff NS RRSets over time; alert on NS changes that are not associated with expected zone management windows.
• Correlate DNS logs with TLS/CT monitors and mail flow anomalies (unexpected MX changes) — these chained signals are strong evidence of a poisoning event.

Response steps if you suspect poisoning

• Immediately validate your local resolver’s cache against authoritative servers.
• Flush cached delegation information for affected zones and, if necessary, override with static delegation (stub) entries while investigating.
• Block or isolate affected resolver processes from the network segment used for authoritative communication until patching and validation are complete.
• Perform forensic capture of relevant traffic (pcap) to assess the injection path and determine whether spoofing, fragmentation, or an on‑path compromise occurred.

---

Risk assessment and recommended prioritization​

CVE‑2025‑11411 has an integrity‑focused impact: compromise of domain resolution and redirection of user traffic. Different scoring providers present varying CVSS values depending on assumptions about attack vector and required privileges; vendors rate the vulnerability mid to high depending on the scoring scheme and adjacent assumptions. The key operational risk lies with non‑DNSSEC zones and resolvers exposed to spoofed or fragmented responses. Public resolvers, ISP resolvers, and enterprise resolvers for critical services deserve the highest priority.
Practical prioritization

• Priority 1: Public/ISP resolvers and enterprise resolvers that handle critical authentication, mail, or certificate validation flows.
• Priority 2: Internal resolvers that serve high‑value applications and that lack DNSSEC enforcement.
• Priority 3: All other resolvers — still patch, but after piloting and validating behavior in priority environments.

---

Cross‑checks and verification notes​

• The Unbound project page and release announcement are the definitive vendor statements describing the vulnerability, the fix, and the authors credited for discovery; use the NLnet Labs advisory as the canonical remediation source for Unbound deployments.
• NVD and distribution trackers (Debian, SUSE) mirror the advisory and provide distribution‑specific package mappings and status; use those trackers to map the correct fixed package version for your distribution.
• Security vendors and vulnerability databases (Tenable, feed aggregators) have indexed the CVE and provide scoring perspectives; treat numeric scores as one input to your risk model rather than an absolute — prioritize according to exposure and business impact.

Flagging unverifiable or rapidly changing claims

• Claims of widespread in‑the‑wild exploitation should be treated with caution until corroborated by multiple telemetry sources (CERTs, major DNS operator reports, or incident response firms). If such reports appear, treat them as urgent and escalate patching and monitoring accordingly.

---

Deployment and testing guidance for administrators​

• Inventory: list all hosts running Unbound and record versions across your estate.
• Pilot: test Unbound 1.24.1 in a controlled environment to confirm that scrubbing behavior does not break any expected delegation flows in your topology.
• Deploy: roll out 1.24.1 using your standard package management and change control (apt/yum/build pipelines, configuration management).
• Validate: confirm that cached NS RRSets are no longer updated with unsolicited authority RRs and that normal resolution for your zones remains correct.
• Monitor: after deployment, maintain heightened DNS telemetry and CT monitoring for 7–14 days to detect anomalies.

For distributions, consult your distro’s security tracker for the exact package names and fixed versions — Debian trackers already list fixed versions and which suites remain vulnerable.

---

Strategic takeaways for WindowsForum readers and IT teams​

• Treat DNS as a critical security control: resolution integrity underpins web, mail, authentication and certificate issuance.
• Deploy vendor fixes promptly for resolvers under your control; the Unbound 1.24.1 update is the direct fix for this issue.
• Accelerate DNSSEC adoption for domains you control and enable validation at resolvers where appropriate to reduce the attack surface for cache‑poisoning classes of bugs.
• Harden network edge practices (anti‑spoofing, fragmentation handling) and implement layered detection — DNS logs, CT monitoring and query diffing across resolvers — to catch early signs of poisoning.
• Coordinate with upstream providers and public DNS operators: large‑scale poisoning events often implicate shared infrastructure behaviors and benefit from cooperative mitigation.

---

Conclusion​

CVE‑2025‑11411 is a practical reminder that DNS cache‑poisoning remains a live, pre‑authentication integrity risk for non‑DNSSEC environments. NLnet Labs’ Unbound 1.24.1 patches the specific trust‑acceptance flaw by scrubbing unsolicited NS RRSets and their address records, and operators should treat this update as mandatory for affected resolvers.
At the same time, DNS defenses must be systemic: DNSSEC adoption, anti‑spoofing measures, resolver hardening, and vigilant telemetry together form the only reliable long‑term defense against delegation poisoning and the broader business impacts of domain hijacking. Historical DNS‑level hijacking campaigns illustrate the real‑world consequences of delegated control being abused, underlining why swift patching and layered mitigations are not optional.
(Verification note: this article cross‑checked NLnet Labs’ release, NVD/CVE aggregator entries and distribution trackers to confirm affected versions, the fix in Unbound 1.24.1, and the remediation guidance; readers should map CVE→package→KB for their specific platform before mass deployment and treat any subsequent public PoC reports as potential accelerants requiring immediate action.)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center