domain

domain is an open-source DNS library for Rust from NLnet Labs, providing an ever-growing set of building blocks for adding Domain Name System functionality to applications. It covers everything from low-level parsing and construction of DNS messages to higher-level facilities like a Tokio-based stub resolver, client and server transports, zone file handling, zone trees, TSIG-secured transactions, and DNSSEC signing and validation.

The crate is organized around Cargo feature flags so you compile only the modules you need, keeping builds lean for constrained targets while still offering a rich async stack for full resolver and nameserver work. It is used as the foundation for NLnet Labs tooling such as the dnsi inspector, the dnst ldns-style utilities, and the Cascade DNSSEC signing pipeline.

What You Get

• Core base and rdata modules with types and traits for building and parsing DNS names, records, and messages
• A Tokio-based asynchronous stub resolver (plus a synchronous wrapper) for looking up records
• Client and server transport implementations for sending and receiving DNS over UDP, TCP, and TLS
• Zone file reading/writing and an in-memory zone tree for answering queries and performing zone transfers
• DNSSEC signing and validation together with TSIG support for authenticated transactions

Common Use Cases

• Resolving DNS records asynchronously from within a Rust application
• Building custom DNS servers, proxies, or load balancers on top of the transport layer
• Parsing, constructing, and inspecting raw DNS messages and record data
• Loading zone files into memory and serving or transferring them with DNSSEC signing

Under The Hood

Architecture — The crate is layered from a always-compiled core outward through feature-gated modules. src/base holds the foundational message machinery (message.rs, message_builder.rs, header.rs, name/, iana/) for parsing and constructing wire-format DNS, while src/rdata implements the individual record types; both build on the external octseq octet-sequence abstraction so the same code works across no_std+alloc, heapless, and std/bytes storage. On top of that, src/net supplies async client/server transports, src/resolv layers a Tokio stub resolver over them, src/zonefile and src/zonetree add parsing and in-memory storage of zones, and src/dnssec, src/crypto, and src/tsig handle signing, validation, and authenticated transactions — each activated only when its Cargo feature is enabled (src/lib.rs gates the module docs and exports with cfg_attr).

Tech Stack — Written in Rust (edition 2024, MSRV 1.87), the library keeps its mandatory dependency surface tiny — domain-macros (an in-repo proc-macro workspace member), octseq, and jiff — and pushes everything else behind optional features: tokio and futures-util for async transports, bytes/smallvec/heapless for storage, ring or openssl as swappable crypto backends, moka for client caching, and serde for serialization. The workspace uses resolver 3 and includes a macros crate for deriving record and wire-format traits.

Code Quality — Testing is substantial: roughly 470 #[test]/#[tokio::test] functions across ~96 files, plus an integration suite under tests/ (net-client.rs, net-client-cache.rs, interop.rs) and a Stelline-based scenario harness (src/stelline) for replaying DNS test vectors from test-data/. The code leans on Rust’s type system for wire-format safety, keeps modules cohesive, and documents extensively via crate-level and module-level doc comments. The API is explicitly marked as evolving, with large-scale redesigns collected behind the unstable-new feature flag.

API Design — The public surface mirrors the module layout, so the feature you enable is the module you import (net, resolv, zonefile, etc.), which keeps discovery predictable. A rich examples/ directory (client transports, sync/async resolver, zone reading and serving, IXFR, keyset management) lowers the on-ramp, and re-exports of key dependencies through the dep module help avoid version-mismatch pain. The main friction is breadth: the many feature flags and the parallel unstable-* and new surfaces mean newcomers must map their goal onto the right features before the ergonomic APIs become available.