What Is DNS and How Domain Name Resolution Works

What DNS actually does on every request

Every request to example.com starts with a lookup that has nothing to do with your application: something has to turn that name into an IP address before a single TCP packet leaves the machine. That translation is DNS, the Domain Name System, and it runs on every request, whether the client is a browser, curl, or a backend service calling another backend by hostname.

There is no single lookup table behind it. DNS is a hierarchy of servers, each responsible for one slice of the namespace, queried in sequence until the answer comes back. Knowing that chain is what turns “the site is down” into “the certificate expired” or “the record still points at the old IP”: two very different fixes that look identical from a browser tab.

How a recursive resolver walks the DNS hierarchy

Two kinds of server do the work, with different jobs. The recursive resolver is the one your machine talks to: your ISP’s, or a public one like 1.1.1.1 or 8.8.8.8. It does the walking on your behalf and hands back one final answer. The authoritative servers hold the actual records for a domain, split across a hierarchy that mirrors the dots in the name.

1
2
3
4
5
6
7
8

client  ->  resolver                             one query, one answer
            resolver -> root server              "who handles .com?"
                     <- nameservers for .com
            resolver -> .com TLD server          "who handles example.com?"
                     <- nameservers for example.com
            resolver -> example.com nameserver   "A record for example.com?"
                     <- 93.184.216.34
client  <-  resolver                             93.184.216.34

Root servers know nothing about example.com. They know which servers handle .com. The .com TLD (top-level domain) server doesn’t hold the record either; it only knows which nameservers are authoritative for example.com, the ones your registrar points at when you set up the domain. Only that last server holds the A record and returns an IP. Three round trips, so your machine never has to know the hierarchy exists.

Most of that walk never happens on a live request. Resolvers cache root and TLD answers for hours or days, since those barely change, so a real query usually starts at the authoritative server for the specific record. Often it doesn’t get that far: the answer is already in the cache.

The DNS record types you’ll actually use

A domain’s authoritative server holds a set of records, each one a different kind of answer to a different question:

CNAME is the one that trips people up. It doesn’t point to an IP; it points to another name, and the resolver has to look that name up too, following the chain until it hits an A or AAAA record. A CDN or a SaaS platform hands you a hostname like abcd123.cloudfront.net for exactly this reason: it can change the IPs behind that name whenever it needs to, and hand back a different one depending on where the query came from, without you touching your DNS record.

One restriction catches everyone setting up a bare domain: a CNAME can’t coexist with other records at the same name, and the zone apex (example.com with no subdomain) always needs NS and SOA records. So you cannot CNAME the apex to a CDN’s hostname, only a subdomain like www. Providers work around this with what they call ALIAS, ANAME, or CNAME flattening: the authoritative server resolves the target itself and hands back an A record, so the apex looks like an ordinary address record to every client while still tracking the CDN’s changing IPs behind it.

How to query DNS with dig

dig asks these questions directly, without a browser’s cache in the way.

1

dig example.com

The part that matters is the ANSWER SECTION:

1
2

;; ANSWER SECTION:
example.com.        300    IN    A    93.184.216.34

Five fields, in order: the name queried, the TTL in seconds (how long this answer may be cached), the class (IN for internet, effectively always this), the record type, and the value. A TTL of 300 means any resolver holding this answer re-queries within five minutes.

Query a specific type instead of the default A:

1
2
3

dig example.com MX
dig example.com TXT
dig example.com NS

Add +short when you want the value alone, which is what you want in a script:

1
2

dig +short example.com
93.184.216.34

Query a specific resolver with @. This is how you check whether a change has reached one provider before it reaches you:

1
2

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

+trace replays the whole walk, root server down to authoritative answer, instead of trusting a cached result:

1

dig +trace example.com

nslookup does the same basic job with an older, more verbose interface. Worth knowing because it ships on Windows by default, where dig often doesn’t.

Why a DNS change takes time: TTL and caching

Change a record and it does not appear everywhere at once. The delay gets called “propagation,” a word that suggests something spreading across the internet copy by copy. Nothing spreads. The new value is live at the authoritative server the moment you save it. What takes time is every resolver that already cached the old answer continuing to serve it until that copy expires.

That reframes the question worth asking. Not “how long does propagation take,” but “what TTL was on the old record, and how many resolvers cached it.” A TTL of 300 seconds means a resolver that queried a minute ago serves the old answer for four more minutes, tops. A TTL of 86400 means some resolver somewhere answers with the old IP for up to a day after you changed it. Some providers also ignore your TTL and cache longer than you asked, which is the other reason two people on different networks can honestly see different answers mid-change.

So plan the change instead of waiting it out. A day before a planned migration to a new server or a new CDN, drop the TTL on the record you’re about to touch to 60 or 300 seconds. That low TTL has to reach the caches first and expire the long-lived copies. Then make the real change: every resolver now refreshes inside the new short window instead of the old long one. Put the TTL back up once the new value is confirmed.

Common DNS mistakes, and when the problem isn’t DNS

A dangling CNAME is the most common one in the wild. A subdomain still points at a decommissioned service, an old S3 bucket or a deleted CDN distribution, and whoever claims that name on the other end can serve their own content under your domain. Delete the DNS record the same day you tear down what it pointed to, not weeks later.

Missing or wrong MX records look like a mail server problem. If outbound email works but nothing ever arrives, check the domain’s MX record before touching the mail server config; it may still point at a service you migrated away from months ago.

Plenty of “DNS is broken” reports aren’t DNS at all. If dig example.com returns the correct current IP and the site still doesn’t load, resolution already succeeded and the problem is downstream: a firewall rule, a certificate mismatch at the TLS handshake, or a reverse proxy routing on a Host header it doesn’t recognize. Check the answer with dig before you read anything into what the browser shows.

Where to check first when a domain doesn’t resolve

Run dig +short <domain> against your system resolver and against a public one (dig @1.1.1.1 +short <domain>). If they disagree, you’re mid-change, and the old TTL tells you how much longer to wait. If they agree and the IP is right, DNS has done its job: move on to TLS, routing, or the application. If the IP is wrong or nothing comes back, fix it at the authoritative nameserver. Flushing your local cache changes nothing that anyone else sees.

Related articles

• What Is a CDN and How It Works
• What Is TLS and How HTTPS Encryption Works
• What Is a Reverse Proxy and How It Works