GeoDNS and DNS Failover: Ensuring Website Availability Worldwide

Why Website Availability Matters for International Audiences

When your website serves users across multiple continents, every millisecond counts. Studies by Google show that a 100ms increase in page load time can reduce conversion rates by up to 7%. For an e-commerce site generating €100,000 per month, that translates to €7,000 in lost revenue — every single month.

But latency is only part of the equation. What happens when your primary server goes down? Without proper failover mechanisms, your entire international audience loses access simultaneously. For businesses operating across time zones, downtime at 3 AM in Paris means peak-hour outage in Tokyo.

This is where GeoDNS and DNS failover come into play — two complementary technologies that form the backbone of any serious international web infrastructure.

Understanding GeoDNS: Routing Users to the Nearest Server

How GeoDNS Works

Traditional DNS resolves a domain name to a single IP address regardless of where the request originates. GeoDNS (Geographic DNS) takes a smarter approach: it analyzes the geographic location of the requesting resolver and returns different IP addresses based on that location.

Here’s a simplified flow:

1. A user in Sydney types your domain into their browser
2. Their ISP’s DNS resolver sends a query to your authoritative nameserver
3. The GeoDNS server identifies the resolver’s IP as Australian
4. It returns the IP address of your server in the Asia-Pacific region
5. The user connects to a nearby server with minimal latency

Meanwhile, a user in Berlin performing the same request gets directed to your European server.

Real-World Latency Improvements

The impact of GeoDNS on user experience is substantial. Consider these typical latency figures:

User Location	Single Server (US East)	With GeoDNS (Regional)	Improvement
New York	20ms	20ms	—
London	85ms	15ms	82%
Tokyo	180ms	25ms	86%
Sydney	220ms	30ms	86%
São Paulo	140ms	22ms	84%

These figures represent network round-trip time only. When you factor in multiple resource requests per page load (CSS, JavaScript, images, API calls), the cumulative improvement becomes dramatic.

GeoDNS Configuration Example

Here’s a practical example using BIND with the GeoIP module, one of the most common open-source implementations:

; Zone file with GeoDNS views

; View for European users
view "europe" {
  match-clients { geoip_country_EU; };
  zone "example.com" {
    type master;
    file "zones/example.com.europe";
  };
};

; View for Asia-Pacific users
view "asia" {
  match-clients { geoip_country_AS; geoip_country_OC; };
  zone "example.com" {
    type master;
    file "zones/example.com.asia";
  };
};

; View for North American users (default)
view "namerica" {
  match-clients { any; };
  zone "example.com" {
    type master;
    file "zones/example.com.namerica";
  };
};

Each zone file points to the regional server’s IP address, ensuring users are automatically routed to the closest infrastructure.

For managed solutions, AWS Route 53 offers geolocation routing policies that accomplish the same result without managing your own nameservers — something our team at Lueur Externe frequently implements as certified AWS Solutions Architects.

DNS Failover: Your Safety Net Against Downtime

The Problem with Single Points of Failure

Even the most reliable servers experience downtime. Hardware failures, software bugs, DDoS attacks, data center power outages — the list of potential failures is long. According to Gartner, the average cost of IT downtime is $5,600 per minute for enterprise businesses.

DNS failover solves this by continuously monitoring your servers’ health and automatically updating DNS records to redirect traffic away from failed servers.

How DNS Failover Works

1. Health checks: Monitoring agents periodically send requests to your servers (HTTP, HTTPS, TCP, or ICMP)
2. Failure detection: If a server fails to respond within a defined threshold (e.g., 3 consecutive checks), it’s marked as unhealthy
3. Record update: The DNS system automatically removes the failed server’s IP from responses
4. Traffic redirection: New DNS queries receive only healthy server IPs
5. Recovery: When the server comes back online and passes health checks, it’s re-added to the rotation

TTL: The Critical Factor

The effectiveness of DNS failover depends heavily on your TTL (Time to Live) settings. TTL tells DNS resolvers how long to cache a response before querying again.

• High TTL (3600s / 1 hour): Less DNS traffic, but failover takes up to an hour to propagate
• Low TTL (60s / 1 minute): Faster failover, but more DNS queries and slightly higher resolution latency
• Recommended for failover (300s / 5 minutes): A practical balance between speed and efficiency

For mission-critical applications, a TTL of 60 seconds is often justified despite the increased DNS query volume.

Combining GeoDNS with DNS Failover: The Ultimate Setup

Architecture Overview

The most robust international infrastructure combines both technologies:

• GeoDNS handles the geographic routing during normal operations
• DNS failover kicks in when a regional server fails, redirecting traffic to the next closest healthy server

Here’s what this looks like in practice:

User in France → GeoDNS → EU Server (Paris)
                              ↓ (if down)
                         Failover → EU Server (Frankfurt)
                              ↓ (if down)
                         Failover → US Server (New York)

User in Japan → GeoDNS → APAC Server (Tokyo)
                              ↓ (if down)
                         Failover → APAC Server (Singapore)
                              ↓ (if down)
                         Failover → US Server (Los Angeles)

This layered approach ensures that:

• Users always get the fastest possible response
• No single server failure causes a complete outage
• Degradation is graceful — users might experience slightly higher latency during failover, but never a complete blackout

AWS Route 53 Implementation

For clients using AWS infrastructure, here’s how we typically configure this at Lueur Externe using Route 53 routing policies:

{
  "Type": "A",
  "Name": "www.example.com",
  "SetIdentifier": "eu-primary",
  "GeoLocation": {
    "ContinentCode": "EU"
  },
  "Failover": "PRIMARY",
  "HealthCheckId": "hc-eu-paris-001",
  "TTL": 60,
  "ResourceRecords": [{"Value": "52.47.XX.XX"}]
}

{
  "Type": "A",
  "Name": "www.example.com",
  "SetIdentifier": "eu-secondary",
  "GeoLocation": {
    "ContinentCode": "EU"
  },
  "Failover": "SECONDARY",
  "HealthCheckId": "hc-eu-frankfurt-001",
  "TTL": 60,
  "ResourceRecords": [{"Value": "3.120.XX.XX"}]
}

This configuration uses geolocation routing combined with failover routing — European users hit the Paris server first, and if it fails health checks, they’re automatically routed to Frankfurt.

Choosing the Right GeoDNS and Failover Provider

Key Features to Evaluate

Not all DNS providers offer the same level of geographic and failover capabilities. Here’s what to look for:

• Global anycast network: The provider’s nameservers should be distributed worldwide
• Health check frequency: 30-second intervals minimum for production systems
• Multiple health check protocols: HTTP, HTTPS, TCP, and custom checks
• Granularity of geo-routing: Country-level minimum, region/state-level preferred
• API access: For automation and infrastructure-as-code workflows
• DNSSEC support: For security against DNS spoofing attacks
• SLA: Look for 100% DNS resolution uptime guarantees

Provider Comparison

Provider	GeoDNS	Failover	Min TTL	Health Check Interval	Starting Price
AWS Route 53	Yes	Yes	1s	10s	$0.50/zone/month
Cloudflare	Yes	Yes	1s (paid)	60s	Free (basic)
NS1	Yes	Yes	1s	5s	Custom pricing
DNSMadeEasy	Yes	Yes	30s	30s	$30/month
Google Cloud DNS	Yes	Yes (with LB)	1s	10s	$0.20/zone/month

Best Practices for International DNS Architecture

1. Start with Proper Planning

Before implementing GeoDNS, analyze your traffic patterns:

• Where are your users located?
• What are your peak hours per region?
• Which regions generate the most revenue?
• What is your acceptable latency threshold?

Tools like Google Analytics geographic reports and real user monitoring (RUM) data provide the answers.

2. Implement Monitoring Before Failover

Don’t rely solely on DNS failover health checks. Implement comprehensive monitoring that tracks:

• Server response time
• Application-level health (not just TCP connectivity)
• SSL certificate validity
• Database connectivity
• Disk space and memory utilization

3. Test Your Failover Regularly

A failover mechanism you’ve never tested is a failover mechanism you can’t trust. Schedule regular “chaos engineering” exercises:

• Deliberately shut down a regional server
• Verify traffic redirects within your expected timeframe
• Confirm that user sessions are handled gracefully
• Test failback when the server recovers

4. Consider Data Replication

GeoDNS and failover only solve the routing problem. You also need your data available in multiple locations:

• Database replication: MySQL/PostgreSQL primary-replica setups across regions
• Object storage sync: S3 cross-region replication for media files
• Session management: Use centralized session stores (Redis, Memcached) or stateless authentication (JWT)

5. Don’t Forget About SEO

For international websites, proper DNS and server configuration directly impacts SEO:

• Use hreflang tags to indicate language/region variants
• Ensure search engine crawlers are routed consistently
• Monitor Core Web Vitals per region in Google Search Console
• Consider whether you need country-specific domains vs. subdirectories

Common Pitfalls and How to Avoid Them

Pitfall 1: Ignoring EDNS Client Subnet (ECS)

Traditional GeoDNS routes based on the resolver’s location, not the end user’s. If a user in Tokyo uses Google’s public DNS (8.8.8.8), the GeoDNS might see the request coming from a US-based resolver. EDNS Client Subnet (ECS) solves this by passing a portion of the client’s IP to the authoritative nameserver. Ensure your GeoDNS provider supports ECS.

Pitfall 2: TTL Too High for Failover

We’ve seen organizations configure DNS failover but leave their TTL at 86400 seconds (24 hours). This means that even after failover triggers, most users continue hitting the dead server for hours due to cached DNS records. For failover to work effectively, keep your TTL at 300 seconds or lower.

Pitfall 3: No Fallback Region

What happens if all servers in a region fail? Always configure a “catch-all” or default route that points to your most resilient data center. Without it, users in affected regions get NXDOMAIN errors — the worst possible outcome.

Pitfall 4: Overlooking DNS Propagation Delays

Even with low TTLs, some ISPs and corporate networks override TTL values and cache DNS records longer. Plan for a worst-case propagation time of 10-15 minutes and design your systems to handle both old and new routing simultaneously during transitions.

Real-World Case Study: E-Commerce Platform Expansion

One of our clients at Lueur Externe — a French e-commerce platform running on Prestashop — needed to expand from serving primarily European customers to a global audience across North America and Asia-Pacific.

The challenges:

• Page load times exceeded 4 seconds for users in Asia
• The single European server experienced occasional downtime during traffic spikes
• Conversion rates for international traffic were 60% below European rates

Our solution:

1. Deployed regional servers on AWS in eu-west-3 (Paris), us-east-1 (Virginia), and ap-northeast-1 (Tokyo)
2. Configured GeoDNS using Route 53 geolocation routing to direct users to the nearest region
3. Implemented health checks every 30 seconds with failover to secondary regions
4. Set up database replication with read replicas in each region and a primary in Paris
5. Reduced TTL from 3600s to 60s for rapid failover response

Results after 3 months:

• Average page load time dropped from 4.2s to 1.1s for Asian users
• Overall uptime improved from 99.7% to 99.99%
• International conversion rates increased by 45%
• Zero complete outages despite two individual server failures

The Future of Geographic DNS Routing

The DNS landscape continues to evolve with technologies that enhance geographic routing:

• DNS over HTTPS (DoH) and DNS over TLS (DoT) improve security but can complicate geographic detection
• Anycast DNS is becoming standard, providing inherent geographic optimization at the nameserver level
• AI-driven traffic management uses real-time latency data rather than static geographic rules
• Edge computing platforms (Cloudflare Workers, AWS Lambda@Edge) complement GeoDNS by moving application logic closer to users

Conclusion: Build Infrastructure That Matches Your Ambitions

GeoDNS and DNS failover are no longer luxury features reserved for tech giants. They are essential components of any serious international web presence. Whether you’re running a Prestashop e-commerce site serving customers in 30 countries or a WordPress content platform with a global readership, these technologies directly impact your bottom line.

The key takeaways:

• GeoDNS reduces latency by 70-85% for international users
• DNS failover ensures availability even when individual servers fail
• Combining both creates enterprise-grade resilience on any budget
• Proper configuration (low TTLs, ECS support, regular testing) is critical for success

Implementing this infrastructure correctly requires expertise in DNS management, cloud architecture, and performance optimization. At Lueur Externe, we’ve been building high-availability web infrastructures since 2003. As certified AWS Solutions Architects with deep expertise in international web projects, we help businesses ensure their websites perform flawlessly for audiences worldwide.

Ready to make your website truly available to the world? Get in touch with our infrastructure team and let’s design a DNS architecture that matches your international ambitions.