What is DNS and How Does Domain Resolution Work Explained

What DNS actually does (and why your browser cares)

Type "example.com" into your browser and hit enter. Somewhere in the next 200 milliseconds, a machine you've never met answers a question you never consciously asked: which IP address belongs to this name? That's DNS in one sentence. The Domain Name System is the internet's naming layer — a globally distributed directory that maps human-readable domain names to the numeric IP addresses computers actually route traffic to.

You never see it. You only notice it when it breaks.

I remember the first time DNS bit me properly. I'd migrated a client's site to a new host, updated the A record, and waited. Twelve hours later, half the office saw the new site and half still saw the old one. Nobody had done anything wrong. Caching was just doing its job. That afternoon taught me more about how domain resolution works than any documentation page ever did.

What is DNS for a domain?

For a single domain, DNS is the set of records that tell the rest of the internet where to send traffic. Think of a domain as a mailbox address that stays fixed while the building behind it can move. The DNS records are the forwarding instructions.

The records that matter most

When you open the DNS panel at your registrar or hosting provider, you're editing a small zone file. These are the entries you'll actually touch:

• A record — points a name to an IPv4 address.
• AAAA record — the same idea for IPv6.
• CNAME — an alias that says "this name is really that other name." Handy for subdomains, but you can't put one at the root of a domain.
• MX — routes email to the right mail server. Get this wrong and your contact form silently stops delivering.
• TXT — free-form text, used heavily for domain verification and email authentication (SPF, DKIM).
• NS — declares which nameservers are authoritative for the domain.

Here's the part most tutorials skip: a domain doesn't have "a DNS." It has a zone, and that zone is only as correct as the last person who edited it. I once spent two hours debugging a broken newsletter because someone had typo'd a single character in an MX record. Everything else was fine.

How does a DNS resolution work?

A DNS resolution is a chain of questions, each one narrowing the search until an authoritative server gives a definitive answer. It sounds heavy. In practice, most of it happens in under 50 milliseconds, and much of it doesn't happen at all because of caching.

The step-by-step walkthrough

1. Your device checks its local cache. The operating system, and often the browser itself, keeps a short-lived record of recent lookups.
2. The recursive resolver takes over. If nothing is cached locally, your device asks a resolver — usually one run by your ISP or a public service like Google or Cloudflare.
3. The resolver checks its own cache. If the answer is fresh, the lookup ends here. This is where the vast majority of real-world queries stop.
4. Root servers. On a miss, the resolver queries a root server, which doesn't know the IP but knows who's responsible for the top-level domain (.com, .org, .io).
5. TLD servers. These point the resolver toward the authoritative nameservers for the specific domain.
6. Authoritative nameserver. This one holds the actual zone file and returns the real answer — the A record, the AAAA record, whatever was asked for.
7. The answer travels back and gets cached at each step along the way, according to its TTL.

The whole exchange happens over UDP on port 53 for most queries. That's a small detail, but it explains why DNS is fast: no handshake, no session setup, just a question and an answer.

TTL, and why your DNS changes don't appear instantly

Every record carries a time-to-live value, measured in seconds. A TTL of 3600 means resolvers may cache that answer for an hour before asking again. Lower the TTL before a planned migration and you cut the waiting window dramatically. Forget to do it, and you're stuck watching some users hit the old server while others hit the new one.

Real talk: this is the single most common source of "the internet is broken" tickets I've seen. It isn't broken. It's cached.

The DNS hierarchy, in plain terms

DNS isn't one database sitting in a data center. It's a hierarchy of delegation, and that design is why it scales to billions of names without a single point of control.

Layer	What it holds	Who runs it
Root	Pointers to every top-level domain	A small set of coordinated operators worldwide
TLD	Delegation for one suffix (.com, .fr, .dev)	Registries like Verisign or national bodies
Authoritative	The actual records for your domain	You, or your hosting/DNS provider

Read that table again and notice something: you only control the bottom row. Everything above it is infrastructure you rely on but never administer. Which is exactly why DNS problems are so frustrating — the broken part is often outside your reach.

Is DNS a protocol?

Yes. DNS is a protocol — actually a family of them. Plain DNS runs mainly over UDP and TCP port 53. Modern encrypted variants have grown fast: DoH (DNS over HTTPS) and DoT (DNS over TLS) wrap queries in encryption so your ISP can't read them in transit. If you care about privacy on public Wi-Fi, DoH is worth the two minutes it takes to enable.

Is 8.8.8.8 or 1.1.1.1 better?

Honestly? For most people, neither is meaningfully "faster" in day-to-day browsing. Both are well-run public resolvers with global anycast networks, and any latency difference between them is usually swamped by whatever your device already has cached.

The real differences are elsewhere:

• 8.8.8.8 is Google's resolver. Extremely reliable, broadly compatible, and logs queries in anonymized form for service improvement.
• 1.1.1.1 is Cloudflare's. It markets itself on privacy, publishes third-party audits of its logging practices, and tends to be the pick for people who specifically don't want a search company seeing their lookups.

My take: pick based on privacy posture and filtering needs, not on a speed test you ran once at 11pm. And if your ISP's resolver is genuinely slow or hijacks failed lookups to show ad pages, switching to either public option is a clear win. I switched a home network to Cloudflare three years ago purely to stop the ISP's "helpful" error pages, and I'd make that same call again.

Should you change your resolver at all?

Only if you have a reason. If your browsing feels fine and your ISP isn't injecting ads into NXDOMAIN responses, leave it alone. Changing resolvers doesn't fix slow websites, and it won't speed up a server that's genuinely overloaded.

When domain resolution goes wrong

DNS failures rarely announce themselves clearly. They show up as "site can't be reached," delayed email, or a page that loads for you but not for your colleague in another country.

A few patterns I've learned to check first:

• Propagation lag. You changed a record; the old value is still cached somewhere. Verify with a lookup tool that queries multiple resolvers.
• Wrong record type. Pointing a root domain with a CNAME, or forgetting the AAAA record so IPv6 users can't connect.
• Missing or malformed TXT records. Email lands in spam, and nothing in the browser tells you why.

One habit has saved me more time than any tool: after every DNS change, test from at least three different networks before declaring victory. Your own machine is the worst possible witness, because it's the one most likely to hold a stale cache.

The question that lingers

What strikes me about DNS is how much invisible coordination it requires. Nobody is in charge of it, yet a resolution on one side of the planet reaches a server on the other in a fraction of a second — through a hierarchy of delegations agreed upon decades ago. It's one of the few systems that complex that mostly just works.

Which raises an uncomfortable question worth sitting with: if the naming layer of the internet is this dependent on caching, delegation, and trust between organizations that don't coordinate directly, how much of the rest of your infrastructure relies on the same quiet assumption — that everyone upstream did their job correctly?

Worth checking your zone file. Just in case.