Hickory DNS Approaches Production Readiness as Memory-Safe DNS Alternative

Figure 1: Visual representation of the BeyondTrust vulnerability chain

On February 11, 2025, David Cook published an update on the Prossimo blog detailing the progress of Hickory DNS toward production readiness. Prossimo is an initiative of the Internet Security Research Group (ISRG), the nonprofit organization behind Let's Encrypt.

The update outlined improvements made over the past year across three main areas: DNSSEC support, specification conformance, and production readiness features.

Benjamin Fry, the creator of Hickory DNS, has been working with Prossimo on the project. Dirkjan Ochtman, one of the Hickory DNS maintainers, will be working under contract with Prossimo to drive development forward in the coming year.

The project received financial support from the Sovereign Tech Agency and craig newmark philanthropies, according to the announcement.

DNSSEC Validation Support

Ferrous Systems led the implementation of DNSSEC features in Hickory DNS. The recursive resolver now supports DNSSEC validation, whereas previously only basic client-side validation existed. According to Ferrous Systems' blog post, the implementation required special handling of DNSSEC-related flags and record types throughout the resolver.

Support was added for generating and validating NSEC3 records, as specified in RFC 5155. NSEC3 is the successor to the NSEC record type, and both are used to authenticate negative responses, confirming that specific records do not exist.

A conformance test suite was added to verify that specific requirements in DNSSEC RFCs were implemented correctly. The test framework allows running multiple DNS server implementations together in a virtual network, enabling comparison of Hickory DNS behavior against other implementations.

Security Audit Findings

Prossimo hired OSTIF to perform a security audit of Hickory DNS. The audit identified denial of service vulnerabilities via resource exhaustion affecting multiple components:

• Call stack exhaustion in the recursive resolver
• Memory consumption by the recursive resolver
• TCP connection setup
• TLS/QUIC handshakes
• DNSSEC verification (the KeyTrap vulnerability)

All identified issues have been addressed through fixes documented in the project's GitHub repository.

Specification Conformance Fixes

Multiple protocol correctness fixes were implemented over the past year. New conformance tests based on RFC 8906 identified issues when handling unrecognized opcodes and empty question sections. Additional test fixtures from an IMC 2023 paper by Nosyk et al. provided a variety of misconfigured zones representative of problems encountered in production environments.

The recursive resolver received fixes for infinite loops when encountering missing glue records, lame delegations, and other edge cases. Error propagation was improved throughout the codebase, correcting response codes sent when certain errors are encountered.

Truncated response handling was fixed to address an edge case where TCP responses could be discarded in favor of truncated UDP responses. CAA record handling received multiple fixes involving invalid property values and issuer names, which is relevant for certificate authorities like Let's Encrypt.

Figure 2: How the authentication bypass vulnerability works

Memory Safety Benefits

DNS server implementations written in C have been affected by memory safety vulnerabilities over the years. A Rust implementation eliminates entire classes of bugs including buffer overflows, use-after-free errors, and null pointer dereferences. For critical infrastructure like DNS, reducing the attack surface provides meaningful security improvements.

Let's Encrypt Integration

Deployment at Let's Encrypt would provide Hickory DNS with a high-profile production environment. Let's Encrypt issues certificates for a substantial portion of the web, and its domain control validation process relies on DNS lookups. A memory-safe resolver in this role would reduce risk for the certificate issuance process.

Growing Ecosystem

The authoritative name server and stub resolver implementations already have deployment experience in various applications. Version 0.25 alpha prereleases are available for testing, allowing organizations to evaluate the software before stable releases.

Concurrent Cache Access

The record cache used by the stub resolver, forwarding resolver, and recursive resolver was replaced with a cache that allows concurrent access. According to the announcement, this removed a coarse-grained lock from the main code path, improving scalability for high-traffic deployments.

Production Maturity

While the client and stub resolver have production deployment experience, the recursive resolver is still being prepared for production use. Organizations considering Hickory DNS for recursive resolution should monitor the project's progress and testing results.

