RustSec Flags DoS Flaws in Hickory DNS Stack, Memory and CPU Exhaustion Risks
RustSec’s latest hickory warnings are not theory. A bad DNSSEC response can spin validators into loops, burn memory, or chew CPU until a service falls over.

RustSec’s newest hickory advisories land on the part of the stack that sits closest to hostile traffic: DNSSEC validation and message encoding. The result is a familiar but dangerous mix of denial-of-service paths, where a single malformed response can push a Rust service into an unbounded loop, a panic in debug builds, or an out-of-memory crash in release builds.
The sharpest finding is RUSTSEC-2026-0118. In hickory-proto, NSEC3 closest-encloser proof validation can loop forever when the DNS response’s SOA owner is not an ancestor of the queried name. In debug builds, the root check can panic. In release builds, the code can keep allocating until memory is exhausted. RustSec paired that with RUSTSEC-2026-0120, which reports the same bug class after the functionality moved from hickory-proto into hickory-net in the 0.26.0 release. For users who need that path, RustSec pointed to hickory-net 0.26.1.
The third advisory, RUSTSEC-2026-0119, is different but just as operationally ugly. During message encoding, hickory-proto’s name compression logic can trigger CPU exhaustion because it performs repeated linear scans over many candidate labels. Feed it a malicious message with lots of records and the encoder does more and more work for no useful result. RustSec recommended hickory-proto 0.26.1 for that fix and described the issue as similar to CVE-2024-8508.

The pattern matters because Hickory DNS is not an edge-case crate. The project describes itself as a Rust-based DNS client, server, and resolver, which puts it inside real infrastructure paths where validators, recursive resolvers, and application servers all depend on fast, correct handling of untrusted wire data. The GitHub security advisory for the NSEC3 issue listed David Cook of the Internet Security Research Group as the reporter and marked the severity High, with no known CVE and no CWEs assigned. RustSec tagged the NSEC3 advisories as denial-of-service issues with dns, dnssec, and nsec3 labels.
The bigger lesson is hard to miss: Rust’s memory safety does not save a DNS stack from denial-of-service bugs. A protocol parser can still burn CPU, allocate itself into a corner, or recurse into invalid state when the input is adversarial. Hickory has already wrestled with NSEC3 edge cases before, including earlier work on limiting NSEC3 iterations and references to RFC 5155 section 10.3. That history makes these advisories look less like isolated slips and more like a reminder that DNSSEC remains one of the nastiest attack surfaces in the Rust ecosystem.
Know something we missed? Have a correction or additional information?
Submit a Tip

