Skip to main content

Module 12: DNS Deep Dive

DNS (Domain Name System) is often called the “phonebook of the internet.” This module takes you from basic understanding to mastering DNS architecture, record types, troubleshooting, and security.
DNS Resolution Flow
Estimated Time: 4-5 hours
Difficulty: Intermediate
Prerequisites: Module 6 (Application Layer basics)

12.1 Why DNS Matters

Without DNS, you’d need to memorize IP addresses:
Instead of: google.com
You'd type: 142.250.190.46

Instead of: netflix.com  
You'd type: 54.237.226.164

Instead of: aws.amazon.com
You'd type: 54.239.28.85
DNS translates human-readable names to machine-readable IP addresses.

12.2 The DNS Hierarchy

DNS is a distributed hierarchical database, not a single server.
                           . (Root)

            ┌─────────────────┼─────────────────┐
            │                 │                 │
          .com              .org              .net
            │                 │                 │
     ┌──────┴──────┐    ┌────┴────┐      ┌────┴────┐
     │             │    │         │      │         │
  google       amazon  wikipedia  ...   cloudflare ...

  ┌──┴──┐
mail   www

DNS Components

ComponentRoleExample
Root ServersTop of hierarchy, point to TLDs13 root server clusters (a.root-servers.net)
TLD ServersHandle top-level domains.com, .org, .net, .io, .dev
Authoritative ServersHold actual DNS recordsns1.google.com
Recursive ResolversQuery on behalf of clients8.8.8.8 (Google), 1.1.1.1 (Cloudflare)

12.3 DNS Resolution Process

Step-by-Step: Resolving www.example.com

1

Browser Cache

Browser checks its local DNS cache.
Cache hit? → Return IP immediately
Cache miss? → Continue
2

OS Cache

Operating system checks its DNS cache.
# View DNS cache on Windows
ipconfig /displaydns

# Clear DNS cache
ipconfig /flushdns  # Windows
sudo dscacheutil -flushcache  # macOS
3

Recursive Resolver

Query is sent to configured DNS resolver (usually ISP’s or 8.8.8.8).
Your PC → "What's the IP of www.example.com?" → Resolver
4

Root Server Query

Resolver asks a root server:
Resolver → Root: "Where's www.example.com?"
Root → Resolver: "I don't know, but .com is handled by these servers..."
5

TLD Server Query

Resolver asks the .com TLD server:
Resolver → .com TLD: "Where's www.example.com?"
.com TLD → Resolver: "example.com is handled by ns1.example.com"
6

Authoritative Server Query

Resolver asks the authoritative server:
Resolver → ns1.example.com: "What's www.example.com?"
ns1.example.com → Resolver: "93.184.216.34"
7

Response to Client

Resolver caches the answer and returns it:
Resolver → Your PC: "www.example.com = 93.184.216.34"

Visual Flow

Your PC                    Resolver                  DNS Servers
   │                          │                          │
   │──"www.example.com?"─────►│                          │
   │                          │──"Where's .com?"────────►│ Root
   │                          │◄─"Try these TLD servers"─│
   │                          │                          │
   │                          │──"Where's example.com?"─►│ .com TLD
   │                          │◄─"ns1.example.com"───────│
   │                          │                          │
   │                          │──"www.example.com?"─────►│ Authoritative
   │                          │◄─"93.184.216.34"─────────│
   │                          │                          │
   │◄─"93.184.216.34"─────────│                          │
   │                          │                          │

12.4 DNS Record Types

Essential Records

RecordPurposeExample
AMaps name to IPv4www93.184.216.34
AAAAMaps name to IPv6www2606:2800:220:1:...
CNAMEAlias to another nameblogwww.example.com
MXMail server@mail.example.com (priority 10)
TXTText dataSPF, DKIM, domain verification
NSNameserver@ns1.example.com
SOAZone authoritySerial, refresh, retry info

Record Examples

; A Records - IPv4 addresses
example.com.        A       93.184.216.34
www.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, DKIM
example.com.        TXT     "v=spf1 include:_spf.google.com ~all"
example.com.        TXT     "google-site-verification=abc123..."

; NS - Nameservers for this domain
example.com.        NS      ns1.example.com.
example.com.        NS      ns2.example.com.

Advanced Records

RecordPurposeUse Case
SRVService location_sip._tcp.example.com → specific server:port
PTRReverse lookupIP → hostname (for reverse DNS)
CAACertificate Authority AuthWhich CAs can issue SSL certs
DNSKEY/DSDNSSECCryptographic verification

12.5 TTL (Time To Live)

TTL determines how long DNS records are cached.
www.example.com.    300     A     93.184.216.34

                 TTL in seconds (5 minutes)

TTL Trade-offs

Low TTL (e.g., 60s)High TTL (e.g., 86400s)
Fast propagation of changesSlower propagation
More DNS queriesFewer DNS queries
More load on DNS serversLess load
Good during migrationsGood for stable records

TTL Strategy for Migrations

Before migration:
1. Lower TTL to 60s (wait for old TTL to expire)
2. Make the change
3. Verify it works
4. Raise TTL back to normal (3600s or higher)

12.6 DNS Zones

A zone is a portion of the DNS namespace managed by a specific organization.

Zone File Example

$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.34
www     IN      A       93.184.216.34
mail    IN      A       93.184.216.35

; Mail
@       IN      MX      10 mail.example.com.

; CNAME
blog    IN      CNAME   www.example.com.

Zone Types

TypeDescription
Primary (Master)The authoritative source, editable
Secondary (Slave)Read-only copy, syncs from primary
ForwardName → IP resolution
ReverseIP → Name resolution

12.7 DNS Propagation

When you change DNS records, the change doesn’t happen instantly worldwide.

Why Propagation Takes Time

1. You update record on authoritative server
2. Old records still cached at:
   - Recursive resolvers worldwide
   - ISP DNS servers
   - Browser caches
   - OS caches
3. Each must wait for TTL to expire
4. Then they query again and get new record

Propagation Timeline

TTL = 3600 (1 hour)

0:00  - Record changed
0:01  - Users with fresh cache see new IP
0:30  - ~50% of caches expired, see new IP
1:00  - Most caches expired
1:30  - Stragglers with extended caching
2:00  - 99%+ should have new record

Checking Propagation

# Query specific DNS server
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# Check multiple locations
# Use: dnschecker.org, whatsmydns.net

12.8 DNS Query Types

Recursive vs Iterative

RECURSIVE (client → resolver):
Client: "Give me the final answer"
Resolver: Does all the work, returns final IP

ITERATIVE (resolver → authoritative):  
Resolver: "Where should I look next?"
Server: "Try this other server"
(Resolver follows the chain)

Query Tools

# nslookup (basic)
nslookup google.com

# dig (detailed)
dig google.com
dig google.com MX
dig +trace google.com  # Show full resolution path

# host (simple)
host google.com

dig Output Explained

$ dig example.com

; <<>> DiG 9.16.1 <<>> example.com
;; QUESTION SECTION:
;example.com.                   IN      A        ← What we asked

;; ANSWER SECTION:
example.com.            3600    IN      A      93.184.216.34
                         ↑                          ↑
                        TTL                        Answer

;; AUTHORITY SECTION:
example.com.            3600    IN      NS     ns1.example.com.

;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)  ← Resolver used
;; WHEN: Tue Jan 01 12:00:00 UTC 2024

12.9 Common DNS Configurations

Subdomain Setup

; Main site
@       IN      A       93.184.216.34
www     IN      A       93.184.216.34

; Subdomains pointing to different servers
api     IN      A       93.184.216.100
blog    IN      A       93.184.216.101
shop    IN      CNAME   shopify.com.

; Wildcard (matches anything)
*       IN      A       93.184.216.34

Load Balancing with DNS

; Round-robin (multiple A records)
www     IN      A       93.184.216.34
www     IN      A       93.184.216.35
www     IN      A       93.184.216.36

; Each query returns records in different order

Geographic DNS

Cloud providers offer geo-based DNS:
User in US → Route to us-east-1
User in EU → Route to eu-west-1
User in Asia → Route to ap-southeast-1

12.10 DNS Security

Common Attacks

DNS Spoofing

Attacker returns fake DNS responses, redirecting users to malicious sites.

DNS Cache Poisoning

Corrupting resolver cache to serve wrong IPs.

DNS Amplification DDoS

Using open resolvers to amplify attack traffic.

DNS Tunneling

Encoding data in DNS queries to bypass firewalls.

DNSSEC

DNS Security Extensions add cryptographic signatures to DNS records.
Zone signs records with private key

DS record in parent zone (chain of trust)

Resolvers verify signatures

Tampered records are rejected

DNS over HTTPS (DoH) / DNS over TLS (DoT)

Traditional DNS is unencrypted (port 53, plaintext).
ProtocolPortEncryptionPrivacy
DNS53NoneISP can see all queries
DoT853TLSQueries encrypted
DoH443HTTPSHidden in web traffic

12.11 Private DNS and Split-Horizon

Private DNS Zones

For internal resources not visible to the public:
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)

Split-Horizon DNS

Same domain returns different results based on where you query from:
External user → api.company.com → 203.0.113.50 (through load balancer)
Internal user → api.company.com → 10.0.1.100 (direct to server)

12.12 DNS Troubleshooting Checklist

# 1. Check if DNS returns any result
dig example.com

# 2. Check specific nameserver
dig @ns1.example.com example.com

# 3. Verify nameservers are correct
dig example.com NS

# 4. Check propagation
# Use whatsmydns.net
# 1. Check MX records
dig example.com MX

# 2. Verify MX target resolves
dig mail.example.com A

# 3. Check SPF record
dig example.com TXT

# 4. Check DKIM
dig selector._domainkey.example.com TXT
# 1. Check CAA records
dig example.com CAA

# 2. Verify domain validation records
dig _acme-challenge.example.com TXT

# 3. Check for CNAME issues (can block CAA lookup)
dig example.com CNAME

12.13 Key Takeaways

Hierarchy Matters

Root → TLD → Authoritative. Understand the chain.

TTL Controls Caching

Lower before changes, raise after for stability.

Records Have Purposes

A for IPv4, AAAA for IPv6, CNAME for aliases, MX for mail.

Propagation Takes Time

Changes spread globally based on TTL, not instantly.

Next Module

Module 13: Load Balancing & Proxies

Understand how traffic is distributed across servers and how proxies work.