What Is DNS? How Domain Name Resolution Actually Works

Type a domain name into a browser, hit enter, and a page appears — a process so fast and reliable that almost nobody thinks about what had to happen first for the browser to even know which server, out of billions of possible computers on the internet, to actually ask. That lookup is DNS, and it's one of those pieces of infrastructure that's genuinely worth understanding at least once, because a surprising number of confusing real-world problems ("the site works for me but not my colleague," "I changed my DNS records and nothing happened") trace directly back to how it actually works.

What is DNS?

The Domain Name System (DNS) is a globally distributed, hierarchical database that translates human-readable domain names (like `example.com`) into the numeric IP addresses computers actually use to route network traffic to each other. It's often described as "the phonebook of the internet," and while that's a reasonable first mental model, DNS is more precisely a distributed *lookup and delegation system* — no single server holds the entire phonebook; instead, the answer to any given lookup is assembled by following a chain of referrals across many independently operated servers.

Why we need it at all

Computers route traffic using IP addresses — a string like `93.184.216.34` (IPv4) or a longer hexadecimal IPv6 address — which are not remotely practical for humans to memorize or type reliably. DNS solves the obvious problem (names are memorable, numbers aren't) but also solves a second, less obvious one: it lets the underlying IP address behind a domain change at any time — a server migration, a new hosting provider, a failover to a backup — without anyone needing to know or care, because the domain name stays exactly the same even as what it points to changes.

The hierarchy: root, TLD, and authoritative servers

Reading a domain name from right to left actually reflects how DNS is organized. Take `www.example.com`:

• Root — the implicit starting point of every lookup, served by a small number of root server clusters operated around the world, whose only job is to point toward the right TLD server.
• .com — the Top-Level Domain (TLD) — TLD servers (one set for `.com`, another for `.in`, another for `.org`, and so on) know which authoritative servers are responsible for each specific domain registered under that TLD.
• example — the domain itself — this is where the actual, authoritative records for the domain live, on nameservers the domain's owner has designated (through their registrar or DNS host).
• www — a subdomain/host — the specific record within `example.com`'s own zone that the authoritative server ultimately answers with.

Recursive resolver vs authoritative server: a distinction worth being precise about

Two terms come up constantly in any DNS explanation, and it's worth being exact about the difference, since the two roles are easy to conflate. A recursive resolver (your ISP's default, or a public one like Cloudflare's or Google's) does the actual legwork of a lookup on your behalf — following referrals from root to TLD to authoritative server, then caching and returning the final answer to you. It doesn't itself hold the authoritative answer for any domain (aside from what it's temporarily cached). An authoritative nameserver, by contrast, is the actual source of truth for one specific zone — it's the server the domain owner (or their DNS host) has configured with the real records, and it's the only place in the entire chain where a query for that zone gets a *definitive* answer rather than a referral or a cached copy.

Step by step: what actually happens when you type a URL

• Browser cache check — the browser first checks whether it already has a recent, unexpired answer for this exact domain cached from a previous visit.
• OS-level resolver cache — if not, the operating system checks its own local DNS cache next.
• Query to a recursive resolver — if still unanswered, a query goes out to a recursive resolver, typically your ISP's default one or a public one like Google's `8.8.8.8` or Cloudflare's `1.1.1.1` if you've configured one.
• Recursive resolver queries the root — if the resolver itself has no cached answer, it asks a root server, which doesn't know the final answer but replies with a referral: "ask a `.com` TLD server."
• TLD server referral — the TLD server likewise doesn't know the final IP, but replies with a further referral: "ask this domain's authoritative nameserver."
• Authoritative server answers — the authoritative nameserver for `example.com` holds the actual record and returns the real IP address (an A or AAAA record).
• Resolver caches and returns the answer — the recursive resolver caches this answer for future use and hands it back to your browser.
• Browser connects — with the IP address in hand, the browser opens an actual HTTP/HTTPS connection to that server, and the page starts loading.

Common DNS record types explained

• A — maps a name directly to an IPv4 address.
• AAAA — maps a name directly to an IPv6 address.
• CNAME — maps a name to *another name*, which is then resolved further (commonly used to point a subdomain at a service provider's own domain, like a CDN).
• MX — specifies which mail servers handle email for the domain, and in what priority order.
• TXT — holds arbitrary text, widely used today for domain-ownership verification and email authentication standards like SPF and DKIM.
• NS — delegates a domain (or subdomain) to a specific set of authoritative nameservers.
• SOA — holds administrative metadata about the zone itself, including who's authoritative for it and how long other resolvers should cache negative answers.
• CAA — restricts which certificate authorities are allowed to issue an SSL/TLS certificate for the domain, as a security control.

TTL and caching: why DNS changes take time to show up everywhere

Every DNS record carries a TTL (Time To Live) value, telling any resolver that caches it how long that cached copy is allowed to be treated as valid before it must be looked up fresh. This is the real explanation behind "DNS propagation" — a term that makes it sound like a single global synchronization event, when what's actually happening is that dozens of independent caches (your browser, your OS, your ISP's resolver, and every other resolver around the world that happened to look up the same domain) are each holding their own copy of the old answer, and each one only refreshes independently once its own cached copy's TTL expires. A record with a 24-hour TTL that you just changed might show the new value instantly to someone whose resolver never cached it, while someone else keeps seeing the old value for up to a full day, simply because their specific resolver's cache hasn't expired yet.

