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 |
The CAA record is what binds your zone to a specific certificate authority — see HTTPS and TLS explained for how CAs use it during issuance. For the IPv4/IPv6 addresses in A and AAAA values, the CIDR cheat sheet covers prefix notation and subnet boundaries.
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.
What Is DNSSEC?
DNSSEC (Domain Name System Security Extensions, RFC 4033) signs zone data with public-key cryptography so resolvers can detect tampering between the authoritative server and your client. Plain DNS has no integrity check — a man-in-the-middle or a poisoned cache can return an attacker-controlled IP and the resolver has no way to know. DNSSEC closes that gap by attaching signatures to every record set and chaining trust from the signed root zone down to your domain.
Three record types do the work. DNSKEY publishes the zone's public signing keys. RRSIG is the signature over each record set, produced with the matching private key. DS (Delegation Signer) lives at the parent zone (the registrar) and contains a hash of your DNSKEY — that's the link in the chain of trust. If any signature fails, a validating resolver returns SERVFAIL instead of the bad answer. Global adoption is still under 10% of domains per APNIC measurements, but most public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) validate by default.
# Show DNSSEC records and the AD (Authenticated Data) flag
dig +dnssec example.com
# Pull the DNSKEY set
dig DNSKEY example.com +short
# Pull the DS record from the parent (.com) zone
dig DS example.com +short
# Trace validation end-to-end
dig +trace +dnssec example.comWhat Are DoH and DoT?
Classic DNS runs on UDP port 53 in cleartext, so anyone on the network path can see your queries and rewrite the answers. DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858) encrypt that traffic. DoT uses a dedicated TLS connection on port 853 and is what most operating systems and home routers prefer because it looks like DNS to network operators. DoH wraps queries inside HTTPS on port 443, so they're indistinguishable from regular web traffic — that's why browsers default to it.
Public endpoints you can configure today: Cloudflare exposes DoH at https://cloudflare-dns.com/dns-query and DoT at 1.1.1.1:853; Google runs DoH at https://dns.google/dns-query and DoT at 8.8.8.8:853; Quad9 uses 9.9.9.9 on both. Firefox shipped DoH as the default for US users in 2020 and Chrome followed with auto-upgrade when the system resolver supports it.
For debugging, encrypted DNS hides queries from tcpdump and from captive-portal-style network tools. To bypass it temporarily, disable DoH in the browser (Firefox: about:preferences#privacy; Chrome: chrome://settings/security) and run dig against the system resolver so you see the raw UDP exchange.
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. If you do not have a terminal handy, the DNS lookup tool runs the same queries from a browser.
# 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 sizeReferences
- • RFC 1035 — Domain Names: Implementation and Specification (companion: RFC 1034 for concepts)
- • RFC 4033 — DNS Security Introduction and Requirements (DNSSEC)
- • RFC 8484 — DNS Queries over HTTPS (DoH)
- • RFC 7858 — Specification for DNS over TLS (DoT)
- • BIND 9 Administrator Reference Manual — authoritative reference for zone files, dig, and named.conf
- • Verisign Labs DNSSEC Debugger — paste a domain to see its full DNSSEC chain
- • InterNIC named.root — the canonical root server hints file
How Should You Manage DNS in Production?
- • 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
- • Enable DNSSEC at your registrar and DNS host — it is a one-click toggle on Cloudflare, Route 53, and most modern providers
- • Test against multiple public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9) to verify propagation