Stub resolver
The small DNS client built into an operating system or application.
The Internet’s naming system
DNS, from the first query to a validated answer.
DNS is not merely a phone book. It is a distributed database, a delegation system, a cache hierarchy, a security boundary and—more often than people realise—part of an application’s control plane.
- 11focused pages
- 0tracking scripts
- 100%static and portable
A system of distinct roles
One protocol, several very different jobs
A client’s stub resolver asks a recursive resolver for a final answer. The recursive resolver consults the hierarchy, caches what it learns and may validate DNSSEC. Authoritative servers publish the data for zones; they do not normally browse the hierarchy on a client’s behalf.
Recursive resolver
Finds the answer, caches it and optionally applies validation or policy.
Authoritative server
Publishes signed or unsigned zone data and referrals.
Explore the guide
Build a complete mental model
Each page focuses on one layer, while cross-links show where the layers meet.
Resolution & caching
Follow an iterative lookup through the root, TLD and authoritative layers; understand TTLs, referrals and negative caching.
Trace a lookup →DNSSEC
Learn how DS, DNSKEY, RRSIG and NSEC records build a chain of trust—and what DNSSEC does not encrypt.
Validate the chain →Privacy & encryption
Compare classic DNS, DoT, DoH and DoQ, then place QNAME minimisation and encrypted transports in the correct threat model.
Compare transports →Resource records
Read zone-file syntax and understand the operational meaning of A, AAAA, CNAME, MX, NS, SOA, TXT, CAA, TLSA and SVCB/HTTPS.
Browse record types →Modern architecture
Separate recursive, authoritative, filtering, encrypted-transport and signing responsibilities into clear trust boundaries.
Design the stack →Operations
Use concrete checks, safe deployment sequences, secondary servers, TSIG, zone transfers and monitoring to keep DNS dependable.
Operate it well →NSD hardening
Build a practical authoritative NSD service, then confine it with AppArmor, systemd sandboxing, narrow capabilities and controlled writable paths.
Harden an authority →Three separate questions
Authenticity, confidentiality and availability are not interchangeable
Is the answer genuine?
DNSSEC lets a validating resolver detect forged or modified signed data.
Can observers read the query?
DoT, DoH and DoQ encrypt a particular client-to-resolver hop.
Will the answer remain reachable?
Redundant authority, sane TTLs, monitoring and disciplined changes support availability.