DNS in Architecture

DNS (Domain Name System) translates domain names to IP addresses.

DNS Resolution Process

1. Browser Cache
   Browser checks local DNS cache

2. OS Cache
   OS checks its DNS cache

3. Router Cache
   Router checks its DNS cache

4. ISP DNS
   ISP's DNS resolver

5. Root DNS Servers
   13 root server clusters (A-M)

6. TLD Servers
   .com, .org, .net servers

7. Authoritative DNS
   Domain's DNS server

Flow:
Browser → OS → Router → ISP → Root → TLD → Authoritative → IP

DNS Record Types

Record	Purpose	Example
A	IPv4 address	example.com → 93.184.216.34
AAAA	IPv6 address	example.com → 2606:2800:...
CNAME	Alias	www.example.com → example.com
MX	Mail server	example.com → mail.example.com
TXT	Text data	SPF, DKIM records
NS	Name servers	example.com → ns1.example.com
SRV	Service	_tcp.example.com

DNS Resolution Example

User types: www.example.com

1. Browser: Cache miss
2. OS: Cache miss
3. ISP DNS: Cache miss
4. Query Root: "Where is .com?" → TLD server
5. Query TLD: "Where is example.com?" → Authoritative
6. Query Authoritative: "What is www.example.com?" → 93.184.216.34
7. Response returned to browser
8. Browser connects to 93.184.216.34

DNS Caching

Cache Levels:

1. Browser Cache (minutes to hours)
2. OS Cache (minutes to hours)
3. Router Cache (minutes to hours)
4. ISP Cache (minutes to hours)
5. CDN Cache (varies)

Total DNS lookup time: 20-120ms

TTL (Time-To-Live) determines how long DNS records are cached.

TTL Impact

Low TTL (60 seconds):
+ Fast propagation of changes
+ Quick failover
- More DNS lookups
- Higher DNS costs

High TTL (24 hours):
+ Fewer DNS lookups
+ Lower DNS costs
- Slow propagation of changes
- Slow failover

TTL Configuration

; DNS Zone File
example.com.    300    IN    A    93.184.216.34
                 ↑
              TTL (300 seconds = 5 minutes)

Common TTL Values:
- 60s: Critical services (fast failover)
- 300s: Web applications
- 3600s: Stable infrastructure
- 86400s: Static content

TTL Strategy

Before Maintenance:
1. Lower TTL to 60s (wait for old TTL to expire)
2. Make changes
3. Increase TTL back to normal

Timeline:
T-24h: Lower TTL to 60s
T-1h: Wait for propagation
T-0: Make DNS changes
T+1h: Verify changes
T+2h: Increase TTL back to 300s

TTL and CDN

CDN TTL Strategy:

Static assets:
Cache-Control: max-age=31536000
CDN-Cache-Control: max-age=31536000

Dynamic content:
Cache-Control: max-age=0, must-revalidate
CDN-Cache-Control: max-age=60

TTL Best Practices

1. Set appropriate TTLs: Based on change frequency
2. Lower TTL before changes: Ensure propagation
3. Monitor TTL expiration: Track cache hits/misses
4. Use negative TTL: For failed lookups
5. Consider DNS providers: Some have minimum TTL limits

DNS can route users to the closest or most appropriate server based on location.

Geographic DNS

Geo-DNS Routing:

US users → US servers
EU users → EU servers
Asia users → Asia servers

Implementation:
- Route 53 Geolocation routing
- Cloudflare Load Balancing
- DNS providers with geo-routing

Geo-DNS Configuration

// AWS Route 53 Geolocation
{
  "Records": [
    {
      "Name": "example.com",
      "Type": "A",
      "GeoLocation": {
        "Continent": "NA"
      },
      "SetIdentifier": "US",
      "TTL": 300,
      "ResourceRecords": [{"Value": "1.2.3.4"}]
    },
    {
      "Name": "example.com",
      "Type": "A",
      "GeoLocation": {
        "Continent": "EU"
      },
      "SetIdentifier": "EU",
      "TTL": 300,
      "ResourceRecords": [{"Value": "5.6.7.8"}]
    }
  ]
}

Latency-Based Routing

Route users to lowest latency endpoint:

1. Measure latency to each endpoint
2. Route user to lowest latency

Example:
US East (50ms) ← US East users
US West (80ms) ← US West users
EU (30ms) ← EU users

Multi-Region Architecture

                    ┌─────────────┐
                    │  DNS (Geo)  │
                    └──────┬──────┘
           ┌───────────────┼───────────────┐
           │               │               │
    ┌──────▼──┐     ┌──────▼──┐     ┌──────▼──┐
    │US Region│     │EU Region│     │Asia Reg │
    └─────────┘     └─────────┘     └─────────┘

Each region:
- Full stack (app, DB, cache)
- Independent operation
- Data replication between regions

DNS Failover

Health-check based failover:

1. Primary server: 1.2.3.4 (healthy)
2. Secondary server: 5.6.7.8 (standby)
3. DNS monitors primary health
4. If primary fails → DNS returns secondary

Failover time:
- TTL: 60 seconds
- Health check interval: 30 seconds
- Total failover: ~90 seconds

DNS Best Practices

1. Use low TTLs for critical services: Fast failover
2. Implement geographic routing: Reduce latency
3. Configure health checks: Automatic failover
4. Use multiple DNS providers: Avoid single point of failure
5. Monitor DNS performance: Track resolution times