A worked example: resolving a real-looking domain

Say a browser needs to resolve `shop.example.com` for the very first time, with nothing cached anywhere. The recursive resolver first asks a root server, which has no idea what `shop.example.com` points to but knows exactly which servers handle `.com` overall, and replies with that referral. The resolver then asks one of those `.com` TLD servers, which likewise doesn't know the final answer but does know which nameservers `example.com` itself delegates to (from its NS records), and replies with *that* referral. Finally, the resolver asks `example.com`'s own authoritative nameserver directly, which actually holds a record for the `shop` subdomain — say, a CNAME pointing to a hosting provider's own domain — and that hosting provider's nameserver is queried one further step to get the actual IP address. The resolver caches every layer of this chain for its respective TTL and hands the final IP back to the browser, which then makes an actual HTTPS connection to that address. The next visitor asking for the same domain, from a resolver that already cached any part of this chain, skips straight to whichever step is still cached — which is exactly why a popular domain's *first* lookup from a given resolver is measurably slower than every subsequent one.

How DNS connects to tools and concepts you might already use

DNS shows up constantly in ordinary web work even when it isn't the main topic. Pointing a custom domain at a CDN is typically done with a CNAME record aimed at the CDN provider's own domain, which is exactly why CDN setup instructions almost always include a DNS step. Verifying domain ownership for services like Google Search Console, or setting up email authentication (SPF/DKIM) to stop your outgoing mail from landing in spam, both work by adding specific TXT records to your domain's DNS zone. None of this requires understanding DNS at a protocol level — but knowing that a "DNS record" is just one line in a zone file that any authoritative nameserver can serve makes all of these unrelated-seeming setup steps click into place as the same underlying mechanism.

Subdomains vs separate domains: how DNS actually treats the difference

`blog.example.com` and `example.com` look closely related, and `example.org` looks almost identical to `example.com` — but DNS treats these very differently. A subdomain (`blog.example.com`) is just another record inside `example.com`'s own DNS zone, managed by whoever controls that zone, and it can point anywhere its owner chooses, including an entirely different hosting provider than the main site. A different domain (`example.org` vs `example.com`) is a completely separate registration with its own independent zone, its own nameservers, and no inherent DNS relationship to the other at all — the fact that the names look similar is purely cosmetic as far as DNS itself is concerned, which is exactly the gap phishing domains rely on when they register a lookalike name.

DNSSEC: a brief, honest note on security

DNS was designed in an era with far less adversarial traffic, and its responses are, by default, not cryptographically authenticated — meaning a resolver has no built-in way to verify that a response it received genuinely came from the real authoritative server rather than an attacker who managed to inject a forged answer (a class of attack broadly called DNS cache poisoning or spoofing). DNSSEC (Domain Name System Security Extensions) addresses this by cryptographically signing DNS records, letting a resolver verify a chain of trust back to the root. It's a real, meaningful security improvement, but adoption is still uneven across domains and resolvers — worth knowing about, without assuming every domain you interact with is protected by it.

Why a short TTL matters right before a migration

TTL trade-offs come up concretely any time someone is planning a real infrastructure change — moving a website to a new host, or a domain to a new IP. Set a long TTL (say, 24 hours) and DNS lookups get answered from cache more often, slightly reducing load on the authoritative server and speeding up repeat visits — but it also means any future change to that record will take up to that same 24 hours to be reliably seen everywhere. The standard practice before a planned migration is to deliberately lower the TTL (to a few minutes) well in advance of the actual cutover, wait for the old, longer TTL to fully expire out of caches everywhere, make the actual change, and only raise the TTL back up again once the new value is confirmed working — this is what keeps a planned migration's downtime window small and predictable instead of depending on how long random resolvers around the world happen to have cached the old answer.

Common problems that trace back to DNS

• "It works for me but not for someone else" — often just two different resolvers sitting at different points in their own TTL cache cycle after a recent DNS change, not an actual server-side inconsistency.
• A browser error like "DNS_PROBE_FINISHED_NXDOMAIN" — typically means the domain genuinely doesn't resolve at all (a typo, an unregistered domain, or a domain whose nameservers were never correctly configured), rather than a temporary network issue.
• Custom domain email suddenly stops arriving — very often traced to a missing or incorrect MX record, which is entirely separate from whether the website itself (an A or CNAME record) is working fine.
• A DNS change "not taking effect" right after making it — almost always just the previous TTL not having expired yet at the specific resolver being tested from, not a failed change.

The short version: DNS is a distributed, hierarchical lookup chain — root, then TLD, then the domain's own authoritative server — with caching and TTLs at every layer along the way, which is why changes ripple out gradually rather than everywhere at once. Most of the DNS-adjacent confusion people run into (slow propagation, email suddenly breaking, one person seeing an old version of a site) comes down to exactly one of these two mechanisms: which layer of the hierarchy holds the record you're looking for, and how long a cache along the way is still allowed to serve a stale answer.