Hickory DNS: A Rust DNS Client, Server and Resolver

What Hickory DNS solves, and who it is for

DNS work in Rust usually starts with a choice between binding to a C resolver and writing the protocol by hand. Hickory DNS exists to remove that choice. The repository describes itself as "A Rust based DNS client, server, and resolver, built to be safe and secure from the ground up," and the goals list is unusually specific: no panics, all code guarded, only safe Rust, only stable Rust. Those goals explain the shape of the project. This is not a thin wrapper around an existing daemon. It is a reimplementation of the protocol stack in Rust, intended for people who want DNS behaviour they can read and modify.

The audience is narrower than the tagline suggests. If you are writing a Rust service that needs to resolve names with custom caching or custom transport, the resolver crate is aimed at you. If you run authoritative zones and want a server whose configuration and update path you control in code, the server crate and the hickory-dns binary are aimed at you. If you want a drop-in replacement for a system resolver without writing Rust, the project is a poor fit, because the primary interface is a set of libraries.

The naming history matters when you search for help. The README carries a notice that the project was rebranded from Trust-DNS to Hickory DNS and moved to the hickory-dns organization and repo. Older tutorials, issue threads and crate references still use the Trust-DNS names, and the topics list still includes trust-dns. Expect to translate names when reading anything written before the move.

The six-crate split and how a query moves through it

The workspace is the architecture. Six crates divide the protocol by layer, and the Cargo.toml members list confirms the layout: crates/net, crates/proto, crates/resolver, crates/server, bin, util, plus integration tests and a conformance test server.

At the bottom, hickory-proto handles message encoding and decoding and the DNS transports. Nothing above it can bypass it. Above that, hickory-client sends query, update and notify messages directly to a server; the README is explicit that this is the direct path, not a resolving path. hickory-resolver sits on top of the client and performs resolution, and the README positions it as usable "in place of the standard OS resolution facilities." hickory-server is the library for building servers, and the hickory-dns binary is a consumer of it rather than a separate implementation. hickory-recursor is separate again: it performs recursive resolution by looking records up from their authoritative name servers, which is a different job from the stub-style resolution the resolver crate does.

That split has a practical consequence. Choosing Hickory DNS is not one decision but several. A service that only needs to resolve names pulls in the resolver and whatever it transitively needs. A service that needs to speak the wire protocol for a specific query type pulls in the client or proto crate and nothing more. The cost is that the crates version together. The workspace pins hickory-net, hickory-resolver, hickory-server and hickory-proto to the same exact version string with =, so mixing a resolver from one release with a proto from another is not a supported arrangement.

Installing the hickory-dns server and running a first query

The binary crate is published as hickory-dns on crates.io, which the README's crate table states provides the hickory-dns binary for running a DNS server. The repository does not document a packaged install for any operating system, so building from source is the path the README supports.

Start by confirming your toolchain. The workspace declares rust-version = 1.88 in the [workspace.package] section, so anything older will fail before it compiles.

cargo install hickory-dns

If you would rather build the checkout directly, the workspace members include bin, and the justfile defines a default recipe that checks, builds and tests all crates with default features.

cargo build --package hickory-dns

Cryptography is opt-in and provider-specific. The README explains that features requiring cryptography are suffixed by the provider, so DNS-over-TLS is offered as tls-aws-lc-rs or tls-ring. To build with DNSSEC, the README says to enable the dnssec-ring feature.

cargo build --package hickory-dns --features dnssec-ring

On the client side, the resolver crate is the entry point for ordinary lookups. The README describes it as utilizing the client library to perform DNS resolution and as usable in place of the standard OS resolution facilities. That is the claim to test first in your own environment: resolve a name through the Hickory resolver and compare the answer and the cache behaviour against what your system resolver returns. The README does not give a worked resolver example, so treat the crate documentation on docs.rs as the reference for the current API.

DNSSEC support and the offline signing gap

The DNSSEC status section is the most concrete part of the README, and also the most limiting. The current root key is bundled into the system and used by default, which the README says gives validation of DNSKEY and DS records back to the root. NSEC and NSEC3 are implemented, so authenticated denial of existence is covered. Zones are automatically resigned on any record update via dynamic DNS.

Then the sentence that should decide several adoption conversations: "Offline signing of records/zones is not presently supported." If your key management model requires signing a zone file on a machine that never touches the network, and then shipping the signed zone to a server, Hickory DNS does not do that today. The resign-on-update model assumes the server holds the keys and is reachable when records change. That is a reasonable model for dynamic environments and a bad one for high-value zones where the signing key is deliberately kept away from the serving host.

