Day 6: DNS (Domain Name System)

What You'll Learn Today

How the DNS hierarchy is structured from root to authoritative servers
The most common DNS record types and when to use each
The difference between recursive and iterative DNS resolution
How caching and TTL work to speed up lookups
Practical tools like dig and nslookup, plus modern DNS security (DNSSEC, DoH, DoT)

Why DNS Matters

Every time you type a URL into your browser, a behind-the-scenes translation happens. Humans prefer names like www.example.com, but networks operate on IP addresses like 93.184.216.34. DNS is the system that bridges this gap. Without it, you would need to memorize IP addresses for every website you visit.

flowchart LR
    subgraph Before["Without DNS"]
        U1["User types\n93.184.216.34"]
    end
    subgraph After["With DNS"]
        U2["User types\nwww.example.com"]
        DNS["DNS resolves\nto 93.184.216.34"]
    end
    U2 --> DNS
    style Before fill:#ef4444,color:#fff
    style After fill:#22c55e,color:#fff

The DNS Hierarchy

DNS is organized as a hierarchical, distributed database. No single server holds all the records. Instead, responsibility is delegated through a tree structure.

flowchart TB
    subgraph Hierarchy["DNS Hierarchy"]
        ROOT["Root Servers\n(13 clusters worldwide)"]
        TLD["TLD Servers\n(.com, .org, .net, .jp)"]
        AUTH["Authoritative Servers\n(example.com, google.com)"]
        LOCAL["Recursive Resolver\n(Your ISP / 8.8.8.8)"]
    end
    LOCAL -->|"1. Query"| ROOT
    ROOT -->|"2. Refer to TLD"| TLD
    TLD -->|"3. Refer to authoritative"| AUTH
    AUTH -->|"4. Return IP"| LOCAL
    style ROOT fill:#ef4444,color:#fff
    style TLD fill:#f59e0b,color:#fff
    style AUTH fill:#3b82f6,color:#fff
    style LOCAL fill:#22c55e,color:#fff

Level	Role	Example
Root Servers	Entry point of every DNS query; directs to TLD servers	13 root server clusters (a.root-servers.net through m.root-servers.net)
TLD Servers	Manage top-level domains (.com, .org, .net, country codes)	Verisign operates .com TLD servers
Authoritative Servers	Hold the actual DNS records for a domain	ns1.example.com stores records for example.com
Recursive Resolver	Client-side server that walks the hierarchy on behalf of the user	Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1)

Root Servers

There are 13 root server identities (labeled A through M), but each is actually a cluster of hundreds of servers distributed globally using anycast routing. They don't store domain records directly. They simply know which TLD servers to ask next.

TLD Servers

TLD servers are responsible for entire top-level domains. There are three main categories.

TLD Category	Examples	Managed By
Generic (gTLD)	.com, .org, .net, .info	Various registries (e.g., Verisign for .com)
Country Code (ccTLD)	.jp, .uk, .de, .kr	National organizations
Sponsored (sTLD)	.edu, .gov, .mil	Sponsored by specific organizations

Authoritative Servers