Ecosystem Compatibility

DNS implementations must handle a wide variety of edge cases and misconfigured zones encountered in the wild. The conformance testing improvements address many scenarios, but production deployments may encounter additional compatibility issues.

Resource Requirements

Rust applications can have different resource characteristics compared to C implementations. Organizations evaluating Hickory DNS should benchmark performance and resource consumption in their specific environments.

Dependency on Continued Development

The project relies on continued funding and contributor involvement. While support from the Sovereign Tech Agency and craig newmark philanthropies provides stability, long-term sustainability depends on ongoing investment in memory-safe infrastructure.

Figure 3: Privilege escalation from user to SYSTEM level

DNS Protocol Roles

Hickory DNS implements the full spectrum of DNS protocol roles. A stub resolver performs basic DNS lookups on behalf of applications. A forwarding resolver accepts queries and forwards them to upstream resolvers. A recursive resolver performs the full resolution process, querying authoritative name servers directly. An authoritative name server hosts DNS zones and responds to queries for those zones.

DNSSEC Validation

DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses have not been tampered with. The recursive resolver validates these signatures when processing queries. NSEC and NSEC3 records provide authenticated denial of existence, proving that a queried name or record type does not exist in a zone.

Memory Safety in Rust

Rust's ownership system and borrow checker prevent common memory safety bugs at compile time. The language guarantees memory safety without requiring garbage collection, making it suitable for systems programming where performance is critical. For DNS servers handling high query volumes, this combination of safety and performance is relevant.

Technical Context (Optional)

The KeyTrap vulnerability identified in the security audit relates to DNSSEC verification resource consumption. Attackers can craft DNS responses that cause excessive computational work during signature verification. The fix limits the resources consumed during DNSSEC validation to prevent denial of service.

Memory-Safe Infrastructure Movement

Hickory DNS is part of a broader effort to rewrite critical Internet infrastructure in memory-safe languages. Prossimo also supports memory-safe implementations of TLS (Rustls), NTP (ntpd-rs), sudo and su, and other components. The approach reflects growing recognition that memory safety vulnerabilities in foundational software pose systemic risks.

Certificate Authority Operations

Certificate authorities depend on DNS for domain control validation. A vulnerability in the DNS resolver used during validation could potentially be exploited to obtain fraudulent certificates. Memory-safe implementations reduce this risk for the certificate ecosystem.

DNS Security Landscape

Traditional DNS implementations including BIND, Unbound, and PowerDNS have addressed numerous memory safety vulnerabilities over the years. A production-ready Rust alternative provides operators with an additional option for their DNS infrastructure.

The specific timeline for production deployment at Let's Encrypt has not been announced. The project is tracking progress through a GitHub issue, but no target date has been published.

Performance benchmarks comparing Hickory DNS to established implementations have not been widely published. Organizations evaluating the software will need to conduct their own testing.

The scope of the OSTIF security audit and whether additional audits are planned has not been detailed in public announcements.

The GitHub tracking issue for Let's Encrypt deployment provides visibility into remaining work items. Progress on this issue indicates movement toward production readiness.

Version 0.25 stable release will incorporate the improvements described in the announcement. Organizations interested in Hickory DNS should monitor release announcements.

Adoption metrics for the client and stub resolver implementations would indicate growing ecosystem confidence. Production deployment reports from early adopters would provide real-world validation.

Additional security audits or conformance testing results would strengthen the case for production deployment. The project's approach to ongoing security review will be relevant for organizations with strict security requirements.

1. Prossimo Blog - "Hickory DNS is Moving Toward Production Readiness" (February 11, 2025): https://www.memorysafety.org/blog/hickory-update-2025/

2. Ferrous Systems Blog - "Hickory DNS Client" (2025): https://ferrous-systems.com/blog/hickory-dns-client/

3. Hickory DNS GitHub Repository: https://github.com/hickory-dns/hickory-dns