The cryptography provider choice compounds the operational work. aws-lc-rs and ring are both supported, and the feature names differ per protocol, so a build matrix that enables tls-aws-lc-rs for one component and tls-ring for another is a configuration mistake waiting to happen. The justfile reflects this by defining separate recipes for tls-aws-lc-rs and https-aws-lc-rs, each with its own set of ignored packages. There is no single all-crypto feature that hides the choice.

Where the resolver is the wrong tool

The resolver crate is designed to replace OS resolution. That is a strong claim with a narrow safe zone. If your application depends on the operating system's own resolver configuration, including whatever nsswitch, systemd-resolved or container DNS setup is in play, substituting an in-process resolver changes behaviour in ways that are hard to debug from the application side. Split-horizon names, search domains and per-interface DNS settings live in the OS resolver, not in your process.

Caching is the second boundary. The README lists RFC 2308, negative caching of DNS queries, against the resolver, which means the resolver owns the negative cache. When a name does not exist, the negative answer is cached according to the SOA minimum in the response. If you are debugging a stale NXDOMAIN and your application uses the Hickory resolver, the OS cache tools will not show you anything, because the cache is inside your process. The README does not document a cache inspection or flush interface, so plan for that during diagnosis rather than after.

Recursive resolution is the third. The recursor crate is a distinct component from the resolver, and the README describes it as looking up records from their authoritative name servers. Running a recursor is running an open resolver unless you restrict who can query it, and the README's goals mention protecting against DDOS attacks "to a degree" without specifying the mechanism. Treat that goal as a statement of intent, not a documented mitigation.

How Hickory DNS compares with a C resolver binding

The realistic alternative for a Rust service is binding to an existing C resolver library or shelling out to a system resolver, and the difference is architectural rather than a matter of features. A C binding gives you the resolver that the host already trusts, with the host's configuration, cache and platform behaviour. Hickory DNS gives you a resolver implemented in Rust, compiled into your binary, with its own cache and its own configuration surface.

The trade-off runs in both directions. With a binding, you inherit decades of platform integration and you inherit the C dependency, the build toolchain requirements and the memory-safety properties of that code. With Hickory DNS, the dependency graph is Rust and the workspace's stated goal is that all code is guarded and only safe Rust is used, but you take on the configuration and the cache semantics yourself.

The same comparison holds on the server side. An established C server brings a configuration language, a zone file format and operational tooling that administrators already know. Hickory DNS brings a Rust library that the hickory-dns binary uses, which means the configuration surface is whatever that binary exposes, and the README does not document it in the excerpt available. If your team's operational knowledge is in the C server's configuration format, moving to Hickory DNS moves that knowledge's value to zero. If your team is already writing Rust and wants the server behaviour in the same language as the rest of the system, the calculus reverses.

Maintenance, versioning and licence

The repository is not archived, and the last push was on 2026-09-22. The release cadence in the recent releases list is uneven: v0.26.1 on 2026-05-01, then v0.26.2 on 2026-09-03 and v0.26.3 on 2026-09-10. That is a four-month gap followed by two releases in a week, which is a normal pattern for a project that batches changes rather than one that ships continuously.

The version skew is the thing to watch. The workspace Cargo.toml declares version = 0.27.0-alpha.1, while the newest published release in the repository's release list is v0.26.3. Anyone tracking main is on an alpha line. The workspace also pins internal dependencies with exact versions, so a partial upgrade across the hickory-* crates is not something the manifest supports.

Licensing is dual, and the README shows both badges: MIT and Apache 2.0. The repository carries LICENSE-MIT and LICENSE-APACHE, and the workspace package metadata declares license = "MIT OR Apache-2.0". The GitHub API reports the licence as NOASSERTION, which is a classification artefact rather than a contradiction; the files and the manifest agree with each other. What that dual grant means for your product is a question for your own legal review, not something this article can settle. The practical point is that the terms are permissive and the choice between them is yours, which is the same arrangement many Rust projects use.

Upgrade cost is dominated by the feature-flag matrix rather than by API churn. Every cryptographic capability is selected through a provider-suffixed feature, so an upgrade that adds a new protocol also adds a new pair of flags to your build configuration. Budget for that each time.

Editorial conclusion

Adopt Hickory DNS if you are writing Rust and want DNS as a library rather than a subprocess, or if you want a configurable authoritative server you can build from source. Do not adopt it if you need offline zone signing, since the README states that is not presently supported, or if you expect a stable API surface, because the workspace is on 0.27.0-alpha.1 while the newest published release is v0.26.3. Before committing, verify which crypto provider your build resolves to, since the tls-aws-lc-rs and tls-ring features are not interchangeable, and confirm that the resolver's caching behaviour matches the RFC 2308 negative caching you are relying on.

Frequently asked questions

Official sources

1. hickory-dns/hickory-dns on GitHub
2. Issues
3. README
4. Releases