How DNS works

When you type example.com into a browser, your computer cannot do anything with that name directly. Machines locate each other by IP address — strings of numbers like 93.184.216.34 — not by words. Something has to translate the human-friendly name into the machine-friendly number, and that something is the Domain Name System, or DNS. It is one of the internet’s most essential and invisible services, a global directory that answers billions of lookups every second.

Why DNS exists

The reason is simple human memory. People recall names like wikipedia.org effortlessly but would struggle with the numeric addresses behind them, and those addresses can change without warning. DNS adds a layer of indirection: we use stable, memorable names, and DNS resolves them to whatever IP address currently serves them. This decoupling lets a site move servers, switch hosting, or balance across many machines without anyone needing to learn a new number.

The resolution chain

DNS is not one giant database but a distributed hierarchy of servers, and a lookup walks down that hierarchy. The journey begins with a resolver — usually operated by your ISP or a public service like a major DNS provider. Your device asks the resolver a single question (“what is the IP for example.com?”), and the resolver does the legwork.

To find the answer, the resolver typically consults three tiers of servers in turn:

1. Root servers sit at the very top. They do not know individual addresses, but they know who handles each top-level domain and refer the resolver onward — for a .com name, they point to the .com servers.
2. TLD servers manage a suffix such as .com, .org, or .uk. They also do not hold the final answer, but they know which server is authoritative for the specific domain and pass that referral back.
3. The authoritative name server holds the official records for the domain itself. It gives the definitive answer, returning the actual IP address.

Think of it as asking for a house: the root tells you which country, the TLD tells you which city, and the authoritative server gives you the exact street address.

This referral style is called an iterative query — each server replies with a pointer rather than the final answer, and the resolver follows the chain. The conversation between your device and the resolver, by contrast, is recursive: the resolver promises to do all the work and hand back one complete answer.

Record types: more than just addresses

DNS stores several kinds of records, each answering a different question about a domain:

• A record — maps a name to an IPv4 address. This is the workhorse of the web.
• AAAA record — maps a name to an IPv6 address, the newer, larger address format.
• CNAME record — makes one name an alias for another. A query for the alias is redirected to the target name, which is then resolved further. This is handy for pointing many subdomains at one canonical host.
• MX record — names the mail servers that accept email for the domain, so mail is delivered to the right place.
• NS record — names the authoritative name servers responsible for the domain’s DNS, effectively saying “ask these servers for the truth about this domain.”

A single domain usually has several of these at once: an A record so the website loads, MX records so email arrives, and NS records declaring who is in charge.

Caching and TTL: keeping it fast

If every lookup had to climb the full hierarchy, DNS would be painfully slow and the root servers would melt under the load. The fix is caching. Once a resolver learns an answer, it stores it and serves subsequent identical queries instantly from memory.

How long it holds that answer is governed by the TTL, or time-to-live, attached to every record. A TTL is a number of seconds telling caches how long the record may be trusted before they must check again. A long TTL means faster, cheaper lookups but slower propagation of changes; a short TTL means changes spread quickly at the cost of more queries. When administrators plan a server migration, they often lower the TTL beforehand so the change takes effect rapidly once made.

The quiet backbone

DNS works so reliably that most people never think about it — until it fails, at which point the whole internet seems broken even though every server is running fine. Understanding the resolver, the root-TLD-authoritative chain, the record types, and the role of caching demystifies that backbone. It also explains why some changes “take a while to propagate”: somewhere out there, a cache is still holding the old answer until its TTL expires.