Hickory Proto

Safe, low-level DNS protocol library underpinning Hickory DNS in Rust

Library
Cargo
v0.26.1
5,371stars
MIT OR Apache-2.0

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
92/100Excellent
Development Activity100
Maintenance96
Community72
Maturity60
Momentum40

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
81/100Excellent
Architecture88
Code Quality90
Innovation80
Learning Curve66

hickory-proto is the foundational protocol crate of the Hickory DNS project (formerly Trust-DNS) — it implements DNS message encoding/decoding, resource-record types, DNSSEC validation primitives, and the transport-layer plumbing that every higher-level Hickory crate (hickory-client, hickory-resolver, hickory-server, hickory-recursor) builds on. It’s designed around Rust’s safety guarantees specifically: the project’s stated goals are zero panics, only safe Rust, and defense against malformed/malicious DNS traffic, which matters for a protocol library parsing untrusted wire-format bytes.

The crate implements a substantial slice of the DNS RFC surface — base message format (RFC 1035), EDNS (RFC 6891), DNSSEC signing/validation with NSEC/NSEC3, mDNS, and DNS-over-TLS/HTTPS/QUIC transports — with pluggable cryptography providers (aws-lc-rs or ring, selected via feature flags) for the DNSSEC and encrypted-transport code paths. Because it’s a no_std-capable, feature-gated crate at the bottom of the workspace’s dependency graph, it’s usable standalone by anyone needing raw DNS message parsing without pulling in a full resolver or server stack.

What You Get

  • DNS message encoding/decoding for the full RFC 1035 base spec plus EDNS (RFC 6891), IPv6 (RFC 3596), and service-location (RFC 2782) record types
  • DNSSEC signing and validation, including NSEC/NSEC3 support, with a choice of cryptography backend (aws-lc-rs or ring) selected via Cargo feature flags
  • Transport implementations for DNS-over-TLS, DNS-over-HTTPS, and DNS-over-QUIC alongside plain UDP/TCP, gated behind feature flags to keep the dependency footprint minimal for consumers who don’t need them
  • A no_std-capable core (opt-in std feature) so the protocol layer can be used in constrained environments, not just full server/client applications
  • Resource-record and zone types shared by every downstream Hickory crate, avoiding duplicated DNS-parsing logic across the client, resolver, server, and recursor

Common Use Cases

  • Building custom DNS tooling (scanners, analyzers, custom resolvers) that needs raw message parsing without a full resolver stack
  • Implementing DNSSEC validation logic in a Rust application handling security-sensitive DNS lookups
  • Adding DNS-over-TLS/HTTPS/QUIC transport support to a Rust network application for encrypted DNS resolution
  • Serving as the shared protocol foundation for higher-level Hickory crates (hickory-resolver for OS-level resolution, hickory-server for building DNS servers)

Under The Hood

Architecture — The crate is organized by protocol concern: src/op handles the DNS message/opcode structure, src/rr implements resource-record types and zone data, src/serialize provides the binary encode/decode layer for wire format, and src/dnssec layers signing/validation on top, all designed so that every higher-level crate in the hickory-dns workspace (crates/resolver, crates/server, crates/net) depends on this one for shared protocol logic rather than reimplementing DNS parsing. Tech Stack — Rust (edition 2021, MSRV 1.88), no_std-capable with an opt-in std feature, pluggable cryptography via aws-lc-rs or ring (feature-flag selected per capability, e.g. tls-aws-lc-rs vs tls-ring), and thiserror/tracing for error handling and instrumentation with no_std compatibility maintained through their own feature flags. Code Quality — 62 files across the proto crate contain #[test]-annotated tests, and the workspace runs codecov-tracked CI on every push; the project’s explicit goals (no panics, safe Rust only, stable Rust only) reflect an unusually strict internal quality bar for a protocol-parsing library that handles untrusted network input, and DNSSEC/NSEC3 and multiple RFCs are implemented and RFC-numbered directly in the README for traceability. API Design — Feature-gated compilation lets consumers pull in only the transports and crypto providers they need (plain resolution vs. DNS-over-TLS vs. DNSSEC validation), keeping binary size and dependency trees minimal for narrow use cases, while the shared op/rr types give a consistent low-level vocabulary that the higher-level hickory-resolver and hickory-server crates build directly on top of.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search