DNS

DNS

A practical field guide to DNS, including an operational example, common misconceptions, troubleshooting checks, and primary references.

Field guide reviewed July 2026

Definition

The Domain Name System, a distributed hierarchical database and protocol used to map names to resource records. It supports far more than address lookup, including service discovery, email routing, delegation, policy, and security data.

In practice

Trace one DNS lookup from client to authority

A lookup for app.example.com crosses distinct roles. Separating those roles turns a vague DNS complaint into a testable transaction.

  1. The client’s stub resolver sends a question for a specific name and record type to its configured recursive resolver.

  2. The recursive resolver returns a valid cached answer or follows referrals through the DNS hierarchy.

  3. An authoritative server for the target zone returns the published record set or an authenticated negative answer.

  4. The resolver caches the result according to its TTL and returns a response code, flags, and answer data to the client.

Common misconceptions

What this does not mean

Every DNS server performs the same job.
Recursive resolvers find answers for clients; authoritative servers publish data for zones. Some software can perform both roles, but the responsibilities remain different.
Lowering a TTL immediately clears old answers.
Caches may reuse a record until its existing TTL expires. Lower the TTL before a planned change if faster convergence is required.
No address in the answer always means the name does not exist.
NXDOMAIN means the queried name does not exist. A successful response with no requested record type is a different condition and should be investigated differently.
Field checks

A practical review order

  • Write down the exact fully qualified name, record type, client, time, and expected answer.
  • Query the same recursive resolver the client uses and record the response code, flags, answer, and TTL.
  • Compare the recursive answer with the target zone’s authoritative servers.
  • Inspect delegation, glue, DNSSEC validation, search suffixes, split-horizon views, and negative caching.
  • Change authoritative data only after identifying whether the failure is at the client, resolver, delegation, or zone.