DNS Explained: How the Internet Finds Your Website

A friend sends you a link, you tap it, and a page appears a moment later. At no point did you type an IP address, and at no point did you tell your browser where to look. Something turned that name into a destination first, and that something is DNS.

This is the story of a single lookup, in the order it actually happens. It is not a catalogue of record types and it is not a configuration guide — it is what happens between a name leaving your device and an answer coming back, which is the part that explains almost every DNS problem you will ever have to debug.

Before anything leaves your computer

The first surprise is how little the network is involved at the start. When you type or tap a name, your operating system checks whether it already knows the answer.

There are at least three places an answer could be waiting. The browser keeps a small cache of its own. The operating system keeps a resolver cache. And on Linux desktops, and on most home routers, a small forwarder runs locally with its own cache on top of those. If any of them holds a fresh copy, the lookup ends right there and nothing leaves the machine.

That is worth internalising, because it is why "it works on my machine" is not evidence of anything. Your machine may simply be reading a note it wrote twenty minutes ago. Try it on DNS Checkers Flush DNS Guide

The stub resolver, and the resolver that does the work

When no local copy exists, the question gets handed upwards. The component that does the handing is called a stub resolver, and it is deliberately unintelligent: it knows one thing, which is which server to ask.

The server it asks is the recursive resolver — sometimes called a caching resolver, and sometimes just "the DNS server", which is where a lot of confusion begins. In most homes and offices the recursive resolver is your router's forwarder or your ISP's equipment. Plenty of people deliberately point it somewhere else: Cloudflare's 1.1.1.1, Google's 8.8.8.8, Quad9's 9.9.9.9. Those addresses are familiar precisely because they are the setting you change when you want different DNS behaviour.

The recursive resolver may already have the answer cached. If it does not, it has to go and find out, and that search is the heart of how DNS works. Try it on DNS Checkers Check DNS Propagation

Walking down the tree

DNS is a hierarchy, not a phone book. Resolving a name means walking down that hierarchy, and the walk happens in referrals.

At the very top sit the root servers. They do not know where any particular website lives. What they know is who is responsible for each top-level domain. Ask a root server about example.com and you get a referral rather than an answer: here are the nameservers for .com.

The recursive resolver takes that referral and asks one of the .com servers about example.com. That server does not hold the final answer either. It holds a delegation — a pointer to the nameservers the domain owner configured, whether that is a registrar's default pair or a managed DNS provider. So it returns a second referral.

Now the resolver asks those authoritative nameservers directly. This time the response is not a referral. It is the answer, and by definition it is the correct answer for that zone, because an authoritative server is the source of truth the domain owner controls. Nothing above it in the tree gets to disagree.

Three trips, usually in well under a second, and only the first time.

Why the answers stick around

If every lookup walked the whole tree, the root servers would melt. They do not, because DNS caches aggressively at every layer, and each cached copy carries an expiry time — its TTL, counted in seconds.

On the second lookup, the recursive resolver answers from memory without asking anyone. On the hundredth lookup from a thousand different people behind that same resolver, the same thing happens. The hierarchy is consulted mainly when something is new, or when something has expired.

This design is why DNS scales to the size of the internet on remarkably little hardware, and it is also the reason changes take time to appear everywhere. We cover that separately in the propagation guide, because "it has not propagated yet" is the most common thing people say about DNS, and it is only half true. Try it on DNS Checkers Check DNS Propagation

When the name does not exist at all

Not every lookup succeeds, and the way DNS reports failure is worth knowing because it creates a problem of its own.

If you ask for a name that has no records at all, the authoritative server answers with NXDOMAIN — a definitive "that name does not exist". Crucially, that negative answer is cached too. Resolvers are told to remember "no such name" for a period, and the length of that period comes from the zone's SOA record rather than from any individual record's TTL.

This is why a brand-new record can appear to be missing long after you created it. Resolvers that asked a few minutes before you added it are still holding the NXDOMAIN they were given, and they will keep handing that answer out until the negative cache expires. It is one of the most confusing situations in DNS: the record is right there in your panel, the authoritative server returns it, and a resolver insists the name does not exist.

There is a second kind of empty response too — NODATA, where the name exists but has no record of the type you asked for. That gets negative-cached as well, which matters most when you have just added a new record type to a name that already existed.

Several answers at once, and no particular order

A single name can hold several records of the same type. example.com may have two A records pointing at two different servers, and four MX records with different priorities. When that happens, the resolver returns a set, and the order it arrives in is not something you should rely on.

Two consequences follow. First, if you are running more than one server behind a name, "which one am I hitting?" is answered by your load balancing and by client behaviour, not by DNS ordering. Second, when you check a record and see one of several plausible values, that is not a problem — it is the set.

A detail worth knowing: one port, two protocols

DNS lives on port 53, and it uses two transport protocols rather than one.

Most queries travel over UDP. A question and its answer usually fit in a single packet, so there is no reason to pay the cost of opening a connection. But when a response is too large for one UDP packet, the resolver retries over TCP. Zone transfers between nameservers always use TCP.

This matters more often than you would expect. Captive portals and restrictive firewalls sometimes permit only UDP on port 53, so everything appears to work — until a response grows past the limit, at which point lookups begin failing in ways that look random. Signed zones hit this more often, because DNSSEC signatures make responses substantially larger.

What actually happens when you change a record

Here is the part that surprises newcomers. When you edit a record in your DNS panel, almost nothing observable happens immediately.

You have changed exactly one thing: what the authoritative servers return. Everything else in the world is still holding whatever it last cached, and it will keep holding it until its own TTL expires. Your own browser may show the new value instantly because you just cleared its cache, or may show the old one for another hour because you did not.

Nothing about that is broken. It is the same caching that makes the system scale, applied to a change you wanted to see everywhere at once.

Why DNS problems feel so strange

Three properties explain most of the confusion.

DNS is distributed, so there is no single place to look and no master switch. It is cached at multiple layers, so two people can be looking at two different truths at the same moment. And it fails partially as a matter of routine — a record can be correct for one resolver, wrong for another, and missing for a third, all at once.

That combination means the useful question is rarely "is DNS broken?" It is "which resolver is saying what, and why?" Answering that is a matter of looking at specific sources in a specific order, which is exactly what the tools here are built for. Try it on DNS Checkers Lookup All DNS Records

What to take away

A lookup is a walk down a hierarchy: root, then TLD, then the authoritative servers for the domain. Answers are cached at every layer, with TTLs deciding how long each copy survives. And changes spread by expiry rather than by broadcast, which is why they appear at different times in different places.

Hold those three ideas and most DNS behaviour stops being mysterious. You will still get caught out — everyone does — but you will know where to look, and you will understand why the answer depends on who is asking.