How DNS Works

DNS is the directory system of the internet

Humans remember names like example.com. Networks route packets using IP addresses. DNS bridges that gap by answering questions such as “what address should I use for this domain?”

Most applications rely on DNS constantly, but the actual resolution process is distributed, cached, and layered, which is why DNS behavior can feel inconsistent when records change.

Last updated: May 11, 2026

Colorful DNS lookup diagram showing browser cache, recursive resolver, root and TLD nameservers, and authoritative DNS. — DNS resolution is distributed: caches answer first when they can, and recursive resolvers walk the hierarchy when they cannot.

The basic flow

Your device or browser checks local caches first.
If nothing is cached, it asks a recursive resolver, often run by your ISP, company, or public DNS provider.
The resolver walks the DNS hierarchy, starting from the root, then the top-level domain, then the authoritative nameserver for the domain.
The authoritative server returns the requested record such as an A, AAAA, CNAME, MX, or TXT record.
The resolver caches the answer based on its TTL and returns it to the client.

A concrete lookup example

If you type api.example.com into a client, the browser or operating system first checks whether it already knows the answer. If not, it asks a recursive resolver, which may contact root servers, then the .com nameservers, then the authoritative nameservers for example.com until it finds the final record.

That layered walk is why DNS can be both resilient and confusing. Each step is simple, but the full path involves multiple caches and independent systems.

Why caches matter

DNS would be slow and expensive if every lookup had to start from the root servers. Caching lets commonly requested names be answered quickly by resolvers, operating systems, browsers, and sometimes intermediate layers.

The downside is that a record update may not appear everywhere immediately. Different caches expire at different times, and some systems behave more aggressively than expected.

Why record changes look inconsistent

When developers talk about “DNS propagation,” they often mean that some caches still hold the old answer. One network might already be using the new IP while another still serves the old one. TTL values, resolver behavior, and local client caches all influence how long that mismatch lasts.

That is why rollout plans for DNS changes often reduce TTLs first, wait, then make the actual record update later.

Common record types

A and AAAA records map names to IPv4 and IPv6 addresses.
CNAME records alias one name to another name.
MX records define mail delivery targets.
TXT records hold arbitrary text and are often used for verification and email policies.

Common confusion

DNS propagation is usually cache expiration, not a magical global push event.
A CNAME does not directly point to an IP address; it points to another name.
DNS resolution happens before an HTTPS request can reach the target server.

What developers usually check first

When a hostname behaves strangely, the practical checks are usually: which resolver answered, what record type was requested, whether the TTL is still keeping an old answer alive, and whether the expected hostname matches the certificate and application routing behind it. DNS is often only the first visible symptom in a longer request path.