How DNS Resolution Works
When you type example.com into a browser, a chain of lookups begins. Your machine doesn't know the IP address, so it asks a recursive resolver (usually run by your ISP or a public provider like 8.8.8.8). The resolver then walks the DNS hierarchy on your behalf.
Step by Step
1. Local cache check — The OS checks its own DNS cache and the /etc/hosts file before making any network request.
2. Recursive resolver — If not cached, the stub resolver sends a query to the configured recursive resolver. This server does the heavy lifting.
3. Root servers — The resolver asks a root server "where is .com?" The root responds with the address of the TLD nameservers for .com.
4. TLD nameservers — The resolver asks the .com TLD server "where is example.com?" and gets back the authoritative nameservers for that domain.
5. Authoritative nameserver — The resolver queries the authoritative NS, which returns the actual A/AAAA record with the IP address.
Caching and TTL
Every DNS record has a TTL (Time to Live) value in seconds. The resolver caches the answer for that duration. Typical TTLs range from 300s (5 min) to 86400s (24 hours). Lower TTLs mean faster propagation of changes but higher query load on authoritative servers.
DNS Record Types
DNS stores far more than just IP addresses. Each record type serves a specific purpose in the ecosystem.
| Type | Purpose | Example Value |
|---|---|---|
A | Maps domain to IPv4 address | 93.184.216.34 |
AAAA | Maps domain to IPv6 address | 2606:2800:220:1:: |
CNAME | Alias pointing to another domain | www.example.com → example.com |
MX | Mail server for the domain (with priority) | 10 mail.example.com |
TXT | Arbitrary text (SPF, DKIM, DMARC, verification) | v=spf1 include:_spf.google.com ~all |
NS | Authoritative nameservers for a zone | ns1.example.com |
SOA | Start of Authority — zone metadata, serial number | ns1.example.com admin.example.com 2024010101 |
SRV | Service location (port, priority, weight) | _sip._tcp 10 60 5060 sip.example.com |
PTR | Reverse DNS — IP to domain name | 34.216.184.93.in-addr.arpa → example.com |
CAA | Certificate Authority Authorization — which CAs can issue certs | 0 issue "letsencrypt.org" |
TXT Records for Email Security
SPF (Sender Policy Framework) declares which mail servers are allowed to send email for your domain. DKIM (DomainKeys Identified Mail) publishes a public key that recipients use to verify email signatures. DMARC ties SPF and DKIM together with a policy for handling failures.
# SPF record
v=spf1 include:_spf.google.com ~all
# DKIM record (selector: google)
google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."
# DMARC record
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:reports@example.com"example.com) if you also need MX or TXT records there. Many DNS providers offer "ALIAS" or "ANAME" as a workaround.
DNS Infrastructure
The DNS ecosystem is built on distinct server roles and clever networking techniques that keep it fast and resilient.
Holds the actual DNS records for a zone. It's the source of truth. Returns answers with the "aa" (authoritative answer) flag set.
Does the work of walking the hierarchy on behalf of clients. Caches results. Examples: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), your ISP's resolver.
13 logical root server clusters (A through M), operated by different organizations. They use anycast so each "server" is actually hundreds of instances worldwide.
Multiple servers share the same IP address. BGP routing sends each query to the nearest instance. This is how root servers and CDN DNS handle global traffic with low latency.
Advanced DNS Features
DNS Load Balancing
DNS can distribute traffic by returning multiple A records (round-robin) or by using weighted responses. The client typically uses the first IP returned. More sophisticated setups use health checks and geographic routing at the DNS level (GeoDNS).
# Multiple A records for round-robin
example.com. 300 IN A 192.0.2.1
example.com. 300 IN A 192.0.2.2
example.com. 300 IN A 192.0.2.3Split-Horizon DNS
Returns different answers depending on who is asking. Internal users on the corporate network get private IPs pointing to internal servers, while external users get public IPs. This is common in enterprise environments and is implemented by configuring DNS views based on the source IP of the query.
_web._tcp.service.consul). This avoids hardcoding IPs and makes infrastructure dynamic.
DNS Security
DNS was designed in the 1980s without authentication or encryption. Several extensions have been added to address this.
| Mechanism | What It Does | Layer |
|---|---|---|
| DNSSEC | Adds cryptographic signatures to DNS responses. Resolvers can verify that records haven't been tampered with. Uses a chain of trust from root to zone. | Data integrity |
| DoH (DNS over HTTPS) | Encrypts DNS queries inside HTTPS. Prevents ISPs and middleboxes from seeing or modifying queries. Runs on port 443. | Transport encryption |
| DoT (DNS over TLS) | Encrypts DNS queries with TLS on a dedicated port (853). Easier for network admins to manage than DoH since it uses a distinct port. | Transport encryption |
DNS Amplification Attacks
An attacker sends DNS queries with a spoofed source IP (the victim's IP) to open resolvers. The resolver sends the (much larger) response to the victim. Because DNS responses can be 50-70x larger than queries (especially with DNSSEC or ANY queries), this amplifies the attack traffic massively.
ANY queries to reduce amplification factor.
Operational Practices
DNS Propagation
When you change a DNS record, the old value may remain in caches worldwide until its TTL expires. "Propagation" is just caches expiring at different times. There's no push mechanism — each resolver refreshes independently.
Low TTL for Migrations
Before a migration (changing hosting provider, IP address, etc.), lower the TTL to 60-300 seconds a few days in advance. This ensures that when you flip the record, caches expire quickly and traffic moves to the new destination. After the migration stabilizes, raise the TTL back up to reduce query load.
# Days before migration: lower TTL
example.com. 300 IN A old-ip
# Migration day: flip the record
example.com. 300 IN A new-ip
# After stabilization: raise TTL
example.com. 86400 IN A new-ipUseful Diagnostic Commands
# Query specific record type
dig example.com A
dig example.com MX +short
# Trace the full resolution path
dig +trace example.com
# Query a specific nameserver
dig @8.8.8.8 example.com
# Reverse DNS lookup
dig -x 93.184.216.34
# Check DNSSEC
dig +dnssec example.comdig +trace to see every step of the resolution process from root to authoritative. It bypasses your local cache and shows you exactly what the hierarchy returns at each level.
Test Yourself
in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones.