Rust hickory-recursor cache flaw enables cross-zone DNS poisoning

Rust’s memory safety did not save hickory-recursor from a serious DNS failure: RUSTSEC-2026-0106 exposed a cross-zone cache-poisoning flaw that could redirect traffic without touching a buffer overflow or use-after-free. The issue, published on April 22, 2026, hit the experimental recursive resolver path in hickory-dns and showed how a bad cache key can be as dangerous as classic memory corruption.

The problem came down to how the record cache was built. Hickory-recursor stored DNS responses keyed by each record’s own name and type, instead of by the query that caused the response to be inserted. That subtle mismatch let an attacker-controlled nameserver for attacker.poc slip a forged AUTHORITY-section NS record for victim.poc into a shared cache. Once that happened, later lookups for the victim zone could be sent to the attacker’s nameserver instead of the legitimate one. The advisory’s key detail is that the legitimate nameserver could receive zero queries while the poisoned one took over resolution for the zone.

This was not a one-off edge case. RustSec’s package page described the bug as an AUTHORITY-section NS record accepted from a sibling zone via parent-pool zone-context elevation, meaning the bailiwick check used the NS pool that serviced the lookup rather than the zone being queried. In plain DNS terms, the resolver trusted the wrong context. That is exactly the kind of architectural mistake that turns a recursive resolver into a traffic-steering tool for an attacker.

There is no patched version for the old hickory-recursor crate, because the code was folded into hickory-resolver under the non-default recursor feature flag. The fix is to move to hickory-resolver 0.26.0 with recursor enabled, where response-level caching keys entries by the originating query, so an answer for attacker.poc cannot contaminate the cache entry for victim.poc. All published versions of the experimental crate were affected.

The larger lesson lands well beyond one advisory. Hickory DNS describes its resolver as a 100% in-process DNS resolver that does not use the host OS resolver, and its recursive role is still documented as experimental. That matters for anyone running their own resolver or testing DNS tooling at home: the security boundary is not just memory safety, it is also cache shape, bailiwick logic, and where trust is assigned. With Hickory discussed in the context of deployment at Let’s Encrypt and even some Google Pixel devices, the stakes are no longer purely hobbyist. DNS software can be Rust-safe and still be operationally unsafe if its architecture gives an attacker the right cache key.