DNS connects domain names to websites and email services. This guide explains common record types and how to check changes with DNS lookups.
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.
Common DNS record types
| 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
Use dig to inspect DNS records from the command line. On systems without dig, use nslookup or a DNS lookup tool.
# 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.
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
A local DNS cache may still contain the previous record. Compare the response from other resolvers:
# 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 issues
- 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.
Contact support
Email [email protected] with your domain and the output of dig +trace yourdomain.com.