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

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

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

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

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

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

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

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:

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:

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

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

# 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

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

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:

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

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!