Every developer uses DNS thousands of times a day without thinking about it. Then one day your deploy breaks because of a DNS propagation delay, or your site goes down because of a misconfigured CNAME, and suddenly you need to understand what is actually happening beneath example.com. I have been through this enough times to know that a basic understanding of DNS prevents hours of confused debugging.
The lookup chain
When you type example.com in your browser, a sequence of lookups happens before any HTTP request is made.
1. Browser cache. The browser checks if it has seen this domain recently. Chrome caches DNS results for 60 seconds by default.
2. OS cache. If the browser cache misses, the operating system's stub resolver checks its own cache. On macOS, this is handled by mDNSResponder. On Linux, it is systemd-resolved or the resolver library.
3. Recursive resolver. If the OS cache misses, the query goes to your configured DNS resolver -- typically your ISP's resolver or a public one like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). This is the server that does the heavy lifting.
4. Root servers. The recursive resolver starts at the root. There are 13 root server addresses (each backed by hundreds of anycast instances worldwide). The resolver asks the root: "Where do I find .com?"
5. TLD servers. The root server responds with the address of the .com TLD (Top-Level Domain) nameservers. The resolver asks the TLD server: "Where do I find example.com?"
6. Authoritative nameserver. The TLD server responds with the address of example.com's authoritative nameserver -- the server that actually holds the DNS records. The resolver asks the authoritative server: "What is the A record for example.com?"
7. The answer. The authoritative server responds with the IP address. The recursive resolver caches this result according to the TTL (Time To Live) and returns it to your browser. Your browser can now make the HTTP connection.
This entire process typically completes in 20-120 milliseconds. Subsequent requests for the same domain hit the cache and resolve in under a millisecond.
Record types you need to know
A record: Maps a domain to an IPv4 address. This is the most fundamental record type.
example.com. 300 IN A 93.184.216.34
AAAA record: Maps a domain to an IPv6 address. The name is "quad-A" because IPv6 addresses are four times longer than IPv4.
CNAME record: An alias that points one domain to another. When the resolver hits a CNAME, it follows the chain to the target domain and resolves that instead.
www.example.com. 300 IN CNAME example.com.
CNAME records have a critical restriction: they cannot coexist with other record types at the same name. This means you cannot have a CNAME at the root domain (example.com) if you also need MX records for email. Many DNS providers work around this with proprietary "ALIAS" or "ANAME" records that function like CNAMEs but resolve on the server side.
MX record: Specifies the mail server for a domain. The priority value (lower is preferred) determines which server receives mail first.
example.com. 300 IN MX 10 mail.example.com.
example.com. 300 IN MX 20 backup-mail.example.com.
TXT record: Holds arbitrary text. Used for email authentication (SPF, DKIM, DMARC), domain verification, and various other purposes.
example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
NS record: Delegates a domain or subdomain to specific nameservers. This is how the parent zone tells resolvers where to find the authoritative servers.
Command-line DNS debugging
dig is the standard DNS debugging tool. If you are not using it, you should be.
# Basic A record lookup
dig example.com
# Query a specific record type
dig example.com MX
dig example.com TXT
dig example.com AAAA
# Query a specific nameserver
dig @8.8.8.8 example.com
# Trace the full resolution path
dig +trace example.com
# Short output (just the answer)
dig +short example.com
The +trace flag is invaluable for debugging propagation issues. It follows the entire chain from root to authoritative, showing you exactly where the resolution succeeds or fails.
nslookup is simpler but less informative:
nslookup example.com
nslookup -type=MX example.com
TTL and propagation
TTL (Time To Live) tells resolvers how long to cache a record, specified in seconds. A TTL of 300 means the record is cached for 5 minutes. A TTL of 86400 means 24 hours.
"DNS propagation" is a misleading term. DNS does not actively propagate. When you change a record, existing caches continue serving the old value until their TTL expires. The "propagation time" is really just the maximum TTL of the old record.
This is why you should lower your TTL before making DNS changes. If your TTL is 86400 (24 hours) and you need to change your A record during a migration, lower the TTL to 300 (5 minutes) at least 24 hours in advance. After the change, wait until the old caches expire (now only 5 minutes), verify everything works, then raise the TTL back.
Common mistakes
Setting CNAMEs at the root domain. As mentioned, CNAMEs conflict with other record types. Your root domain needs an A (or AAAA) record, not a CNAME. Use your DNS provider's ALIAS/ANAME feature if you need to point the root at another hostname.
Forgetting the trailing dot. In DNS zone files, a name without a trailing dot is relative to the zone origin. www becomes www.example.com. but www.example.com (without the trailing dot) becomes www.example.com.example.com. This catches people when editing zone files manually.
Not checking all nameservers. If your domain has four authoritative nameservers, a change might be live on two and stale on two. Always verify against all of them:
dig +short NS example.com
# Then query each one
dig @ns1.provider.com example.com
dig @ns2.provider.com example.com
For quick lookups during debugging -- checking A records, MX configuration, TXT records for email authentication, or verifying DNS changes -- I use a DNS lookup tool at zovo.one/free-tools/dns-lookup that queries multiple record types in one view.
DNS is invisible infrastructure until it breaks. Understand the lookup chain, know your record types, and always check TTL before making changes.
I'm Michael Lip. I build free developer tools at zovo.one. 350+ tools, all private, all free.
Top comments (0)