Short answer: DNS (Domain Name System) works like the internet’s address book. When you type a domain name into your browser, a chain of servers translates that human readable name into a machine readable IP address. The lookup goes from your browser cache, to a recursive resolver, to a root server, to a TLD server, to the authoritative nameserver that holds the real answer. The whole round trip usually finishes in 20 to 120 milliseconds, and the result is cached so the next visit is nearly instant.
Most articles stop at the phonebook metaphor. This one does not. Below we follow one real request step by step, show the actual dig output returned at each hop, and then cover the parts developers and site owners actually struggle with: record types, TTL behaviour during a migration, and why DNS changes seem to “propagate” slowly when in reality nothing is propagating at all.
What DNS Actually Is (In Plain Terms)
Computers do not route traffic using words. They route packets using IP addresses such as 23.215.0.136 (IPv4) or 2606:2800:21f:cb07:6820:80da:af6b:8b2c (IPv6). Humans are terrible at remembering numbers, so DNS exists as a globally distributed, hierarchical database that maps names to those numbers.
Two properties make DNS work at internet scale:
- It is hierarchical. No single machine knows every domain. Responsibility is delegated downward, from the root, to
.com, toexample.com, toshop.example.com. - It is cached everywhere. Every answer carries a TTL (time to live) that tells every machine on the path how long it may reuse that answer without asking again.
Those two properties explain almost every DNS behaviour you will ever encounter, including the frustrating ones.
The Cast of Characters in a DNS Lookup
| Player | Role | Example |
|---|---|---|
| Stub resolver | The tiny client inside your OS or browser that starts the query | Windows DNS Client, systemd-resolved |
| Recursive resolver | Does the legwork, asks every server in the chain, caches the answer | 1.1.1.1, 8.8.8.8, your ISP resolver |
| Root servers | Know who runs each top level domain | 13 named root sets (a.root-servers.net to m.root-servers.net) |
| TLD servers | Know which nameservers are delegated to a given domain | a.gtld-servers.net for .com |
| Authoritative nameserver | Holds the actual zone file and gives the final answer | Your DNS host (Cloudflare, Route 53, your registrar) |
How Does DNS Work Step by Step
Here is the full sequence for a cold lookup of example.com, meaning nothing is cached anywhere.
- Browser cache check. Chrome, Firefox and Edge keep their own short lived DNS cache. If the name is there and still valid, the lookup ends in microseconds.
- OS cache and hosts file check. The operating system checks its own cache, plus the static
hostsfile, which always wins over DNS. - Query sent to the recursive resolver. Your device sends a UDP packet on port 53 (or an encrypted DoH/DoT session) to the resolver configured by DHCP or by you.
- Resolver checks its own cache. Public resolvers serve millions of users, so popular domains are almost always warm.
- Resolver asks a root server. The root does not know
example.com, but it knows who runs.comand returns a referral. - Resolver asks a .com TLD server. The TLD does not know the IP either, but it knows which nameservers are authoritative for
example.comand returns another referral. - Resolver asks the authoritative nameserver. This one holds the zone and returns the real A or AAAA record, flagged as authoritative.
- Resolver caches and replies. The answer is stored for the duration of the TTL, then handed back to your OS, which hands it to the browser.
- Browser opens a TCP connection. The TCP handshake plus TLS handshake begin against the returned IP address.
- The page loads. Every additional hostname on the page (CDN, fonts, analytics, images) triggers its own lookup, which is why DNS latency compounds.
The Same Journey, Shown With Real dig Output
dig ships with BIND utilities and is available on macOS and Linux out of the box, and on Windows through WSL or the BIND tools package. It is the fastest way to see what is really happening.
Stage 1: The Normal Lookup (What Your Browser Effectively Does)
$ dig example.com A
; <<>> DiG 9.18.28 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41215
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 213 IN A 23.215.0.136
;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 56Read the flags line. rd means recursion desired, ra means recursion available, and the absence of aa tells you this answer came from cache, not from the authoritative server. The 213 is the remaining TTL in seconds, counting down inside the resolver cache.
Stage 2: Ask a Root Server Directly
The +norecurse flag stops the server from doing the work for us, so we see the referral instead of the answer.
$ dig @198.41.0.4 example.com A +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58217
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; QUESTION SECTION:
;example.com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
;; SERVER: 198.41.0.4#53(198.41.0.4)Zero answers, thirteen authority records. The root said, in effect, “I do not know, but ask these .com machines.” The IP addresses in the additional section are called glue records and they prevent an infinite lookup loop.
Stage 3: Ask the .com TLD Server
$ dig @192.5.6.30 example.com A +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31904
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 172800 IN A 199.43.135.53
b.iana-servers.net. 172800 IN A 199.43.133.53Still no answer. This is the delegation step, and it is exactly what you change at your registrar when you “point the domain to a new DNS host”.
Stage 4: Ask the Authoritative Nameserver
$ dig @199.43.135.53 example.com A +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10442
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
example.com. 300 IN A 23.215.0.136
;; Query time: 24 msecNotice the aa flag. That means authoritative answer. This is the source of truth, and the TTL of 300 is the original value from the zone file, not a countdown. When you are debugging a DNS change, always compare the authoritative answer against what your resolver returns.
The Shortcut: dig +trace
You can replay all four stages in one command:
$ dig +trace example.com AIt starts at the root hints, follows each referral automatically, and prints every hop. Two other commands worth memorising:
dig example.com NS +shortshows which nameservers are live for the domain.dig @8.8.8.8 example.com Achecks what a specific public resolver currently has cached.
On Windows without dig, nslookup -type=NS example.com 8.8.8.8 covers most of the same ground, and ipconfig /flushdns clears the local cache. What is DNS and how DNS works tackles the same question from another angle.
DNS Record Types Developers Actually Use
| Record | What it does | Typical value | Gotcha |
|---|---|---|---|
| A | Maps a name to an IPv4 address | 203.0.113.24 | Multiple A records give crude round robin, not real failover |
| AAAA | Maps a name to an IPv6 address | 2001:db8::1 | A stale AAAA record breaks dual stack clients while IPv4 looks fine |
| CNAME | Aliases one name to another name | www to app.herokudns.com | Cannot coexist with other records at the same name, so no CNAME at the root unless your provider offers ALIAS or CNAME flattening |
| MX | Where email for the domain should be delivered | 10 mx1.provider.net | Lower priority number wins; MX must point to a hostname, never to an IP |
| TXT | Free text, used for SPF, DKIM, DMARC and domain verification | v=spf1 include:_spf.provider.com ~all | Only one SPF record per domain is allowed, merge instead of adding a second |
| NS | Delegates a zone to nameservers | ns1.provider.com | Must match what the registrar has set, otherwise you get a lame delegation |
| SOA | Start of authority, zone metadata and negative caching TTL | ns1.provider.com hostmaster… | The minimum field controls how long NXDOMAIN answers are cached |
| CAA | Lists which certificate authorities may issue certs | 0 issue “letsencrypt.org” | A forgotten CAA record blocks certificate renewal at the worst moment |
| PTR | Reverse lookup, IP back to name | mail.example.com | Set by whoever owns the IP block, not by you; critical for email deliverability |
TTL: The Single Most Misunderstood Number in DNS
Every record carries a TTL in seconds. It is an instruction to caches: you may reuse this answer for this many seconds before asking again.
| TTL value | Practical meaning | When to use it |
|---|---|---|
| 60 to 300 seconds | Changes take effect in minutes, more queries hit your nameservers | During migrations, failover setups, blue green deployments |
| 3600 seconds (1 hour) | A sane default balance | Normal production records |
| 86400 seconds (24 hours) | Fast and cheap, but a change can take a full day to clear | Records that never move, such as MX or verification TXT |
The Safe Migration Playbook
- 48 hours before the move: lower the TTL on every record you plan to change, from 86400 down to 300. You must wait out the old TTL for this reduction itself to take effect.
- Prepare the destination first: the new server should already answer correctly for the hostname, with a valid certificate, before anything changes in DNS.
- Keep the old server online: run both in parallel. Traffic will trickle over, not switch instantly.
- Flip the record: update the A, AAAA or CNAME value.
- Verify from multiple angles: query the authoritative server, then 1.1.1.1, then 8.8.8.8, then your own ISP resolver. They will agree at different times, and that is normal.
- Watch the old server’s access logs until requests stop arriving, which is the only reliable signal that caches have expired.
- Raise the TTL again once traffic is stable, typically after 24 to 72 hours.
Warning about nameserver changes: switching NS records at the registrar is a different animal. TLD delegations commonly use a 172800 second (48 hour) TTL, so plan for two full days and keep the old zone serving identical records the whole time.
Why DNS Changes Seem to Propagate Slowly
Here is the important correction that most beginner guides skip: DNS does not propagate. Nothing is pushed anywhere. Your authoritative nameserver is updated instantly, usually within seconds across a provider’s anycast network. There is more on it in How DNS Works.
What actually causes the delay is expiry of cached copies, and those copies live in a lot of places:
- The browser cache (Chrome keeps its own, cleared via
chrome://net-internals/#dns) - The operating system cache
- A local router or corporate DNS forwarder, which sometimes ignores TTLs entirely
- The ISP or public recursive resolver, potentially thousands of independent cache nodes worldwide
- Negative caching, where a previous NXDOMAIN result is held for the SOA minimum value
Each of those expires on its own schedule based on the TTL that was in force when it cached the record, not the TTL you set afterwards. That is why a change can look live for you and dead for a colleague in another country. This is also why so called “DNS propagation checkers” show a patchwork map: they are simply querying different resolvers with different cache states.
Fast Diagnostic Checklist
| Symptom | Command to run | Likely cause |
|---|---|---|
| Site works for some users only | dig @ns1.yourhost.com site.com A |
Cached old record still inside the TTL window |
| NXDOMAIN on a record you just created | dig site.com SOA |
Negative caching, wait out the SOA minimum |
| Email stopped arriving after a move | dig site.com MX +short |
MX records not recreated in the new zone |
| Random intermittent failures | dig site.com NS +short |
Split brain, two DNS hosts still authoritative with different data |
| SERVFAIL on one resolver only | dig site.com +dnssec |
Broken DNSSEC signature or a stale DS record at the registrar |
Security and Privacy: What Changed in Modern DNS
Classic DNS on port 53 is plain text and unauthenticated. Two layers fix different parts of that problem:
- DNSSEC cryptographically signs zone data so a resolver can verify the answer was not tampered with. It proves authenticity, not confidentiality.
- DoH and DoT (DNS over HTTPS and DNS over TLS) encrypt the conversation between your device and the resolver, so your network operator cannot read or rewrite your queries. Every major browser and mobile OS supports this today.
Also worth knowing: DNS filtering is one of the cheapest security controls available. Pointing company devices at a filtering resolver blocks known malware and phishing domains before a connection is ever opened.
Performance Tips That Actually Move the Needle
- Cut the number of distinct hostnames on a page. Each unique domain can cost a full lookup on first visit.
- Use
dns-prefetchandpreconnectin your HTML head for third party domains you know will be needed. - Pick an anycast DNS provider so queries are answered from a nearby point of presence rather than a single data centre.
- Add a secondary DNS provider for critical domains. If one provider goes down, the second keeps answering.
- Do not set TTLs to 30 seconds permanently. It multiplies lookups, adds latency for real users and rarely buys anything once a migration is finished.
Frequently Asked Questions
How does DNS work step by step, in one sentence?
Your browser asks a recursive resolver for a domain, the resolver asks a root server which points to the TLD server, the TLD server points to the authoritative nameserver, the authoritative nameserver returns the IP address, and the resolver caches that answer for the length of its TTL before handing it back to your browser.
Is 8.8.8.8 or 1.1.1.1 better?
Both are fast, free and globally anycast. 1.1.1.1 from Cloudflare is generally marginally faster in independent latency tests and has a stronger stated privacy position, while 8.8.8.8 from Google is extremely reliable and very widely peered. The honest answer is that the difference is usually a few milliseconds, and the best resolver for you is whichever one has a node closest to your network. Test with dig @1.1.1.1 example.com and dig @8.8.8.8 example.com and compare the query time yourself.
Why would someone need a DNS server?
Without DNS you would have to memorise raw IP addresses for every service you use, and nothing could ever change servers without breaking every link pointing at it. DNS provides a stable human readable name layer, plus load balancing, failover, geographic routing, email routing and domain ownership verification.
How long does a DNS change really take?
The change is live on your authoritative nameserver within seconds. Visibility for everyone else depends on the TTL that was cached before the change. With a 300 second TTL prepared in advance, most users see the new value in under 10 minutes. With a default 86400 second TTL, expect up to 24 hours. Nameserver (NS) changes at the registrar can take up to 48 hours.
Is DNS a protocol?
Yes. DNS is an application layer protocol defined mainly in RFC 1034 and RFC 1035, normally running over UDP port 53, falling back to TCP port 53 for large responses and zone transfers, and increasingly carried over TLS (port 853) or HTTPS (port 443).
What is the difference between a recursive resolver and an authoritative nameserver?
A recursive resolver asks questions on your behalf and caches the answers. An authoritative nameserver owns the data and gives the definitive answer. A resolver never owns records, and an authoritative server never goes hunting for records it does not hold.
Can I have a CNAME on my root domain?
Not in standard DNS, because the root of a zone must carry SOA and NS records and a CNAME cannot coexist with other records at the same name. Most modern DNS providers offer an ALIAS, ANAME or CNAME flattening record that resolves the target and returns A records instead, which achieves the same result.
How do I clear my DNS cache?
- Windows:
ipconfig /flushdns - macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux (systemd):
sudo resolvectl flush-caches - Chrome: visit
chrome://net-internals/#dnsand clear the host cache
Remember that this only clears your caches. It has no effect on your ISP resolver or on anyone else’s machine.
Key Takeaways
- DNS turns domain names into IP addresses through a hierarchy: resolver, root, TLD, authoritative.
- The
aaflag indigoutput is how you tell a real authoritative answer from a cached one. - Record types each solve a specific job, and the classic traps are CNAME at the root, duplicate SPF records and forgotten CAA records.
- TTL is a promise to caches, so lower it before a migration, not during one.
- DNS does not propagate. Old answers simply expire on their own schedule, which is why changes look inconsistent for a while.
Once you can read dig output and reason about TTLs, DNS stops being mysterious and becomes one of the most predictable parts of your stack. Bookmark the commands above, run them the next time a site “is not working for some people”, and you will usually have an answer within a minute.