These are the final source of truth. When you register a domain, you configure its authoritative DNS server (or use your registrar's default). This server holds the actual records that map names to IP addresses.

DNS Record Types

DNS supports many record types, each serving a specific purpose.

Record Type	Purpose	Example Value
A	Maps a domain to an IPv4 address	`example.com → 93.184.216.34`
AAAA	Maps a domain to an IPv6 address	`example.com → 2606:2800:220:1:...`
CNAME	Creates an alias pointing to another domain	`www.example.com → example.com`
MX	Specifies mail servers for the domain	`example.com → mail.example.com (priority 10)`
NS	Delegates a zone to authoritative name servers	`example.com → ns1.example.com`
TXT	Stores arbitrary text (SPF, DKIM, verification)	`"v=spf1 include:_spf.google.com ~all"`
SOA	Start of Authority; zone metadata	Serial number, refresh interval, admin email
PTR	Reverse DNS; maps IP to domain name	`34.216.184.93.in-addr.arpa → example.com`

A and AAAA Records

These are the most fundamental records. An A record maps a hostname to an IPv4 address. An AAAA record (pronounced "quad-A") does the same for IPv6.

example.com.    300    IN    A       93.184.216.34
example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

CNAME Records

A CNAME (Canonical Name) creates an alias. When a resolver encounters a CNAME, it follows the chain to the canonical name and then looks up the A/AAAA record for that name.

flowchart LR
    subgraph CNAME["CNAME Resolution"]
        WWW["www.example.com\n(CNAME)"]
        CANON["example.com\n(Canonical)"]
        IP["93.184.216.34\n(A Record)"]
    end
    WWW -->|"Points to"| CANON -->|"Resolves to"| IP
    style WWW fill:#8b5cf6,color:#fff
    style CANON fill:#3b82f6,color:#fff
    style IP fill:#22c55e,color:#fff

Important: A CNAME record cannot coexist with other record types for the same name. You cannot have both a CNAME and an MX record for example.com. This is why CNAME is typically used for subdomains like www.

MX Records

MX (Mail Exchange) records direct email traffic. They include a priority value; lower numbers mean higher priority.

example.com.    300    IN    MX    10    mail1.example.com.
example.com.    300    IN    MX    20    mail2.example.com.

If mail1 is unavailable, the sending server tries mail2.

TXT Records

TXT records are versatile. Common uses include:

Use Case	TXT Record Content
SPF (email authentication)	`"v=spf1 include:_spf.google.com ~all"`
DKIM (email signing)	`"v=DKIM1; k=rsa; p=MIGf..."`
Domain verification	`"google-site-verification=abc123..."`
DMARC (email policy)	`"v=DMARC1; p=reject; rua=mailto:..."`

SOA Records

The SOA (Start of Authority) record contains administrative information about a DNS zone.

example.com.  86400  IN  SOA  ns1.example.com. admin.example.com. (
    2024010101  ; Serial number
    3600        ; Refresh (1 hour)
    900         ; Retry (15 minutes)
    1209600     ; Expire (14 days)
    86400       ; Minimum TTL (1 day)
)

PTR Records

PTR (Pointer) records provide reverse DNS lookup, mapping an IP address back to a hostname. They use a special domain: in-addr.arpa for IPv4 and ip6.arpa for IPv6. The octets are reversed.

34.216.184.93.in-addr.arpa.    IN    PTR    example.com.

DNS Resolution Flow

When your browser needs to resolve a domain name, the process involves multiple steps and servers.

Recursive vs Iterative Resolution

Aspect	Recursive Resolution	Iterative Resolution
Who does the work	The recursive resolver does all the querying	Each server provides a referral; the client follows up
Client effort	Minimal; sends one query, gets final answer	Must make multiple queries
Used by	End-user devices querying their ISP resolver	Recursive resolvers querying authoritative servers
Analogy	Asking a librarian to find the book for you	The librarian tells you which shelf to check next

Full Resolution Walkthrough

Here is what happens when you type www.example.com in your browser for the first time.

sequenceDiagram
    participant Browser
    participant Stub as Stub Resolver<br/>(OS)
    participant Recursive as Recursive Resolver<br/>(ISP / 8.8.8.8)
    participant Root as Root Server
    participant TLD as .com TLD Server
    participant Auth as example.com<br/>Authoritative

    Browser->>Stub: Resolve www.example.com
    Stub->>Recursive: Query www.example.com
    Recursive->>Root: Query www.example.com
    Root->>Recursive: Referral → .com TLD servers
    Recursive->>TLD: Query www.example.com
    TLD->>Recursive: Referral → example.com NS
    Recursive->>Auth: Query www.example.com
    Auth->>Recursive: A 93.184.216.34
    Recursive->>Stub: A 93.184.216.34
    Stub->>Browser: 93.184.216.34

Step by step:

Browser cache: The browser checks its own DNS cache first
OS stub resolver: If not cached, the OS resolver checks its cache (and /etc/hosts)
Recursive resolver: The configured DNS server (e.g., 8.8.8.8) starts the resolution
Root server query: The recursive resolver asks a root server, which replies with a referral to .com TLD servers
TLD server query: The resolver asks the .com TLD server, which replies with the authoritative name servers for example.com
Authoritative query: The resolver asks the authoritative server, which returns the actual IP address
Response returned: The IP address flows back through the chain to the browser

Caching and TTL

DNS caching is essential for performance. Without it, every single web request would require multiple round trips across the internet.

Where Caching Happens

flowchart LR
    subgraph Caches["DNS Cache Locations"]
        BC["Browser Cache\n(Chrome: ~60s)"]
        OS["OS Cache\n(systemd-resolved)"]
        RR["Recursive Resolver\n(ISP cache)"]
    end
    BC --> OS --> RR
    style BC fill:#22c55e,color:#fff
    style OS fill:#3b82f6,color:#fff
    style RR fill:#8b5cf6,color:#fff

TTL (Time to Live)

Every DNS record includes a TTL value in seconds. This tells resolvers how long they may cache the record before re-querying.

TTL Value	Duration	Use Case
60	1 minute	During DNS migration or failover
300	5 minutes	Dynamic environments, CDNs
3600	1 hour	Standard websites
86400	1 day	Stable, rarely changing records

TTL Trade-offs

Short TTL (e.g., 60s)	Long TTL (e.g., 86400s)
Changes propagate quickly	Changes take longer to propagate
More DNS queries (higher load)	Fewer DNS queries (lower load)
Good for failover scenarios	Good for stable services

Tip: Before performing a DNS migration, lower the TTL to 60 seconds a few days in advance. After the migration is confirmed, raise it back to a longer value.

DNS Tools

dig

dig (Domain Information Groper) is the most powerful DNS query tool.

# Basic A record lookup
dig example.com

# Query specific record type
dig example.com MX
dig example.com AAAA
dig example.com TXT

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

# Short output
dig +short example.com

# Trace the full resolution path
dig +trace example.com

Example output of dig example.com:

; <<>> DiG 9.18.18 <<>> example.com
;; ANSWER SECTION:
example.com.        86400   IN  A   93.184.216.34

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; MSG SIZE  rcvd: 56

nslookup

nslookup is a simpler, cross-platform tool available on Windows, macOS, and Linux.

# Basic lookup
nslookup example.com

# Query specific server
nslookup example.com 8.8.8.8

# Query specific record type
nslookup -type=MX example.com

Tool	Strengths	Platform
`dig`	Detailed output, +trace, scriptable	Linux, macOS
`nslookup`	Simple syntax, widely available	Windows, Linux, macOS
`host`	Minimal output, quick checks	Linux, macOS

DNSSEC

Standard DNS has no built-in authentication. A malicious server could return a forged IP address, and the client would have no way to detect it. DNSSEC (DNS Security Extensions) solves this by adding cryptographic signatures to DNS records.

flowchart TB
    subgraph DNSSEC["DNSSEC Chain of Trust"]
        ROOT_KEY["Root Zone\n(Trust Anchor)"]
        TLD_KEY[".com Zone\n(DS + DNSKEY)"]
        AUTH_KEY["example.com Zone\n(DS + DNSKEY + RRSIG)"]
        RECORD["A Record\n(Signed with RRSIG)"]
    end
    ROOT_KEY -->|"Signs"| TLD_KEY
    TLD_KEY -->|"Signs"| AUTH_KEY
    AUTH_KEY -->|"Signs"| RECORD
    style ROOT_KEY fill:#ef4444,color:#fff
    style TLD_KEY fill:#f59e0b,color:#fff
    style AUTH_KEY fill:#3b82f6,color:#fff
    style RECORD fill:#22c55e,color:#fff

DNSSEC Record	Purpose
DNSKEY	Public key used to verify signatures
RRSIG	Signature over a set of DNS records
DS	Delegation Signer; links parent zone to child zone's key
NSEC/NSEC3	Proves a record does NOT exist (authenticated denial)

Verifying DNSSEC

# Check if a domain has DNSSEC
dig example.com +dnssec

# Look for the 'ad' (Authenticated Data) flag in the response
dig @8.8.8.8 example.com +dnssec +short

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

Traditional DNS queries are sent in plaintext over UDP port 53, which means anyone on the network path can see which domains you are resolving. DoH and DoT encrypt DNS queries.

Feature	Traditional DNS	DNS over TLS (DoT)	DNS over HTTPS (DoH)
Port	53 (UDP/TCP)	853 (TCP)	443 (TCP)
Encryption	None	TLS	HTTPS (TLS)
Visibility	Queries visible to ISP	Encrypted but identifiable as DNS	Blends with regular HTTPS traffic
Adoption	Universal	Moderate	Growing (browsers, OS)

flowchart LR
    subgraph Traditional["Traditional DNS"]
        C1["Client"] -->|"Plaintext\nPort 53"| S1["Resolver"]
    end
    subgraph DoT["DNS over TLS"]
        C2["Client"] -->|"TLS Encrypted\nPort 853"| S2["Resolver"]
    end
    subgraph DoH["DNS over HTTPS"]
        C3["Client"] -->|"HTTPS\nPort 443"| S3["Resolver"]
    end
    style Traditional fill:#ef4444,color:#fff
    style DoT fill:#f59e0b,color:#fff
    style DoH fill:#22c55e,color:#fff

Popular DoH/DoT Providers

Provider	DoH Endpoint	DoT Hostname
Cloudflare	`https://cloudflare-dns.com/dns-query`	`1dot1dot1dot1.cloudflare-dns.com`
Google	`https://dns.google/dns-query`	`dns.google`
Quad9	`https://dns.quad9.net/dns-query`	`dns.quad9.net`

Summary

Concept	Description
DNS Hierarchy	Root → TLD → Authoritative → Recursive resolver
A / AAAA Records	Map domain names to IPv4 / IPv6 addresses
CNAME	Alias that points one domain name to another
MX Record	Directs email to the correct mail server
NS Record	Delegates a zone to specific name servers
TXT Record	Stores arbitrary text (SPF, DKIM, verification)
SOA Record	Zone metadata (serial, refresh, expiry)
PTR Record	Reverse DNS; maps IP back to domain name
Recursive Resolution	Resolver does all the work on behalf of the client
TTL	Time a cached record remains valid
DNSSEC	Cryptographic signatures to authenticate DNS responses
DoH / DoT	Encrypted DNS queries over HTTPS or TLS

Key Takeaways

DNS is a hierarchical, distributed system; no single server knows everything
Understanding record types (A, AAAA, CNAME, MX, NS, TXT) is essential for configuring domains
TTL management is critical during DNS migrations and failover planning
dig is the most powerful tool for diagnosing DNS issues
DNSSEC adds authentication, while DoH/DoT add encryption to DNS

Practice Problems

Beginner

Use dig to look up the A record, MX record, and NS record for a domain of your choice. Identify the TTL for each record and explain what each record tells you.

Intermediate

You are migrating app.example.com from server A (10.0.0.1) to server B (10.0.0.2). The current TTL is 86400 seconds. Write a step-by-step migration plan that minimizes downtime, including when and how you would adjust the TTL.

Advanced

Design a DNS architecture for a global web application with the following requirements:

The application runs in 3 regions (US, Europe, Asia)
Users should be directed to the nearest region
If one region goes down, traffic should fail over to the remaining regions
Email must be handled by a separate mail service

Specify the record types, TTL values, and any additional DNS features you would use. Draw a diagram of the resolution flow.

References

Next up: In Day 7, we'll explore "HTTP & How the Web Works." You'll follow a URL from the address bar through DNS resolution, TCP connection, and HTTP request/response, and learn about the evolution from HTTP/1.1 to HTTP/3 with QUIC!