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 | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
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
- https://www.rfc-editor.org/rfc/rfc9499.html
Supports
- Current DNS terminology for names, labels, resolvers, authoritative servers, zones, delegation, referrals, and resource records
- Distinctions between recursive and authoritative service
- Current meanings of negative responses and DNSSEC terms
- https://www.rfc-editor.org/rfc/rfc1034.html
Supports
- Hierarchical namespace, zones, delegation, authoritative servers, and resolver architecture
- Iterative referrals through the hierarchy and recursive service for clients
- Positive caching and time-to-live behavior
- NS, CNAME, SOA, and MX concepts
- RFC 1034 publication in November 1987 and its replacement of the original DNS concepts document
- https://www.rfc-editor.org/rfc/rfc1035.html
Supports
- DNS query and response message structure, flags, sections, classes, and response codes
- Domain-name presentation and wire formats
- Core resource record fields and A, CNAME, MX, NS, PTR, SOA, and TXT formats
- UDP and TCP transport behavior, truncation, and resolver processing
- RFC 1035 publication in November 1987 and its replacement of the original DNS implementation document
- https://www.rfc-editor.org/rfc/rfc3596.html
Supports
- AAAA records for IPv6 addresses
- IPv6 reverse mapping under the ip6.arpa namespace
- RFC 3596 publication in October 2003
- https://www.rfc-editor.org/rfc/rfc2308.html
Supports
- Negative caching for name errors and missing record data
- NXDOMAIN and no-data distinctions
- SOA data and time-to-live handling for cacheable negative answers
- RFC 2308 publication in March 1998
- https://www.rfc-editor.org/rfc/rfc7766.html
Supports
- Required TCP support for full DNS protocol implementations
- Relationship between UDP, TCP, truncation, response size, and zone transfer
- Operational consequences when TCP DNS is blocked
- RFC 7766 publication in March 2016
- https://www.rfc-editor.org/rfc/rfc4033.html
Supports
- DNSSEC data origin authentication and integrity protection
- DNSSEC chain-of-trust and authenticated-denial concepts
- DNSSEC limits, including lack of confidentiality and protection from denial of service
- RFC 4033 publication in March 2005
- https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
Supports
- Current registries for record types, classes, response codes, flags, and DNS protocol parameters
- https://www.iana.org/domains/root
Supports
- Root zone as the highest level of the DNS hierarchy
- IANA coordination of top-level-domain delegations in the root zone
- https://www.rfc-editor.org/rfc/rfc882.html
Supports
- Original DNS concepts, including the distributed namespace, referrals, caching, and timeouts
- RFC 882 publication in November 1983
- https://www.rfc-editor.org/rfc/rfc1996.html
Supports
- DNS NOTIFY for prompt notification of zone changes
- RFC 1996 publication in August 1996
- https://www.rfc-editor.org/rfc/rfc2671.html
Supports
- EDNS(0), the OPT pseudo-record, capability negotiation, and larger UDP messages
- RFC 2671 publication in August 1999
- https://www.rfc-editor.org/rfc/rfc8198.html
Supports
- Aggressive use of DNSSEC-validated NSEC and NSEC3 cache data
- RFC 8198 publication in July 2017
- https://kb.isc.org/docs/aa-00208
Supports
- dig +trace behavior and its root-to-authority resolution path
- https://kb.isc.org/docs/behavior-dig-versions-edns-bufsize
Supports
- dig availability with ISC BIND and EDNS buffer behavior
- https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html
Supports
- Route 53 DNS hosting, hosted zones, records, and DNSSEC configuration
- https://developers.cloudflare.com/dns/get-started/
Supports
- Cloudflare primary authoritative DNS setup, assigned name servers, and DNS record management
- https://docs.cloud.google.com/dns/docs/overview
Supports
- Google Cloud DNS public and private managed zones, authoritative serving, and TTL-based resolver propagation
- https://learn.microsoft.com/en-us/azure/dns/dns-overview
Supports
- Azure public DNS, private DNS zones, and resolver services
- https://www.ibm.com/docs/en/ns1-connect?topic=introduction-overview
Supports
- NS1 Connect managed authoritative DNS, zone publication, and traffic steering
- https://techdocs.akamai.com/edge-dns/docs/welcome-edge-dns
Supports
- Akamai Edge DNS authoritative service, primary and secondary zones, DNSSEC, and API management
- https://www.powerdns.com/authoritative-server.html
Supports
- PowerDNS Authoritative Server as self-managed authoritative DNS software
