DNS (Domain Name System) is often called the “phonebook of the internet,” but it is more accurately the internet’s distributed directory service. Unlike a phonebook (which is a single, static document), DNS is a globally distributed, hierarchical, real-time database that handles trillions of queries per day. This module takes you from basic understanding to mastering DNS architecture, record types, troubleshooting, and security.A better analogy: DNS is like the information desk network at a large airport. You ask the first desk “Where is Gate B42?” They do not know, but they say “Go to Terminal B information.” Terminal B information says “Gate B42 is in Concourse B-East, ask the desk there.” The Concourse B-East desk finally tells you “Gate B42 is down the hall, third on the left.” Each desk only knows about its own area, but by following the chain, you get your answer. And crucially, you remember the answer for next time (caching) so you do not have to ask again.
; A Records - IPv4 addressesexample.com. A 93.184.216.34www.example.com. A 93.184.216.34; AAAA Record - IPv6 address www.example.com. AAAA 2606:2800:220:1:248:1893:25c8:1946; CNAME - Alias (cannot coexist with other records for same name)blog.example.com. CNAME www.example.com.; MX - Mail servers (lower number = higher priority)example.com. MX 10 mail1.example.com.example.com. MX 20 mail2.example.com.; TXT - Verification, SPF, DKIMexample.com. TXT "v=spf1 include:_spf.google.com ~all"example.com. TXT "google-site-verification=abc123..."; NS - Nameservers for this domainexample.com. NS ns1.example.com.example.com. NS ns2.example.com.
This is one of the most important operational patterns in DNS management. Getting it wrong can cause hours of downtime.
Step 1: Days before migration - Lower TTL from 3600s to 60s - WAIT for the old TTL to fully expire (at least 3600s = 1 hour) - This ensures all caches worldwide will refresh within 60 secondsStep 2: Make the change - Update the DNS record to point to the new IPStep 3: Verify it works - Check from multiple locations: dig @8.8.8.8, dig @1.1.1.1 - Use whatsmydns.net to verify global propagation - Test the application at the new IPStep 4: After migration is confirmed stable - Raise TTL back to normal (3600s or higher) - Higher TTL = fewer DNS queries = faster resolution for users
The classic mistake: Changing the DNS record without lowering the TTL first. If the TTL was 86400 seconds (24 hours), some users will continue hitting the old IP for up to 24 hours after the change, regardless of what you do. There is no way to force a cache flush on every resolver worldwide. The only defense is to lower the TTL before the migration and wait for the old TTL to expire.
$TTL 86400@ IN SOA ns1.example.com. admin.example.com. ( 2024010101 ; Serial 7200 ; Refresh (2 hours) 3600 ; Retry (1 hour) 1209600 ; Expire (2 weeks) 86400 ; Minimum TTL (1 day)); Nameservers@ IN NS ns1.example.com.@ IN NS ns2.example.com.; A Records@ IN A 93.184.216.34www IN A 93.184.216.34mail IN A 93.184.216.35; Mail@ IN MX 10 mail.example.com.; CNAMEblog IN CNAME www.example.com.
1. You update record on authoritative server2. Old records still cached at: - Recursive resolvers worldwide - ISP DNS servers - Browser caches - OS caches3. Each must wait for TTL to expire4. Then they query again and get new record
TTL = 3600 (1 hour)0:00 - Record changed0:01 - Users with fresh cache see new IP0:30 - ~50% of caches expired, see new IP1:00 - Most caches expired1:30 - Stragglers with extended caching2:00 - 99%+ should have new record
RECURSIVE (client → resolver):Client: "Give me the final answer"Resolver: Does all the work, returns final IPITERATIVE (resolver → authoritative): Resolver: "Where should I look next?"Server: "Try this other server"(Resolver follows the chain)
; Main site@ IN A 93.184.216.34www IN A 93.184.216.34; Subdomains pointing to different serversapi IN A 93.184.216.100blog IN A 93.184.216.101shop IN CNAME shopify.com.; Wildcard (matches anything)* IN A 93.184.216.34
Traditional DNS is unencrypted (port 53, plaintext). This means anyone between you and the DNS resolver — your ISP, a coffee shop Wi-Fi operator, or a MITM attacker — can see exactly which domains you are querying. It is like asking for directions by shouting across a crowded room — everyone hears where you are trying to go.
Traditional DNS (port 53, unencrypted): Your PC -> Resolver (8.8.8.8): Query: A record for secretproject.company.com [Visible to anyone capturing packets on the network]DNS over HTTPS (port 443, encrypted): Your PC -> Resolver (1.1.1.1): [Encrypted HTTPS traffic -- looks identical to any web browsing] [Snooper sees traffic to 1.1.1.1:443 but cannot read the query]
Troubleshooting DNS at the packet level: When DNS issues are subtle (intermittent failures, slow resolution), tcpdump or Wireshark are your best friends. Capture DNS traffic with sudo tcpdump -i eth0 port 53 -w dns-capture.pcap. In Wireshark, filter by dns and look for: (1) queries with no response (the resolver or authoritative server might be unreachable), (2) responses with NXDOMAIN status (the domain does not exist — typo in the record?), (3) responses with SERVFAIL (the authoritative server has a configuration problem), or (4) unusually high query times (the resolver is overloaded or the network path is congested).
Public DNS (internet):app.company.com → 203.0.113.50 (public IP)Private DNS (internal): app.company.com → 10.0.1.100 (private IP)db.company.com → 10.0.2.50 (no public record)
# 1. Check if DNS returns any resultdig example.com# 2. Check specific nameserverdig @ns1.example.com example.com# 3. Verify nameservers are correctdig example.com NS# 4. Check propagation# Use whatsmydns.net
