Global Load Balancing - Learning Module

Loading content...

0/273

GeoDNS

Location-Aware Traffic Routing

When a user in Frankfurt requests www.example.com, should they see the same IP address as a user in Sydney? For a static website, perhaps. But what if you need to serve European users from EU data centers for GDPR compliance? What if Australian users experience unacceptable latency when routed to European servers? What if you provide different content or pricing by region?

GeoDNS solves these challenges by returning different DNS responses based on the geographic location of the requesting client. It's the mechanism behind region-specific content delivery, regulatory compliance routing, and Netflix knowing to serve you different content catalogs in different countries.

Understanding GeoDNS is essential for architects designing systems with geographic requirements—whether for performance, compliance, or business localization.

What You Will Learn

By the end of this page, you will have mastered: how GeoDNS determines user location from IP addresses; the accuracy and limitations of IP geolocation databases; GeoDNS configuration patterns for common use cases; regulatory compliance routing (GDPR, data residency); performance optimization through geographic affinity; GeoDNS provider comparison and implementation approaches; and integration with health checks for resilient geographic routing.

How GeoDNS Works

GeoDNS extends standard DNS with location-based response selection. When a DNS query arrives at a GeoDNS-enabled authoritative server, the server determines the client's location and returns the IP address configured for that geographic region.

The GeoDNS Resolution Flow:

Query Reception: The GeoDNS server receives a DNS query. The source IP is either the recursive resolver's IP (traditional) or includes EDNS Client Subnet data (preferred).
Location Determination: The server looks up the source IP (or ECS subnet) in a geographic database to determine the client's approximate location—typically at country, region, or city granularity.
Policy Matching: The server evaluates configured geographic policies to find the matching rule for the determined location.
Response Selection: The server returns the IP address(es) configured for the matched geographic policy.
Scoped Caching: The response includes cache scope information so recursive resolvers can correctly cache responses per-subnet/region.

Converting Mermaid diagram...

IP Geolocation Databases:

The accuracy of GeoDNS depends entirely on IP geolocation database quality. These databases map IP address ranges to geographic locations based on multiple data sources:

GeoIP Data Sources

•Regional Internet Registry (RIR) Data — ARIN, RIPE, APNIC, LACNIC, and AFRINIC publish which organizations hold which IP blocks, often with location hints.
•ISP Registration Data — Internet Service Providers register address allocations, sometimes with geographic granularity.
•Latency Triangulation — Measuring round-trip times from known locations to determine approximate geographical position.
•User-Contributed Data — Services that know user locations (GPS, WiFi positioning) can correlate with IP addresses.
•Commercial Data Sources — Companies like MaxMind and Digital Element maintain proprietary enrichment data.

IP Geolocation Accuracy by Granularity
Granularity Level	Typical Accuracy	Confidence Level	Use Cases
Country	95-99%	Very High	Regulatory compliance, content licensing
Region/State	80-90%	High	Regional content, coarse load balancing
City	60-80%	Moderate	Local content, city-level targeting
Postal Code	40-60%	Low	Local advertising (use with caution)
Latitude/Longitude	Variable	Low-Moderate	Distance calculations (not precise location)

Geolocation Limitations

IP geolocation is inherently imprecise. VPN users appear in the VPN server's location. Mobile users may use IP addresses registered far from their current location. Satellite internet users (Starlink) may show surprising locations. Corporate users behind NAT may show headquarters location. Never assume geolocation is authoritative—it's a best-effort approximation.

GeoDNS Configuration Patterns

GeoDNS policies range from simple country-level routing to complex hierarchical configurations with fallbacks. Understanding common patterns helps architects design effective geographic routing.

Pattern 1: Continental/Regional Routing

The most common GeoDNS pattern routes users to the nearest regional data center based on continent or major geographic region.

geodns-regional.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# Continental GeoDNS Routing Configuration
geodns_policy:
  hostname: "api.example.com"
  type: "geolocation"
  
  regions:
    - name: "North America"
      countries: ["US", "CA", "MX"]
      answer: 
        - type: "A"
          value: "104.18.10.1"  # US-East data center
          
    - name: "South America"
      countries: ["BR", "AR", "CO", "CL", "PE", "VE", "EC", "UY", "PY", "BO"]
      answer:
        - type: "A"
          value: "104.18.20.1"  # São Paulo data center
          
    - name: "Europe"
      countries: ["GB", "DE", "FR", "IT", "ES", "NL", "PL", "SE", "AT", "CH", 
                  "BE", "IE", "PT", "CZ", "RO", "HU", "DK", "FI", "NO", "GR"]
      answer:
        - type: "A"
          value: "185.45.10.1"  # Frankfurt data center
          
    - name: "Asia Pacific"
      countries: ["JP", "KR", "AU", "SG", "IN", "ID", "PH", "TH", "VN", "MY", "NZ"]
      answer:
        - type: "A"
          value: "103.21.20.1"  # Singapore data center
          
    - name: "Middle East & Africa"
      countries: ["AE", "SA", "IL", "ZA", "EG", "NG", "KE"]
      answer:
        - type: "A"
          value: "185.45.10.1"  # Route to Europe (closest)
          
  default:
    # Fallback for unlisted countries
    answer:
      - type: "A"
        value: "104.18.10.1"  # US-East as global fallback
        
  ttl: 300  # 5 minute TTL for geolocation records

Pattern 2: Country-Specific Routing

For regulatory compliance or country-specific services, GeoDNS can route individual countries to dedicated infrastructure:

geodns-country-specific.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# Country-Specific GeoDNS for Regulatory Compliance
geodns_compliance:
  hostname: "app.example.com"
  type: "geolocation"
  
  # GDPR-compliant EU routing
  eu_countries:
    countries: ["AT", "BE", "BG", "HR", "CY", "CZ", "DK", "EE", "FI", 
                "FR", "DE", "GR", "HU", "IE", "IT", "LV", "LT", "LU",
                "MT", "NL", "PL", "PT", "RO", "SK", "SI", "ES", "SE"]
    answer:
      - type: "A"
        value: "185.45.100.1"  # EU-only infrastructure
    health_check:
      endpoint: "/health"
      interval: 30
      
  # China-specific routing (ICP licensing)
  china:
    countries: ["CN"]
    answer:
      - type: "A"
        value: "47.93.100.1"  # Chinese data center (licensed)
    fallback_behavior: "block"  # Don't route to non-licensed DC
    
  # Russia data localization law
  russia:
    countries: ["RU"]
    answer:
      - type: "A"
        value: "185.45.150.1"  # Russian data center
        
  # Brazil LGPD compliance
  brazil:
    countries: ["BR"]
    answer:
      - type: "A"
        value: "104.18.200.1"  # São Paulo data center
        
  # Default: Route to global infrastructure
  default:
    answer:
      - type: "A"
        value: "104.18.10.1"

Pattern 3: Hierarchical GeoDNS with Fallbacks

Complex deployments use hierarchical policies: try country-specific, fall back to regional, fall back to global. This ensures resilience when regional infrastructure fails:

geodns-hierarchical.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
# Hierarchical GeoDNS with Fallback Chain
geodns_hierarchical:
  hostname: "cdn.example.com"
  evaluation_order: ["country", "region", "continent", "global"]
  
  country_policies:
    - match: {country: "US", state: "CA"}
      primary: "104.18.10.1"   # Los Angeles PoP
      fallback: "104.18.11.1"  # US-West region
      
    - match: {country: "US", state: "NY"}
      primary: "104.18.20.1"   # New York PoP
      fallback: "104.18.21.1"  # US-East region
      
    - match: {country: "JP"}
      primary: "103.21.10.1"   # Tokyo PoP
      fallback: "103.21.11.1"  # APAC region
      
  region_policies:
    - match: {region: "US-West"}
      primary: "104.18.11.1"
      fallback: "104.18.21.1"  # US-East
      
    - match: {region: "US-East"}
      primary: "104.18.21.1"
      fallback: "104.18.11.1"  # US-West
      
    - match: {region: "EU"}
      primary: "185.45.10.1"
      fallback: "104.18.21.1"  # US-East as EU fallback
      
  continent_policies:
    - match: {continent: "NA"}
      primary: "104.18.21.1"
      
    - match: {continent: "EU"}
      primary: "185.45.10.1"
      
    - match: {continent: "AS"}
      primary: "103.21.11.1"
      
  global_fallback: "104.18.21.1"  # US-East as ultimate fallback
  
  health_integration:
    remove_unhealthy: true
    health_check_endpoint: "/healthz"

Design for Failure

Always define fallback behavior in GeoDNS configurations. When a regional data center fails, users shouldn't receive no response—they should be routed to the next-best option, even if suboptimal. Integrate health checks with GeoDNS to automatically remove unhealthy endpoints from geographic policies.

Regulatory Compliance Routing

One of the most critical applications of GeoDNS is regulatory compliance—ensuring that user data and requests are handled in accordance with geographic legal requirements. Data localization laws, privacy regulations, and content restrictions often mandate geographic routing controls.

Major Regulatory Frameworks Requiring Geographic Routing:

Regulatory Requirements for Geographic Routing
Regulation	Jurisdiction	Key Requirement	Routing Implication
GDPR	European Union	Data protection, data subject rights, transfer restrictions	Process EU user data within EU/EEA; restrict transfers to non-adequate countries
LGPD	Brazil	Brazilian personal data protection	Brazilian user data should be processed with LGPD-compliant systems
PIPL	China	Personal data localization, cross-border transfer restrictions	Process Chinese user data within China; special approval for transfers
Data Localization Law	Russia	Personal data of Russian citizens stored in Russia	Route Russian users to Russian data centers
PDPA	Thailand	Personal data protection and transfer restrictions	Consider Thailand-specific data handling
CCPA/CPRA	California, USA	Consumer privacy rights	May affect data handling but less routing-specific

Implementing Compliance Routing:

Compliance routing requires more than just directing traffic—it requires ensuring that the entire data processing chain respects geographic boundaries:

Compliance Routing Checklist

•Data Center Selection — Ensure destination data centers are within the required jurisdiction. EU traffic to EU data centers, Russian traffic to Russian data centers, etc.
•Data Processing Scope — The routed infrastructure must process data entirely within jurisdiction—no silent cross-border database replication or analytics pipelines.
•Fallback Behavior — When compliant infrastructure is unavailable, determine whether to fail open (route elsewhere) or fail closed (deny service). Regulatory requirements may mandate fail-closed.
•Audit Trail — Maintain logs demonstrating that geographic routing is functioning correctly. Regulators may request evidence of compliance.
•Third-Party Services — Ensure third-party services (CDNs, analytics, error tracking) also respect geographic boundaries. A compliant data center using a non-compliant CDN may still violate regulations.
•VPN/Proxy Detection — Consider whether to detect and handle VPN users appearing in incorrect jurisdictions. Business and legal teams should define policy.

gdpr-geodns-policy.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# GDPR-Compliant GeoDNS Configuration
gdpr_compliance:
  hostname: "app.example.eu"
  
  eu_members:
    # EU/EEA countries - route to EU infrastructure only
    countries: ["AT", "BE", "BG", "HR", "CY", "CZ", "DK", "EE", "FI", 
                "FR", "DE", "GR", "HU", "IE", "IT", "LV", "LT", "LU",
                "MT", "NL", "PL", "PT", "RO", "SK", "SI", "ES", "SE",
                # EEA countries
                "IS", "LI", "NO"]
    answer:
      - type: "A"
        value: "185.45.100.1"  # Frankfurt data center (EU-only)
      - type: "A"  
        value: "185.45.110.1"  # Dublin data center (EU-only backup)
    health_check:
      enabled: true
      failover: "intra-eu-only"  # Only failover to other EU DCs
      
  adequacy_countries:
    # Countries with EU adequacy decisions - can route to EU or local
    countries: ["GB", "CH", "JP", "KR", "AR", "NZ", "IL", "CA"]
    answer:
      - type: "A"
        value: "185.45.100.1"  # Route to EU for simplicity
        
  non_adequate_countries:
    # All other countries - route to non-EU infrastructure
    # Their data doesn't mix with EU user data
    default: true
    answer:
      - type: "A"
        value: "104.18.100.1"  # US data center (separate data silo)
        
  fallback_behavior:
    eu_users_if_eu_down: "503_service_unavailable"  # Fail closed for EU
    non_eu_users_if_us_down: "185.45.100.1"  # Can failover to EU
    
  monitoring:
    alert_on_cross_region_failover: true
    log_all_routing_decisions: true

Legal Advice Required

Geographic routing is a technical control, not a complete compliance solution. Regulations like GDPR involve much more than routing—including consent management, data subject rights, processor agreements, and more. Always work with legal counsel to ensure your geographic routing strategy meets actual regulatory requirements.

Performance Optimization with GeoDNS

Beyond compliance, GeoDNS is a powerful performance optimization tool. By routing users to nearby infrastructure, GeoDNS reduces latency, improves throughput, and enhances user experience. However, geographic proximity doesn't always equal network proximity.

The Proximity Fallacy:

Intuitively, we assume that the geographically closest server provides the lowest latency. This is often true, but network reality is more nuanced:

Submarine Cable Routing: A user in South Africa may have lower latency to London than to Lagos due to undersea cable routing.
Peering Arrangements: ISP peering points may create faster paths to distant data centers than nearby ones with poor peering.
Backbone Capacity: A nearby data center on a congested link may be slower than a distant one on a high-capacity backbone.
Last-Mile Quality: Local network infrastructure quality varies dramatically by region.

Latency Anomalies Where Geography Misleads
User Location	Geographic Closest DC	Actually Fastest DC	Reason
South Africa	Johannesburg	London	Submarine cables route via Europe; better peering to UK
Argentina	São Paulo	Miami	Better transit to US backbone than regional infrastructure
Australia (Perth)	Singapore	Sydney	Direct submarine cables to eastern Australia
India (South)	Mumbai	Singapore	Better undersea connectivity to Singapore than cross-India routes

Latency-Based GeoDNS:

Advanced GeoDNS implementations use actual latency measurements rather than geographic assumptions. These systems continuously measure round-trip times from various locations to each data center and route users based on measured performance:

latency-based-geodns.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
# Latency-Based GeoDNS Configuration (AWS Route 53 Example)
# Uses latency measurements rather than pure geography
 
resource "aws_route53_record" "api_latency_us_east" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 60
  
  latency_routing_policy {
    region = "us-east-1"
  }
  
  set_identifier  = "us-east-1"
  records         = ["104.18.10.1"]
  health_check_id = aws_route53_health_check.us_east.id
}
 
resource "aws_route53_record" "api_latency_eu_west" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 60
  
  latency_routing_policy {
    region = "eu-west-1"
  }
  
  set_identifier  = "eu-west-1"
  records         = ["185.45.10.1"]
  health_check_id = aws_route53_health_check.eu_west.id
}
 
resource "aws_route53_record" "api_latency_ap_northeast" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 60
  
  latency_routing_policy {
    region = "ap-northeast-1"
  }
  
  set_identifier  = "ap-northeast-1"
  records         = ["103.21.20.1"]
  health_check_id = aws_route53_health_check.ap_northeast.id
}
 
# Route 53 measures latency from resolver locations to each region
# Returns the record with the lowest measured latency for each query

Combining Geography and Latency:

Optimal configurations often combine geographic and latency-based routing:

Geographic Boundaries: Use pure GeoDNS for compliance (EU users must go to EU).
Latency Within Regions: Within compliant regions, use latency-based routing to select the fastest specific data center.
Health Integration: Automatically remove high-latency or unhealthy endpoints from consideration.

This layered approach respects hard requirements while optimizing within constraints.

Measure, Don't Assume

Deploy real-user monitoring (RUM) to measure actual latency experienced by users in each region. Use this data to validate and refine your GeoDNS policies. Geographic assumptions are starting points; measured data should drive ongoing optimization.

GeoDNS Providers and Implementation

Implementing GeoDNS requires selecting a DNS provider with geographic routing capabilities. Most modern cloud DNS services include GeoDNS features, while specialized providers offer advanced capabilities.

Major GeoDNS Providers:

GeoDNS Provider Comparison
Provider	Geo Capabilities	Latency Routing	Health Checks	Unique Features
AWS Route 53	Country, continent, state (US)	Yes (region-based)	Yes	Deep AWS integration; alias records
Cloudflare DNS	Country, continent (Enterprise)	Yes (load balancing add-on)	Yes	Anycast integration; Workers for custom logic
Google Cloud DNS	Limited (via Traffic Director)	Yes (with GCLB)	Via GCLB	Integrated with GCP load balancing
NS1	Country, region, city, ASN	Yes (Filter Chain)	Yes	Traffic management DSL; advanced policies
Dyn (Oracle)	Country, region	Yes	Yes	Enterprise focus; DDoS mitigation
Azure Traffic Manager	Country, region	Yes (performance)	Yes	Azure integration; DNS/non-DNS

Implementation Considerations:

GeoDNS Implementation Checklist

•GeoIP Database Quality — Evaluate provider's GeoIP database accuracy for your target regions. Some providers update more frequently than others. Enterprise providers often provide accuracy SLAs.
•EDNS Client Subnet Support — Ensure the provider supports ECS for improved accuracy when users use public resolvers. Without ECS, users on Google DNS or Cloudflare DNS may be misrouted.
•Health Check Integration — Verify that health checks can automatically remove unhealthy endpoints from geographic policies. Manual intervention during outages is operationally expensive.
•TTL Flexibility — Check minimum TTL limits. Some providers enforce minimums that may slow failover. For GeoDNS, 60-300 second TTLs are typical.
•Fallback Configuration — Ensure you can configure fallback behavior when regional infrastructure is unavailable. Some providers offer explicit fallback chains; others require manual configuration.
•Monitoring and Analytics — Evaluate query analytics to understand traffic distribution by geography. This data is essential for capacity planning and policy validation.

cloudflare-geodns.tf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
# Cloudflare GeoDNS with Load Balancing (Enterprise Feature)
 
resource "cloudflare_load_balancer" "api" {
  zone_id      = var.cloudflare_zone_id
  name         = "api.example.com"
  fallback_pool_id = cloudflare_load_balancer_pool.us_east.id
  
  # Geographic steering - route by region
  steering_policy = "geo"
  
  # Pop-specific pool mappings
  pop_pools {
    pop = "LAX"  # Los Angeles PoP
    pool_ids = [cloudflare_load_balancer_pool.us_west.id]
  }
  
  pop_pools {
    pop = "JFK"  # New York PoP
    pool_ids = [cloudflare_load_balancer_pool.us_east.id]
  }
  
  pop_pools {
    pop = "FRA"  # Frankfurt PoP
    pool_ids = [cloudflare_load_balancer_pool.eu_central.id]
  }
  
  pop_pools {
    pop = "NRT"  # Tokyo PoP
    pool_ids = [cloudflare_load_balancer_pool.ap_north.id]
  }
  
  # Regional pool mappings (for PoPs without explicit mapping)
  region_pools {
    region = "WNAM"  # Western North America
    pool_ids = [cloudflare_load_balancer_pool.us_west.id]
  }
  
  region_pools {
    region = "ENAM"  # Eastern North America
    pool_ids = [cloudflare_load_balancer_pool.us_east.id]
  }
  
  region_pools {
    region = "WEU"  # Western Europe
    pool_ids = [cloudflare_load_balancer_pool.eu_central.id]
  }
  
  region_pools {
    region = "SEAS"  # Southeast Asia
    pool_ids = [cloudflare_load_balancer_pool.ap_north.id]
  }
  
  proxied = true
}
 
resource "cloudflare_load_balancer_pool" "us_east" {
  name = "us-east-pool"
  
  origins {
    name    = "origin-1"
    address = "us-east-origin.example.com"
    enabled = true
  }
  
  notification_email = "ops@example.com"
  
  monitor = cloudflare_load_balancer_monitor.https.id
}
 
resource "cloudflare_load_balancer_monitor" "https" {
  type            = "https"
  expected_body   = "healthy"
  expected_codes  = "200"
  method          = "GET"
  timeout         = 5
  path            = "/health"
  interval        = 60
  retries         = 2
  follow_redirects = true
  allow_insecure  = false
}

Testing Geographic Routing

Test GeoDNS policies from multiple geographic locations before deploying to production. Use tools like 'dig' with specific resolver IPs, global DNS testing services (DNSChecker, WhatsMyDNS), or VPN services to simulate queries from different countries. Validate that routing matches your configured policies.

Advanced GeoDNS Patterns

Beyond basic geographic routing, advanced GeoDNS deployments implement sophisticated patterns for content differentiation, A/B testing, and multi-tenant architectures.

Pattern 1: Language/Content Localization

GeoDNS can route users to region-specific application instances serving localized content, pricing, and features:

localized-geodns.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# Localized Content GeoDNS
localization_routing:
  hostname: "store.example.com"
  
  regions:
    - name: "Japan (Japanese)"
      countries: ["JP"]
      target: "store-jp.example.internal"  # Japanese language, JPY pricing
      
    - name: "Germany (German)"
      countries: ["DE", "AT", "CH"]
      target: "store-de.example.internal"  # German language, EUR pricing
      
    - name: "Brazil (Portuguese)"
      countries: ["BR"]
      target: "store-br.example.internal"  # Portuguese, BRL pricing
      
    - name: "Canada (French)"
      regions: ["CA-QC"]  # Quebec only
      target: "store-ca-fr.example.internal"  # French Canadian
      
    - name: "Canada (English)"
      countries: ["CA"]  # Rest of Canada (after Quebec rule)
      target: "store-ca-en.example.internal"  # English Canadian
      
  default:
    target: "store-us.example.internal"  # English, USD pricing

Pattern 2: Geographic A/B Testing

Rolling out new features by geography allows controlled testing with regional user populations before global launch:

geo-ab-testing.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# Geographic A/B Testing Configuration
geo_ab_test:
  hostname: "app.example.com"
  experiment: "new-checkout-flow-v2"
  
  # Canary regions - get new version first
  canary_regions:
    - countries: ["NZ", "AU"]  # Australia/NZ often used as canary
      weight_new_version: 100
      target_new: "app-v2.example.internal"
      target_old: "app-v1.example.internal"
      
  # Gradual rollout regions
  rollout_regions:
    - countries: ["GB", "IE"]  # UK/Ireland - 50% rollout
      weight_new_version: 50
      target_new: "app-v2.example.internal"
      target_old: "app-v1.example.internal"
      
    - countries: ["US", "CA"]  # North America - 10% rollout
      weight_new_version: 10
      target_new: "app-v2.example.internal"
      target_old: "app-v1.example.internal"
      
  # Hold-out regions - stay on old version
  holdout_regions:
    - countries: ["DE", "FR", "JP"]  # Major markets - 0% yet
      weight_new_version: 0
      target_old: "app-v1.example.internal"
      
  metrics:
    track_by: ["region", "version"]
    conversion_events: ["checkout_complete", "signup"]

Pattern 3: Multi-Tenant Geographic Isolation

For SaaS platforms, GeoDNS can route different customer tenants to dedicated regional infrastructure for data isolation:

multi-tenant-geodns.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Multi-Tenant Regional Isolation
multi_tenant_routing:
  # Tenant-specific subdomains with regional routing
  
  # European enterprise customer - EU-only infrastructure
  acme-corp.app.example.com:
    restriction: "EU-only"
    countries: ["*"]  # All countries, but only EU destinations
    targets:
      primary: "eu-central.saas-infra.example.internal"
      secondary: "eu-west.saas-infra.example.internal"
    disallow_non_eu_failover: true
    
  # Japanese enterprise - Japan data residency
  nippon-inc.app.example.com:
    restriction: "Japan-only"
    countries: ["*"]
    targets:
      primary: "ap-northeast-1.saas-infra.example.internal"
    disallow_non_jp_failover: true
    
  # Global startup - follow-the-sun routing
  startup-xyz.app.example.com:
    restriction: "none"
    geo_routing:
      eu: "eu-central.saas-infra.example.internal"
      us: "us-east.saas-infra.example.internal"
      apac: "ap-southeast.saas-infra.example.internal"
    follow_the_sun: true  # Route to active support region

DNS Is Just the Routing Layer

Remember that GeoDNS provides routing, not access control. A user can still directly access any IP address. If you need to enforce geographic restrictions, implement validation at the application layer—GeoDNS should guide traffic, not secure it.

Summary: GeoDNS

GeoDNS is a powerful technique for location-aware traffic routing, enabling performance optimization, regulatory compliance, and regional service differentiation. Let's consolidate the key concepts:

Key Takeaways

•GeoDNS Routes by Location — Geographic DNS returns different IP addresses based on the geographic location of the requesting client, determined from IP geolocation databases.
•IP Geolocation Has Limitations — Country-level accuracy is high (95%+), but city-level accuracy degrades significantly. VPNs, mobile users, and corporate networks can cause misidentification.
•Regulatory Compliance is a Primary Use Case — GDPR, data localization laws, and content restrictions often require geographic routing to ensure data is processed in compliant jurisdictions.
•Geographic ≠ Network Proximity — The closest geographic data center may not be the lowest latency. Use latency-based routing when performance is the primary goal.
•Health Integration Is Essential — Combine GeoDNS with health checks to automatically remove unhealthy regional endpoints from routing. Manual failover is operationally expensive.
•Advanced Patterns Enable Sophisticated Use Cases — Geographic A/B testing, multi-tenant isolation, and localized content delivery are all enabled by GeoDNS.

What's Next:

With GeoDNS covered, we'll conclude this module with Traffic Management Policies—exploring comprehensive strategies for combining GSLB, DNS, Anycast, and GeoDNS into cohesive traffic management architectures that balance performance, availability, cost, and compliance.

Page Complete

You've mastered GeoDNS—from IP geolocation mechanics through compliance routing and advanced patterns. You understand how to design geographic routing for performance, regulatory compliance, and regional differentiation. Next, we'll bring together all traffic management concepts into comprehensive policies.