DNS is where most site-level problems actually live. Not the code, not the server, not the browser. DNS. This article gives you enough DNS fluency to read records, diagnose propagation issues, and stop guessing when something breaks.
What happens on a lookup
When a visitor types example.com, their computer asks a recursive resolver (usually their ISP's, or 1.1.1.1, or 8.8.8.8). The resolver walks the DNS tree: root servers point to the .com TLD, the .com TLD points to the domain's authoritative nameservers, and the authoritative nameservers answer with the final IP. That answer is cached everywhere along the path for however long the record's TTL says.
The record types that actually matter
| Type | What it does | Typical use |
|---|---|---|
| A | Maps hostname to IPv4 address | @ or www → server IP |
| AAAA | Maps hostname to IPv6 address | Same as A, but IPv6 |
| CNAME | Alias one hostname to another | www → example.com |
| MX | Mail exchanger for the domain | Directs inbound email |
| TXT | Arbitrary text | SPF, DKIM, DMARC, domain verification |
| NS | Nameservers for the zone | Who answers authoritatively |
| CAA | Allowed certificate authorities | Restricts who can issue SSL |
Reading records with dig
dig is the tool. It ships on macOS and Linux, and Windows users can install it via BIND or use nslookup as a fallback.
# Who is authoritative for this domain?
dig +short NS example.com
# What does the domain resolve to?
dig +short A example.com
# Ask a specific resolver (bypass your ISP's cache)
dig @1.1.1.1 +short A example.com
# Full trace from root — diagnoses delegation issues
dig +trace example.com
# MX records and their priorities
dig +short MX example.com
# All TXT records (SPF, DKIM, DMARC, etc.)
dig +short TXT example.comTTL: the number that controls propagation
Every record has a TTL (time to live) in seconds. A record with TTL 3600 may be cached by resolvers worldwide for up to an hour. If you plan to change a record, drop the TTL to 300 (five minutes) a few days ahead of the change so old entries expire quickly.
A real example: adding www
You've set up example.com but www.example.com does not load. The fix is a CNAME or a second A record:
# Option A: CNAME (preferred for www)
www.example.com. IN CNAME example.com.
# Option B: second A record (required at zone apex if no CNAME flattening)
www.example.com. IN A 192.0.2.10
example.com. IN A 192.0.2.10When a change hasn't propagated
Most of the time the record is fine and your local cache is lying. Verify from a neutral vantage:
# Check from Cloudflare's resolver
dig @1.1.1.1 +short A example.com
# Check from Google's resolver
dig @8.8.8.8 +short A example.com
# Or use a web tool that queries from 20+ locations
# https://www.whatsmydns.net/If all external resolvers return the new IP but your browser still shows the old site, the problem is your local cache. Flush it:
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux with systemd-resolved
sudo systemd-resolve --flush-caches
# Windows
ipconfig /flushdnsCommon gotchas
- · CNAME at the zone apex. RFC 1912 forbids a CNAME on the root (example.com, not www.example.com). Use an A record, or a provider that supports CNAME flattening (Cloudflare, Route 53 alias).
- · Dangling records. A CNAME pointing to a hostname that no longer exists will silently fail. Delete records for services you no longer use.
- · Overlapping MX. Only one set of MX records should exist for a zone. Mixing Google Workspace MX with cPanel MX causes random delivery failures.
- · Ignoring DNSSEC mismatches. If your registrar publishes DS records but your nameservers aren't signing, resolvers will refuse to answer.
Still stuck?
Email [email protected] with the output of dig +trace yourdomain.com and we will read it with you.