openskills.info
Open Course

DNS Fundamentals

The Domain Name System translates human-readable domain names into IP addresses that computers use to route traffic. It operates as a distributed, hierarchical database where resolvers query authoritative servers through a chain of delegations from root to specific zone.

itNetworking

Don't Panic — DNS Fundamentals

The phone-book comparison gets one thing right and hides everything interesting. There is no book.

No server anywhere holds the full list of names and none ever has. The namespace is a tree, administrators cut it into zones — the chunks any one party actually administers — and each zone hands authority over its children to somebody else's servers. A lookup is a walk down that chain of delegations, and nearly everything odd here follows from the work being split among parties who never coordinate.

Two roles, and mixing them up is the classic way to lose an afternoon. A recursive resolver goes and finds answers on a client's behalf, then caches what it learned.

An authoritative server answers out of the zone data it actually holds. One machine can do both jobs, but the jobs stay distinct, so when a response surprises you the first question is which of the two produced it.

On a cold lookup for www.example.com, a root server merely points the resolver toward com, a com server points it toward example.com, and only the last answers from real data.

What comes back is a typed record rather than an address. A and AAAA give addresses, CNAME makes one name an alias for another, MX names the mail servers, NS marks a delegation, SOA carries a zone's administrative values, TXT holds strings the industry uses for everything. A successful A lookup proves nothing about whether AAAA or MX exist at the same name.

Then caching, where the surprises live. Every record carries a TTL, a time-to-live saying how long the answer may be reused, and it is a request rather than an instruction.

Resolvers clamp it to their own floor and ceiling, software libraries cache on their own terms, browsers keep a private cache, and long-lived programs cheerfully resolve a name once at startup and never again. Propagation time is therefore set by the slowest cache in a population nobody can enumerate. Design changes that never need everyone to notice at once: run old and new endpoints together, and cut over once traffic on the old one reaches zero.

The sharpest edge is that absence caches too. NXDOMAIN says the name does not exist, and how long that answer lingers comes from a field in the zone's SOA record, not from any TTL on the record just created.

That is the whole mechanism behind "I added it and it still does not resolve", and why automated setup that checks a name before creating it can poison its own rollout. Read that field before the change.

One habit worth adopting: list every name in the zone and resolve each target on a schedule. Zones only grow, nobody's change process includes deleting records, and a CNAME left pointing at a decommissioned service resolves quite happily to a name somebody else can now register.

Keep the Cheatsheet open for record types and response codes. Delegation and DNSSEC get proper treatment in the Intro. Field Notes has the apex CNAME problem, plus where those queries have quietly gone.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources