# DNS as a System(Part 8)

# GeoDNS

## Introduction

Imagine you're in Tokyo trying to stream a video from a service with servers in New York, London, and Tokyo. Would you want your traffic routed 6,000+ miles across the Pacific to New York? Or would you prefer the local Tokyo server, just kilometers away?

Traditional DNS often couldn't make this intelligent choice. **GeoDNS** changes that.

GeoDNS is an enhancement to standard DNS that routes requests based on:

*   **Geographical location** of the user
    
*   **Server health and capacity** status
    
*   **Network conditions** and performance
    
*   **Content availability** and caching status
    

The result: **Faster service, better reliability, optimized global performance**.

In this chapter, we explore how GeoDNS transforms DNS from a simple lookup system into an intelligent traffic manager.

## What is GeoDNS? {#what-is-geodns}

### Definition

**GeoDNS** (Geographic DNS) is an intelligent DNS routing system that:

*   Analyzes the origin location of DNS requests
    
*   Evaluates available servers and their status
    
*   Returns different DNS answers based on user location
    
*   Optimizes performance and reliability
    

### Simple Concept

```plaintext
Traditional DNS:
Query: Where is netflix.com?
Answer: Always 192.173.83.100

GeoDNS:
Query: Where is netflix.com? (from Tokyo)
Answer: 192.173.83.101 (Tokyo server)

Query: Where is netflix.com? (from London)
Answer: 192.173.83.102 (London server)

Query: Where is netflix.com? (from New York)
Answer: 192.173.83.103 (New York server)

Same domain, different answers based on location!
```

### Key Characteristics

| Aspect | Detail |
| --- | --- |
| **Dynamic** | Answers change based on request origin |
| **Location-Aware** | Uses geographic data to make decisions |
| **Health-Aware** | Considers server status and capacity |
| **Performance-Optimized** | Routes to nearest/best available server |
| **Transparent** | Users don't know it's happening |
| **Global** | Works worldwide across all regions |

## Traditional DNS Limitations {#limitations}

### The Problem

Standard DNS has a critical limitation: **it can't see where requests are coming from**.

### Why This Matters

```plaintext
Traditional DNS Flow:

User in Tokyo:
├─ Makes DNS query
├─ Query reaches ISP resolver (also in Tokyo)
├─ ISP resolver is cached, returns cached IP
└─ User gets: 192.173.83.100 (New York server)

User in London:
├─ Makes DNS query
├─ Query reaches ISP resolver (also in London)
├─ ISP resolver is cached, returns same cached IP
└─ User gets: 192.173.83.100 (New York server)

User in New York:
├─ Makes DNS query
├─ Query reaches ISP resolver (also in New York)
├─ ISP resolver is cached, returns same cached IP
└─ User gets: 192.173.83.100 (New York server)

Result: Everyone gets New York server!
├─ Tokyo user: 6,000+ miles away (200ms+ latency)
├─ London user: 3,500+ miles away (100ms+ latency)
├─ New York user: 0 miles away (10ms latency)

Problem: Inefficient routing, poor performance
```

### Root Cause

```plaintext
Why Traditional DNS Can't Optimize:

DNS Protocol Design (1987):
├─ Simple lookup: Domain → IP
├─ No location information
├─ No real-time status
├─ Returns same answer for everyone
└─ Designed for simpler internet

ISP Caching:
├─ Results cached at ISP level
├─ All users behind ISP get cached answer
├─ Resolver's location ≠ user's location
├─ Can't distinguish users
└─ Geographic data lost

Nameserver View:
├─ Nameserver only sees resolver IP
├─ Not the user's actual location
├─ User in Tokyo → Tokyo ISP resolver → NYC server
└─ Nameserver thinks request from ISP location
```

### Real-World Impact

```plaintext
Without GeoDNS:
├─ Tokyo users suffer high latency
├─ London users experience slowness
├─ Network congestion in certain regions
├─ Poor video streaming quality
├─ Higher server costs (centralized)
└─ Suboptimal user experience

With Traditional Setup:
├─ Company runs servers in multiple regions
├─ But can't direct traffic to nearest server
├─ Investment in infrastructure wasted
└─ Users still get poor performance
```

## GeoDNS Architecture {#architecture}

### Components

```plaintext
GeoDNS System:

┌─────────────────────────────────────┐
│  Client (User Device)               │
│  ├─ In different geographic region  │
│  └─ Makes DNS query                 │
└────────────────┬────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────┐
│  Resolver (ISP or Public DNS)       │
│  ├─ Receives query                  │
│  ├─ May forward to authoritative    │
│  └─ Caches results                  │
└────────────────┬────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────┐
│  GeoDNS Nameserver                  │
│  ├─ Receives query from resolver    │
│  ├─ Determines client subnet/location│
│  ├─ Checks server health status     │
│  ├─ Evaluates network conditions    │
│  └─ Returns optimized IP            │
└────────────────┬────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────┐
│  Multiple Regional Servers          │
│  ├─ Tokyo Server (192.173.83.101)  │
│  ├─ London Server (192.173.83.102) │
│  ├─ New York Server (192.173.83.103)│
│  └─ Sydney Server (192.173.83.104) │
└─────────────────────────────────────┘
```

### Decision Points

```plaintext
GeoDNS Makes Decisions Based On:

1. User Location
├─ Geographic origin of request
├─ Derived from IP address
├─ Determined via EDNS client subnet
└─ Helps find nearest server

2. Server Health
├─ Is server up and running?
├─ Current capacity utilization?
├─ Recent performance metrics?
├─ Network connectivity status?
└─ Skip unhealthy servers

3. Network Conditions
├─ Current latency to server
├─ Bandwidth utilization
├─ Congestion levels
├─ Packet loss rates
└─ Performance scoring

4. Content Availability
├─ What content is cached locally?
├─ Update frequency of content
├─ Licensing/regional restrictions
├─ Cache hit probability
└─ Performance optimization

Result: Optimal server selection
```

## How GeoDNS Works

### Step-by-Step Process

```plaintext
Query: Video user in Berlin wants to access Netflix

Step 1: User Makes Query
├─ User: "What's the IP for netflix.com?"
├─ Location: Berlin, Germany
├─ ISP: German telecom company
└─ Query reaches ISP resolver

Step 2: ISP Resolver Queries GeoDNS
├─ ISP resolver: "I have query from Berlin"
├─ Sends query to Netflix nameservers
├─ Includes EDNS client subnet info
│  └─ Client subnet: 91.123.0.0/24 (Berlin ISP)
└─ Query includes: Record type, TTL requirements

Step 3: GeoDNS Analyzes Request
├─ Parse EDNS client subnet
├─ Determine user location: "Berlin, Germany"
├─ Query location database
│  └─ Find nearest servers to Berlin
├─ Check server status
│  ├─ Amsterdam server: Healthy, 20% loaded
│  ├─ Frankfurt server: Healthy, 60% loaded
│  └─ Stockholm server: Down for maintenance
├─ Check current performance
│  ├─ Amsterdam: 5ms latency, excellent
│  ├─ Frankfurt: 8ms latency, good
│  └─ Stockholm: N/A (down)
└─ Select optimal server: Amsterdam

Step 4: GeoDNS Returns Answer
├─ Netflix nameserver selects IP
├─ IP for Amsterdam server: 192.173.83.150
├─ TTL: 300 seconds (relatively short)
├─ Response sent to ISP resolver
└─ ISP resolver caches response

Step 5: User Gets Answer
├─ ISP resolver returns to user
├─ Answer: netflix.com = 192.173.83.150
├─ User connects to Amsterdam server
├─ Low latency (5-10ms): Fast streaming!
└─ Optimal experience

Step 6: Different User, Different Answer
├─ New query from Tokyo user
├─ EDNS client subnet: 202.25.0.0/24 (Tokyo ISP)
├─ GeoDNS analysis: Tokyo location
├─ Selected server: Tokyo (nearest)
├─ IP returned: 192.173.83.151 (Tokyo server)
├─ Different answer for same domain!
└─ Tokyo user also gets optimal experience
```

## Client Subnet Extension (EDNS)

### The Problem It Solves

Without EDNS, GeoDNS is impossible:

```plaintext
Without EDNS Client Subnet:

Nameserver sees:
├─ Query for: netflix.com
├─ From: 8.8.8.8 (Google resolver)
├─ Problem: Google has resolvers worldwide
│  ├─ Same IP seen from Tokyo
│  ├─ Same IP seen from Berlin
│  ├─ Same IP seen from Sydney
│  └─ Nameserver can't tell them apart!
├─ Result: All users get same answer
└─ GeoDNS impossible without client location info
```

### The Solution: EDNS Client Subnet

**EDNS** (Extensions for DNS) is a DNS extension that includes optional fields in queries:

```plaintext
EDNS Client Subnet Field:

Purpose: Tell nameserver the user's location
Format: CIDR notation of client's subnet
Example: 91.123.0.0/24

How It Works:

ISP Resolver:
├─ Receives query from user in Berlin
├─ User IP: 91.123.45.123
├─ Creates EDNS field: 91.123.0.0/24
├─ Includes in DNS query
└─ "Query is from this subnet in Berlin"

Nameserver:
├─ Receives query with EDNS field
├─ Parses client subnet: 91.123.0.0/24
├─ Looks up location: "Berlin, Germany"
├─ Selects server: Amsterdam (nearest)
├─ Returns: Amsterdam IP
└─ User gets optimal routing!
```

### Historical Context

```plaintext
Why EDNS Was Possible:

Original DNS (1987):
├─ RFC 1035 designed protocol
├─ Limited message format
├─ Included unused bits for "future"
├─ Designers anticipated extensions
└─ Left room for enhancement

EDNS (1999):
├─ RFC 2671 introduced EDNS0
├─ Used previously reserved bits
├─ Backward compatible (still works)
├─ Optional (clients can ignore it)
├─ Optional (servers can ignore it)
└─ Perfect upgrade path

GeoDNS Enabled By:
├─ EDNS client subnet extension
├─ Added location information
├─ Optional field (backward compatible)
├─ Adoption growing (2010s+)
└─ Now supported by most providers
```

### EDNS in Dig Commands

```bash
# Query WITH EDNS client subnet
$ dig netflix.com +subnet=91.123.0.0/24

# Dig shows EDNS in output
; EDNS: version 0, flags:; udp: 4096
; OPT PSEUDOSECTION:
; COOKIE: XXXXXX (if supported)
; CLIENT-SUBNET: 91.123.0.0/24 ; scope PREFIX-LENGTH
```

## Content Delivery Networks (CDNs) {#cdns}

### What is a CDN?

A **Content Delivery Network (CDN)** is a network of geographically distributed servers that cache and serve content.

### CDN Concept

```plaintext
Without CDN (Centralized):
User in Tokyo
    │
    ├─ Want: Netflix video
    ├─ Stored: New York server
    └─ Route: Tokyo → New York (6000+ miles)

Result:
├─ High latency: 200-300ms
├─ Bandwidth expensive (transcontinental)
├─ Server overloaded
├─ Poor user experience
└─ Inefficient

With CDN (Distributed):
User in Tokyo
    │
    ├─ Want: Netflix video
    ├─ Cached: Tokyo edge server (10 miles away)
    ├─ Route: Tokyo → Tokyo (local)
    └─ Original: New York server (backup)

Result:
├─ Low latency: 5-10ms
├─ Bandwidth efficient (local)
├─ Server not overloaded
├─ Excellent user experience
└─ Efficient

Savings:
├─ 95% reduction in latency
├─ 99% reduction in backbone traffic
├─ Better scalability
└─ Much better user experience
```

### CDN + GeoDNS Partnership

```plaintext
How CDNs Use GeoDNS:

1. CDN Deploys Servers Globally
├─ Netflix Edge servers in major cities
├─ Tokyo, Bangkok, Sydney (Asia)
├─ London, Frankfurt, Amsterdam (Europe)
├─ New York, Los Angeles (North America)
├─ São Paulo, Mexico City (Latin America)
└─ 200+ edge locations worldwide

2. Content Cached Locally
├─ Popular content replicated to all edges
├─ User downloads locally
├─ Backbone traffic minimal
├─ Cost efficient

3. GeoDNS Routes Intelligently
├─ User query: "netflix.com"
├─ GeoDNS: "You're in Tokyo"
├─ Returns: Tokyo edge server IP
├─ User gets nearest server
└─ Low latency + cached content

4. User Experience
├─ Fast streaming (cached content)
├─ Low latency (geographic proximity)
├─ Reliable (multiple edge locations)
└─ Scalable (load distributed)

Major CDNs Using GeoDNS:
├─ Akamai (world's largest CDN)
├─ Cloudflare
├─ Fastly
├─ CloudFront (Amazon)
├─ Azure CDN (Microsoft)
└─ Dozens more
```

## Real-World Example: Netflix {#netflix-example}

### Netflix's GeoDNS Strategy

Netflix operates one of the world's most sophisticated GeoDNS systems:

```plaintext
Netflix Global Infrastructure:

Network Topology:
├─ Streaming servers (Open Connect)
├─ In 200+ ISPs and network operators
├─ Distributed across continents
├─ Multiple servers per location
└─ 1000+ edge caches

Netflix Geographic Zones:

North America:
├─ New York (primary east)
├─ Los Angeles (primary west)
├─ Toronto (Canada)
├─ Mexico City
├─ São Paulo (Brazil)
└─ ... multiple more

Europe:
├─ London (UK/Ireland hub)
├─ Amsterdam (Europe hub)
├─ Frankfurt (Central Europe)
├─ Paris
├─ Stockholm (Nordic region)
├─ ... multiple more

Asia-Pacific:
├─ Tokyo (Japan)
├─ Bangkok (Southeast Asia)
├─ Singapore (Southeast Asia hub)
├─ Sydney (Australia)
├─ Mumbai (India)
├─ Seoul (Korea)
└─ ... multiple more
```

### GeoDNS in Action

```plaintext
User in Stockholm Wants to Stream:

Query: What's netflix.com?

1. User's ISP in Stockholm creates query
2. Includes EDNS client subnet (Swedish ISP range)
3. Netflix's GeoDNS nameserver receives query

4. GeoDNS Analysis:
   ├─ Client subnet location: Stockholm, Sweden
   ├─ Nearest servers: Stockholm, Amsterdam, Frankfurt
   ├─ Check Stockholm server:
   │  ├─ Status: Operational
   │  ├─ CPU: 45% utilized
   │  ├─ Latency: 2ms
   │  ├─ Content: Fully cached
   │  └─ Result: Excellent option!
   ├─ Check Amsterdam:
   │  ├─ Status: Operational
   │  ├─ CPU: 75% utilized
   │  ├─ Latency: 15ms
   │  └─ Result: Secondary option
   ├─ Check Frankfurt:
   │  ├─ Status: Operational
   │  ├─ CPU: 80% utilized
   │  └─ Result: Tertiary option

5. GeoDNS Decision:
   └─ Select Stockholm server (nearest, best health)

6. Response:
   ├─ netflix.com = 192.173.83.120 (Stockholm)
   ├─ TTL: 300 seconds
   └─ User gets answer

7. User Experience:
   ├─ Connects to Stockholm server
   ├─ Latency: ~2ms (excellent!)
   ├─ Content cached locally
   ├─ Streaming starts immediately
   ├─ 4K quality available
   └─ User: Seamless streaming

Next User (Different Location):

User in Madrid, Spain wants to stream:

Query: What's netflix.com?

1. User's ISP in Madrid creates query
2. EDNS client subnet (Spanish ISP range)

3. GeoDNS Analysis:
   ├─ Client location: Madrid, Spain
   ├─ Nearest: Amsterdam (closer than Stockholm)
   ├─ Check Amsterdam:
   │  └─ Status: Good, 60% CPU
   ├─ Result: Select Amsterdam

4. Response:
   ├─ netflix.com = 192.173.83.102 (Amsterdam)
   └─ Different IP than Stockholm user!

5. User Experience:
   ├─ Connects to Amsterdam server
   ├─ Latency: ~15ms (good)
   ├─ Streaming quality: Excellent
   └─ Different answer than Swedish user

Summary:
├─ Same domain: netflix.com
├─ Different answers based on location
├─ Optimized for each user
├─ Both users get excellent performance
└─ This is GeoDNS in action!
```