*[EXCLUSIVE: Deep-dive analysis.]*
Hickory DNS is a popular DNS library, client, server, and resolver written in Rust, favored for its speed and modern code. But from version .8. up to *before* .24.3 and .25.-alpha.5, it housed a sneaky vulnerability: CVE-2025-25188. If you relied on Hickory DNS for DNSSEC (DNS Security Extensions) verification, your trust in domain responses may have been misplaced—and that’s a big deal.
What Is DNSSEC, and Why Should You Care?
DNSSEC helps make sure the answers you get when looking up a website or service are not tampered with. It’s all about cryptographically signing DNS records, which the resolver client (like Hickory DNS) checks as it browses the DNS hierarchy.
When you set up DNSSEC, you usually “anchor” your trust using a trust anchor — a DNSKEY that guarantees everything signed further down the chain.
The Vulnerability: What Went Wrong?
The Hickory DNS bug revolved around how it handled trust for entire *sets* of DNSKEY records (resource record sets, or RRsets).
The Bad Logic
- If one DNSKEY in an RRset matched the trust anchor, Hickory DNS trusted all keys in that set—automatically.
- Therefore, *anyone* controlling a DNS zone could insert extra, malicious DNSKEYs alongside a valid key, and Hickory DNS would believe signatures made by those rogue keys.
A second variant involved DS (Delegation Signer) records
- If a DS record correctly authenticated a single DNSKEY, *signatures from ANY other key in the set* could be accepted.
That means, a clever attacker could “sneak in” their own keys and forge valid-looking DNS responses, completely bypassing the supposed security guarantee of DNSSEC in affected versions.
A Simple Code Example
Let’s imagine a simplified example. Suppose your Hickory DNS-based resolver has a trust anchor for the example.com. zone:
let trust_anchor = "AwEAAc..."; // Some base64 public key
let zone_dnskeys = vec![
// The legitimate key (trusted)
DNSKey::from_public_key("AwEAAc..."),
// A malicious key inserted by attacker
DNSKey::from_public_key("BADBADBAD..."),
];
if zone_dnskeys.iter().any(|key| key == &trust_anchor) {
// Hickory code before .24.3/.25.-alpha.5 did this (in effect):
// Trust ALL keys in this RRset!
for key in &zone_dnskeys {
add_trusted_key(key);
}
}
What should happen:
Only the anchor key is trusted.
What did happen:
ALL keys, even untrusted or malicious ones in the RRset, are considered “trusted” for verifying DNS records from that point on.
Their own, rogue DNSKEY
4. Hickory DNS client fetches the RRset, sees the trusted anchor, and (due to the bug) trusts *all* keys—including the rogue one.
5. Attacker now signs bad DNS data (e.g., for a spoofed subdomain, or malicious TXT records) with the rogue key—they will pass DNSSEC validation on vulnerable clients.
Result:
DNSSEC’s core promise of “bogus records are rejected” is completely broken.
The DS Variant
DS (Delegation Signer) records authenticate which DNSKEYs belong to a delegated zone (like from .com to example.com).
- If the DS signs *one* DNSKEY, Hickory DNS would extend trust to *all* the DNSKEYs it got back in that RRset.
Versions Affected and Details
- Vulnerable: .8. and up, until .24.3, and also .25.-alpha.4 and below (including alpha versions).
.25.-alpha.5 (alpha branch)
If you use or embed Hickory DNS for any DNSSEC-related logic, *update now*.
References & Further Reading
- GitHub Security Advisory for Hickory DNS
- CVE Record on NVD *(May not be published yet)*
- Hickory DNS Changelog
Remediation & What You Should Do
1. Upgrade ASAP
Update your Hickory DNS dependency to at least .24.3 (stable) or .25.-alpha.5 if you need the latest.
2. Audit Trust Models
If you use DNSSEC, check to make sure no suspicious or unexpected DNSKEYs were ever trusted in your deployments.
3. Monitor for Spoofing
Be wary of unexpected DNS responses or signature verifications—especially if you operate or rely on critical DNS infrastructure.
Conclusion: What This Means
CVE-2025-25188 is a big reminder: even the best cryptographic systems can be broken by logic errors and improper trust handling. If you rely on Hickory DNS for DNSSEC, this bug means attackers could have slipped in forged answers—ruining the security you counted on.
Fix: *Always* verify which keys are being trusted and why.
For those using Hickory DNS for production DNSSEC validation:
Upgrade now and audit.
*Stay secure, keep your trust model tight, and don’t let small oversights become big breaches.*
Timeline
Published on: 02/10/2025 18:15:35 UTC