The Domain Name System (DNS) translates human-readable domain names like example.com into IP addresses like 93.184.216.34. It is a globally distributed, hierarchical database that handles over 1 trillion queries per day. Every web request, API call, and email delivery starts with a DNS lookup. Understanding DNS is essential for debugging connectivity issues, configuring domains, and optimizing performance.
What Are DNS Record Types?
DNS records are instructions stored on authoritative nameservers. Each record has a type, name, value, and TTL (time to live). Here are the most important record types:
| Type | Purpose | Example Value |
|---|---|---|
| A | Maps domain to IPv4 address | 93.184.216.34 |
| AAAA | Maps domain to IPv6 address | 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME | Alias to another domain name | app.example.com → lb.cloud.com |
| MX | Mail server with priority | 10 mail.example.com |
| TXT | Arbitrary text (SPF, DKIM, verification) | v=spf1 include:_spf.google.com ~all |
| NS | Authoritative nameserver for zone | ns1.cloudflare.com |
| SOA | Start of Authority — zone metadata | ns1.example.com admin.example.com ... |
| SRV | Service location (host + port) | _sip._tcp.example.com 5060 |
| CAA | Restricts which CAs can issue certs | 0 issue "letsencrypt.org" |
| PTR | Reverse DNS — IP to domain | 34.216.184.93.in-addr.arpa → example.com |
How Does DNS Resolution Work?
When you type a URL, the DNS resolution process involves multiple steps. Most lookups complete in under 50ms because of caching at every layer.
User types: https://app.example.com
1. Browser cache → Checks its own DNS cache (Chrome: chrome://net-internals/#dns)
2. OS cache → Checks /etc/hosts and OS resolver cache
3. Recursive resolver → Your ISP or configured resolver (e.g., 8.8.8.8, 1.1.1.1)
├─ Cache hit? → Return cached answer immediately
└─ Cache miss? → Query the hierarchy:
a. Root servers (.) → "Ask .com nameservers"
b. TLD servers (.com) → "Ask example.com nameservers"
c. Authoritative NS → "app.example.com = 93.184.216.34"
4. Answer cached at each layer for the TTL duration
5. IP returned to browser → TCP connection beginsHow Does DNS Caching and TTL Work?
The TTL (Time To Live) value on each DNS record tells resolvers how long to cache the answer, in seconds. Choosing the right TTL is a trade-off between performance and propagation speed.
| TTL | Duration | Use case |
|---|---|---|
| 60 | 1 minute | Failover, load balancing, pre-migration |
| 300 | 5 minutes | Dynamic services, frequently changing IPs |
| 3600 | 1 hour | Standard web applications |
| 86400 | 24 hours | Stable records (MX, NS) |
Migration tip: Before changing a DNS record, lower the TTL to 60 seconds at least 24–48 hours in advance. After the change propagates, raise the TTL back. This ensures old caches expire quickly when you make the switch.
What Are Common DNS Misconfigurations?
DNS errors are notoriously hard to debug because symptoms (timeouts, wrong server, bounced emails) appear far from the cause. These are the most frequent mistakes:
- • CNAME at zone apex — A CNAME record at the root domain (e.g.,
example.com) violates RFC 1034. Use an A/AAAA record or a provider-specific alias record (ALIAS/ANAME). - • Missing trailing dot — In zone files,
app.example.comwithout a trailing dot is treated as relative to the zone, producingapp.example.com.example.com. - • High TTL before migration — Changing an A record with a 24h TTL means some users will hit the old server for up to a full day.
- • Missing MX records — No MX record means mail servers fall back to the A record, which usually is not a mail server.
- • SPF/DKIM/DMARC misconfiguration — Missing or incorrect TXT records cause outbound email to land in spam or be rejected entirely.
- • Pointing CNAME to IP address — A CNAME must point to a domain name, never an IP address. Use an A record for IPs.
How Do You Debug DNS with dig and nslookup?
dig and nslookup are the primary tools for DNS troubleshooting. dig is preferred on Unix systems because it shows full resolver details.
# Basic A record lookup
dig example.com
# Query a specific record type
dig example.com AAAA
dig example.com MX
dig example.com TXT
# Query a specific nameserver (bypass cache)
dig @8.8.8.8 example.com A
# Trace the full resolution path
dig +trace example.com
# Short answer only
dig +short example.com
# Check all records for a domain
dig example.com ANY
# Reverse DNS lookup
dig -x 93.184.216.34
# nslookup (cross-platform, simpler output)
nslookup example.com
nslookup -type=MX example.com
nslookup example.com 1.1.1.1
# Check if DNS changes have propagated
# Compare answers from multiple resolvers
dig @8.8.8.8 example.com +short # Google
dig @1.1.1.1 example.com +short # Cloudflare
dig @9.9.9.9 example.com +short # Quad9;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34
│ │ │ │ └─ Value (IP address)
│ │ │ └─ Record type
│ │ └─ Class (IN = Internet)
│ └─ TTL in seconds (3600 = 1 hour)
└─ Domain name (FQDN with trailing dot)
;; Query time: 23 msec ← How long the lookup took
;; SERVER: 1.1.1.1#53 ← Which resolver answered
;; MSG SIZE rcvd: 56 ← Response packet sizeKey Takeaways
- • DNS is a hierarchical, cached system — understanding caching and TTLs is critical for managing domains
- • Use A/AAAA for IP mappings, CNAME for aliases (never at zone apex), and MX/TXT for email
- • Lower TTLs before DNS changes and raise them after — the most common source of "DNS is not propagating" issues is high TTLs
- • Use
dig +traceto debug resolution issues by following the full query path from root to authoritative server - • Always set up SPF, DKIM, and DMARC TXT records for any domain that sends email
- • Test against multiple public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9) to verify propagation