The Distributed Namespace
DNS is the internet's directory: it maps the names humans type to the addresses machines route to. What makes it work at planetary scale is that no single server holds the data. The namespace is a tree, ownership of each branch is delegated downward, and answers are cached everywhere — so a lookup for www.example.com touches a handful of servers, none of which knows the whole picture.
The structure is the point. The root delegates the .com branch to the registry that runs it; that registry delegates example.com to whoever the owner chose to host it; that host answers for everything under example.com. Each level only has to know who is responsible for the level below — a chain of pointers, not a copy of the data. That is how one namespace holds billions of names with no central bottleneck.
The Name Hierarchy and the Trailing Dot
Read a domain name right to left, because that is the order DNS resolves it. The invisible root sits at the top, written as a single trailing dot. Below it are the top-level domains — .com, .org, .uk — then second-level names like example.com, then any subdomains beneath. A fully qualified domain name (FQDN) includes that final dot: www.example.com. is absolute, while www.example.com without the dot may have a search domain appended by the resolver.
The trailing dot is not cosmetic. In a zone file, a name without it is treated as relative to the current zone and silently gets the zone name appended — so www.example.com written without the dot becomes www.example.com.example.com., which is almost never what you meant. The hierarchy is also why the same label can mean different things in different places: mail.google.com and mail.example.com share a label and nothing else.
Zones and Delegation
A zone is the unit of administrative control: a contiguous slice of the tree that one operator answers for. The .com zone is run by its registry; the example.com zone is run by whoever the owner delegated it to. The boundary between a parent and child zone is marked by NS records — the parent publishes the names of the child's authoritative servers and stops there, handing off responsibility.
Delegation is what lets the tree scale. The .com servers do not store the address of www.example.com; they store an NS record saying "ask these servers for anything under example.com." That referral is the entire mechanism. A subdomain like eng.example.com can be delegated again to a different team's servers, or kept in the parent zone — the choice is whether you want a new administrative boundary.
# the parent (.com) only delegates — it returns NS, not the address dig +norecurse @a.gtld-servers.net example.com NS # ;; AUTHORITY SECTION: # example.com. 172800 IN NS a.iana-servers.net. # example.com. 172800 IN NS b.iana-servers.net. # the address itself lives only on those authoritative servers
Authoritative versus Recursive Servers
Two completely different jobs share the name "DNS server." An authoritative server owns a zone's data and answers questions about it from its own records — it is the source of truth for example.com. A recursive resolver owns no data; it is a lookup agent that walks the hierarchy on a client's behalf, caches what it learns, and hands back the final answer. Your laptop talks only to a recursive resolver, never to the root or a TLD directly.
The split matters operationally. Point a host at 8.8.8.8 or 1.1.1.1 and you get a recursive resolver that will do the whole walk for you. Point it at an authoritative server expecting it to resolve arbitrary names and you get a referral or a refusal, because that server only answers for its own zones. Mixing the two roles up is the single most common DNS misconception.
The Registry, Registrar, and Registrant Chain
A name comes to exist through three parties that are easy to conflate. The registry operates a TLD's authoritative servers and master database — Verisign runs .com. The registrar is the company you buy a name through and that submits your registration to the registry. The registrant is you, the owner. Buying a name registers it; it does not, by itself, host its DNS.
The gap people fall into: the registrar where you bought the name and the DNS host that actually serves your records can be — and often are — different companies. Your registrar sets the parent's NS records to point at whichever authoritative servers you choose, and from there the DNS host answers every query. Changing DNS providers means updating those NS records at the registrar, not moving the registration.
Authoritative server owns the zone and answers from its own records — it is where the data lives. It does not resolve names outside its zones; ask it for an unrelated name and you get a referral, not an answer. Run one when you host a domain's records.
Recursive resolver owns no data; it walks the hierarchy for a client, caches the result, and returns the final IP. This is what your laptop, your home router, and public services like 8.8.8.8 provide. Point clients here, never at the root or a TLD server directly.
- Confusing the registrar with the DNS host. The registrar holds your registration and sets the parent NS records; a separate DNS host may serve the actual zone — so updating records at the registrar's panel does nothing if your NS points elsewhere.
- Dropping the FQDN trailing dot in a zone file. A name written without the final dot is relative and gets the zone appended, turning www.example.com into www.example.com.example.com. and breaking the record silently.
- Assuming one server holds the whole namespace. No server does; the root only delegates to TLDs, TLDs delegate to authoritative servers, and querying the root for a full name returns a referral, not the address.
- Pointing applications at an authoritative server expecting recursion. An authoritative server answers only for its own zones; ask it to resolve an arbitrary name and it refuses or refers, and your lookups fail.
- Forgetting to update the parent's NS records when delegating a subdomain. If the parent zone still answers for eng.example.com directly, the new authoritative servers you set up are never consulted.
- Write every name in a zone file as a fully qualified name with the trailing dot, so the resolver never silently appends the zone and produces a doubled name.
- Point clients and applications at a recursive resolver (a public one like 1.1.1.1 or your own), never at a root or TLD server, because only a recursive resolver does the full walk.
- Confirm a delegation with
dig +norecurse @parent-server child NSbefore going live, so you see the parent actually hand off to your authoritative servers. - Keep at least two NS records on separate networks for any zone you publish, so a single authoritative server outage does not make the whole zone unresolvable.
- Track which company is registrar versus DNS host for each domain, so when you migrate providers you change the NS records at the right place instead of editing a panel that serves nothing.
Knowledge Check
You query a .com TLD server directly for www.example.com. What do you get back?
- A referral: the NS records naming example.com's authoritative servers
- The A record with the IP address of the web server
- A fully recursive answer, produced after the TLD server walks the rest of the tree on your behalf
- An NXDOMAIN, because only the root knows that name
A name written as www.example.com (no trailing dot) appears in an example.com zone file and resolution breaks. Why?
- It is relative, so the zone is appended, yielding www.example.com.example.com.
- The name is case-sensitive, so it must be written in uppercase to match the records in the zone
- Without the dot the record is parsed as a CNAME instead of an A
- The missing dot makes the name absolute and skips the zone entirely
You bought a domain at one company but host its records at another. Where do you change the records?
- At the DNS host that serves the zone, since that is where records live
- At the registrar where you bought the name, since the registrar always serves a domain's DNS
- At the TLD registry, which stores every record under the TLD
- At the root server operator, which owns the full namespace
You got correct