DNS Basics: How It Actually Works

DNS gets described as the internet's phone book so often that the phrase has stopped meaning much. It's a reasonable starting point, but it doesn't explain why a DNS change can take hours to show up everywhere, why some monitoring alerts are noise and others are urgent, or what's actually happening between typing a domain name and a page loading. This article covers the mechanics from the ground up, so the more specific articles on this blog (on individual record types, TTL, propagation, and monitoring) have something to build on.

What DNS solves

Computers route traffic using IP addresses, not names. DNS exists because humans are bad at remembering strings like 203.0.113.42, and because a server's address can change over time without anyone wanting to update it by hand everywhere it's referenced. DNS is the system that maps a name you can remember to the address a computer needs, and it resolves that name every time it's needed, either with a fresh query or from a nearby cache.

That's the whole job: given a name, return the current answer. Everything else (records, resolvers, caching, propagation) is about how that answer gets produced, distributed, and kept up to date.

The anatomy of a domain name

A domain name's hierarchy runs right to left: each label narrows things down, from the broadest part (the TLD) to the most specific (the subdomain):

mail.example.com

• com is the top-level domain (TLD). It's the broadest category, and a registry keeps track of every domain registered under it.
• example is the second-level domain, the name you registered with a domain registrar.
• mail is a subdomain (sometimes called a host or hostname), a label your own DNS configuration adds in front of your domain to point at a specific service, like a mail server or a particular application.

There's technically one more layer above .com: an invisible trailing dot representing the DNS root zone. You'll rarely see it written out, but it's where the resolution process described below starts.

The resolution process, step by step

When something needs to resolve mail.example.com to an IP address, the request typically passes through several layers before an answer comes back:

1. Stub resolver. Your device or application doesn't do DNS lookups itself. It asks a recursive resolver, usually one run by your ISP, your company network, or a public resolver like Cloudflare or Google, to do the work and return an answer.
2. Recursive resolver. This is the workhorse. If it already has the answer cached from a previous lookup, it returns that immediately. If not, it starts querying on your behalf, working down from the top.
3. Root servers. The recursive resolver first asks one of the DNS root servers, which don't know the answer but know which servers are responsible for the .com TLD, and refer the resolver there.
4. TLD servers. The .com TLD servers don't know the answer either, but they know which nameservers are authoritative for example.com specifically, based on that domain's NS records, and refer the resolver there.
5. Authoritative nameservers. These are the servers your DNS provider runs, and they hold the records for your domain. They return the current value for mail.example.com, whatever record type was requested.
6. Answer returned and cached. The recursive resolver hands the answer back to your device and caches it for as long as the record's TTL allows, so the next request for the same name doesn't need to repeat this whole chain.

You can watch this chain happen yourself:

dig +trace mail.example.com

This walks the same path a resolver takes (root, then TLD, then authoritative), printing each referral along the way. It's a useful way to confirm that a domain's NS delegation points where you expect.

Recursive resolvers vs. authoritative nameservers

This distinction comes up constantly once you're troubleshooting DNS, so it's worth being precise about it. A recursive resolver is a middleman: it doesn't own any DNS data. It just fetches and caches answers on behalf of whoever asks it. An authoritative nameserver is the source of truth: it's run by (or on behalf of) the domain owner, and it holds the records.

The difference matters because caching only happens at the recursive layer. A recursive resolver might be serving a stale, cached answer for a domain even though the authoritative nameserver has already been updated with the new value. Querying the authoritative nameserver directly always shows the current record:

dig @ns1.example.com mail.example.com A

This is also why DNS monitoring tools like OneDollarDNS query authoritative nameservers directly rather than relying on public resolvers: it's the only way to see a change the moment it happens rather than whenever a cache elsewhere happens to expire.

The record types you'll run into

A domain's DNS configuration is a set of records, each one a different type of answer for a given name. The common ones, with links to a full explanation of each:

• A and AAAA records map a name to an IPv4 or IPv6 address. These are what most people mean when they think of "the DNS record."
• CNAME records alias one hostname to another, useful when you want a subdomain to follow whatever address a third-party service (a CDN, a SaaS platform) is currently using.
• MX records tell other mail servers where to deliver email for your domain.
• TXT records, including SPF, DKIM, and DMARC, hold arbitrary text data, most commonly used for email authentication and domain verification.
• NS records declare which nameservers are authoritative for a domain. Every other record depends on these being correct.
• SOA records hold administrative metadata about a zone, including how long secondary nameservers should cache negative answers.
• CAA records specify which certificate authorities are allowed to issue TLS certificates for a domain.
• PTR records do the reverse of an A record, mapping an IP address back to a hostname.

A typical domain ends up with most of these. A/AAAA, NS, SOA, MX, and TXT are close to universal for any domain that serves a site or sends email. CAA is optional and often skipped, and PTR usually isn't yours to manage at all, since it lives in the reverse zone tied to an IP address block, typically controlled by whoever hosts that IP rather than by the domain owner. Either way, knowing what each one is for makes it easier to recognize when a change to one of them is expected versus suspicious.

Caching, TTL, and why changes aren't instant

Every record carries a TTL (time to live), a number of seconds telling any resolver that caches it how long to hold onto that answer before checking again. This is what makes DNS fast: without caching, every request for every domain would require the full resolution chain described above. It's also why a DNS change doesn't reach everyone at once. Resolvers around the world are holding cached answers with different amounts of time left on them, so different people can see the old and new value simultaneously until every cache catches up. See why DNS propagation takes so long and TTL explained for the full mechanics.

Where DNS problems actually come from

Most DNS incidents aren't exotic. They tend to fall into a few familiar shapes: a record that was typed wrong during a manual edit, an NS delegation left pointing at an old provider after a migration, a TXT record for SPF or DMARC that got dropped or overwritten, or a change nobody on the team made and can't immediately account for. None of these announce themselves. DNS doesn't fail loudly the way an application crash does. It just quietly serves whatever the records currently say, correct or not, until someone notices, often because a visitor lands somewhere wrong, an email bounces, or a certificate renewal fails.

How DNS monitoring fits in

The mechanics above are also what a DNS monitoring tool is built around. OneDollarDNS queries your domain's authoritative nameservers directly, the same servers described in the resolution process, and compares the current answer against what it saw last time. Because that check bypasses the caching layer entirely, it can catch a change within minutes, regardless of the record's TTL.

If you're new to monitoring and want to know what to do once an alert arrives, what to do when DNS monitoring alerts you covers how to evaluate a change and decide whether it's expected or worth escalating.