CVE-2025-25188: Hickory DNS DNSSEC Validation Vulnerability

CVE-2025-25188 Overview

CVE-2025-25188 affects Hickory DNS, a Rust-based DNS client, server, and resolver. The vulnerability impacts DNSSEC validation in the client library, stub resolver, and recursive resolver. Versions from 0.8.0 through 0.24.2 and 0.25.0-alpha.4 trust an entire RRset of DNSKEY records once any single DNSKEY establishes trust. An attacker controlling a zone can leverage this to authenticate records signed by unrelated keys. The maintainers released fixes in versions 0.24.3 and 0.25.0-alpha.5. This is an improper verification of cryptographic signature issue tracked as [CWE-345].

Critical Impact
DNSSEC validation can be bypassed for records within a zone, allowing an attacker with a trusted DNSKEY to spoof arbitrary DNS responses signed by any DNSKEY in that zone.

Affected Products

Hickory DNS versions 0.8.0 through 0.24.2
Hickory DNS 0.25.0-alpha.1 through 0.25.0-alpha.4
Applications relying on Hickory DNS client library, stub resolver, or recursive resolver with DNSSEC verification enabled

Discovery Timeline

2025-02-10 - CVE-2025-25188 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-25188

Vulnerability Analysis

Domain Name System Security Extensions (DNSSEC) rely on a chain of trust anchored in configured trust anchors. Hickory DNS validated DNSKEY RRsets by verifying that at least one key in the set matched a trust anchor. Once that single match succeeded, the resolver treated every DNSKEY in the RRset as authenticated. This behavior collapses the per-key trust model into a per-RRset trust model.

An attacker who controls a zone can publish additional DNSKEYs alongside a legitimately trusted key. Signatures produced by those attacker-controlled keys then pass validation. A second variant occurs with Delegation Signer (DS) records: an authenticated DS covering one DNSKEY extends trust to signatures produced by unrelated DNSKEYs in the same zone.

Root Cause

The validation routine iterated DNSKEY records and short-circuited on the first successful trust anchor match, then applied that trust to the entire RRset rather than binding trust to the specific key. The fix ensures the RRSIG covering the DNSKEY RRset must be verified against a DNSKEY that itself is authenticated by the trust anchor or DS record.

Attack Vector

Exploitation requires an attacker to serve DNS responses for a zone that a Hickory DNS resolver evaluates. The attack proceeds over the network with low complexity and requires low privileges tied to authority over a zone. Successful exploitation impacts integrity of DNS resolution without directly affecting confidentiality or availability.

rust

         )
     }
 
+    /// Returns true if this is an RRSIG RecordType
+    #[inline]
+    pub fn is_rrsig(self) -> bool {
+        self == Self::RRSIG
+    }
+
     /// Returns true if this is a Zero (unspecified) RecordType
     #[inline]
     pub fn is_zero(self) -> bool {

Source: Hickory DNS patch commit e118c6e. The patch introduces an is_rrsig helper used by updated validation logic that verifies the RRSIG over the DNSKEY RRset with an already-authenticated key before extending trust.

Detection Methods for CVE-2025-25188

Indicators of Compromise

DNS responses returning unexpected records for authoritative zones that pass DNSSEC validation on Hickory-based resolvers but fail on independent validators such as delv or dig +sigchase.
Zones that publish multiple DNSKEYs where only a subset appear in the DS RRset at the parent.
Divergence in resolved IP addresses between Hickory DNS resolvers and reference validating resolvers for the same query.

Detection Strategies

Inventory Rust services and containers for dependencies on hickory-dns, hickory-resolver, hickory-client, hickory-server, and legacy trust-dns-* crates below the fixed versions.
Cross-validate DNSSEC-protected responses against a second independent validating resolver and alert on mismatches.
Run software composition analysis (SCA) tooling in CI pipelines to fail builds pulling in vulnerable Hickory DNS versions.

Monitoring Recommendations

Monitor DNS query and response logs for unexpected DNSKEY or DS record changes on zones consumed by Hickory-based resolvers.
Log resolver version strings during startup and centralize them for auditing against the fixed release baseline.
Track outbound resolver traffic patterns for anomalies suggesting redirection of validated responses.

How to Mitigate CVE-2025-25188

Immediate Actions Required

Upgrade Hickory DNS to version 0.24.3 or 0.25.0-alpha.5 or later in all Rust applications, resolvers, and container images.
Rebuild and redeploy binaries after updating Cargo.lock to ensure the patched crate is actually linked.
Audit third-party Rust binaries for embedded Hickory DNS usage and coordinate updates with upstream maintainers.

Patch Information

The fix is available in Hickory DNS 0.24.3 and 0.25.0-alpha.5. Details are published in GitHub Security Advisory GHSA-37wc-h8xc-5hc4 and implemented in commit e118c6e. The patch requires each DNSKEY used to authenticate records to itself be validated through the trust chain rather than inheriting trust from a sibling key.

Workarounds

Disable DNSSEC validation in Hickory DNS configurations where upgrading is not immediately possible, accepting the loss of authentication guarantees.
Route DNS traffic through an upstream validating resolver such as Unbound or BIND that performs independent DNSSEC verification.
Restrict resolver trust anchors to zones under direct administrative control until patched builds are deployed.

bash

# Update Hickory DNS crate to a fixed version
cargo update -p hickory-resolver --precise 0.24.3
cargo update -p hickory-proto --precise 0.24.3
cargo build --release

# Verify the resolved version
cargo tree -i hickory-proto