DNS vs. Anycast for Edge PoP Routing

Hello! Welcome to the sixth lesson in our module on architecting unified edge security platforms.

In our last lesson, we focused on the "middle mile," designing the secure connection from our edge Points of Presence (PoPs) back to the customer's origin servers. We established a layered defense using origin IP concealment, mutual TLS for authentication, and connection pooling for performance.

Now that we've secured the path from the edge, we need to address a more fundamental question: how do users get to the right edge PoP in the first place? In a global network with dozens or hundreds of PoPs, directing user traffic to the nearest, best-performing location is critical for both latency and availability.

This brings us to today's learning outcome: Compare DNS-based vs. anycast-based traffic steering for routing requests to the nearest edge PoP.

We will deconstruct the two primary architectural patterns that solve this problem. As a software engineer, you'll find that this choice involves fascinating trade-offs between network-level automation and application-level control, directly impacting performance, reliability, and operational complexity.

---

1. The Core Problem: Traffic Steering

When a user in Singapore wants to access a service, we want them to connect to our Singapore PoP, not one in Frankfurt. The mechanism that makes this routing decision is called traffic steering or Global Server Load Balancing (GSLB). Its job is to map a user's request to the optimal PoP based on factors like network proximity, latency, and PoP health.

There are two dominant architectural approaches to this:

1. DNS-based Steering (GeoDNS): Use the Domain Name System to give users in different locations the IP address of a different PoP.
2. Anycast-based Steering: Use the internet's core routing protocol (BGP) to automatically send users to the topologically nearest PoP.

The image below provides a high-level visual comparison of these two concepts.

Let's dive into the internals of each approach.

---

2. DNS-Based Traffic Steering

In this model, the intelligence resides in an authoritative DNS server. When it receives a query for a domain like www.service.com, it doesn't just return a single, static IP address. Instead, it inspects the request and returns the IP address of the PoP it deems "best" for that specific user.

Architectural Breakdown

As the video explained, the authoritative DNS server is the final source of truth for a domain. In a GeoDNS setup, this server is enhanced with logic to perform traffic steering.

Let's summarize the key characteristics and trade-offs of DNS-based steering.

Advantages:

• Granular Control: You can implement complex logic. Decisions can be based not just on geography, but also on PoP health, server load, capacity, time of day, or even business logic (e.g., routing free-tier users to cheaper PoPs).
• Graceful Draining: To take a PoP offline for maintenance, you can simply stop returning its IP in DNS responses. Over the course of the DNS TTL, new traffic will naturally flow to other PoPs, allowing existing connections to finish gracefully.
• RUM-Powered Intelligence: As the Dropbox tech blog on their edge network mentions, DNS-based steering can be integrated with Real User Metrics (RUM). You can collect actual performance data from clients and build a highly accurate map of which PoP is truly the fastest for each client subnet, moving beyond simple geographic proximity.

Disadvantages:

• Slow Failover: If a PoP fails suddenly, traffic will continue to be sent there until the DNS records cached by clients and intermediate resolvers expire. This TTL can be minutes or even hours, leading to significant downtime for some users. The Dropbox blog (LINK) shows a real-world graph where it takes 15 minutes to drain 90% of traffic, even with a 60-second TTL.
• Inaccurate Geolocation: The authoritative server makes decisions based on the source IP of the DNS resolver, which might be a large public service (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1) located far from the actual user. The EDNS Client Subnet (ECS) extension helps but is not universally supported due to privacy concerns.
• Reliance on Third-Party Data: The quality of your steering depends on the accuracy of your GeoIP database.

---

3. Anycast-Based Traffic Steering

Anycast takes a fundamentally different approach. Instead of DNS intelligence, it leverages the core routing fabric of the internet itself. With Anycast, you announce the exact same IP address from all of your PoPs around the world.

When a user sends a packet to this shared IP, the network of BGP routers that form the internet's backbone directs it to the "closest" PoP that advertises it.

Architectural Breakdown

The key takeaway is that with Anycast, the decision-making is decentralized and handled by the network, not by your own servers.

Advantages:

• Extremely Fast Failover: If a PoP goes down and stops advertising the Anycast IP, BGP will automatically and very quickly (often in seconds) reconverge and start routing traffic to the next-closest PoP. This failover is seamless and transparent to users.
• Simplicity: The basic setup is simple. You don't need complex DNS logic or GeoIP databases. You just advertise the same prefix everywhere.
• DDoS Resilience: Anycast provides a natural defense against DDoS attacks. An attack originating from many sources will be distributed across multiple PoPs, diluting its impact on any single location.

Disadvantages:

• Coarse Control ("On/Off Switch"): You have very little control over traffic distribution. You can either advertise the IP from a PoP or not. You can't easily say "send 10% less traffic to this PoP because it's getting full."
• "Network-Nearest" is not "Latency-Lowest": BGP's definition of "closest" is typically the path with the fewest Autonomous System (AS) hops, which doesn't always correspond to the lowest latency path. A packet might take a 2-hop path across an ocean instead of a 3-hop path across town.
• Difficult Graceful Draining: If you withdraw an Anycast route to drain a PoP, all traffic, including existing TCP connections, is immediately rerouted. This will break those connections, as they will arrive at a new PoP that has no state for them. This is a major issue for applications with long-lived connections.

---

4. Case Study: Solving Anycast's Weakness

One of Anycast's biggest flaws is that it is "dumb" to service health. BGP will happily route traffic to a PoP as long as the network is up, even if the application servers in that PoP are all down. Your software engineering background will appreciate how a system can be designed to fix this.

The key architectural pattern from the Google case study is the separation of concerns:

• Anycast/BGP is responsible for routing traffic between PoPs.
• Local Load Balancers are responsible for health-checking the actual backend services within a PoP.
• Control Loop: If a load balancer detects that all local backends for a service are unhealthy, it signals the BGP process to withdraw the Anycast route advertisement from that PoP.

This creates an intelligent system that gets the best of both worlds: fine-grained health checking at the application layer controlling the coarse-grained, fast-acting routing of the network layer.

---

5. Comparison and Hybrid Approaches

Neither DNS nor Anycast is universally superior. The choice depends heavily on the application's needs and the organization's expertise.

Feature	DNS-Based Steering	Anycast-Based Steering
Control Granularity	High (per-user, can use application metrics)	Low ("on/off" switch per PoP)
Failover Speed	Slow (limited by DNS TTL, can be minutes/hours)	Very Fast (seconds, limited by BGP convergence)
Load Balancing Logic	Centralized, software-defined (in DNS server)	Decentralized, network-defined (BGP path selection)
Graceful Draining	Yes (stop serving IP, wait for TTL to expire)	No (withdrawing route breaks existing connections)
DDoS Resistance	Lower (attacker can target a specific PoP IP)	Higher (attack traffic is naturally distributed)
Troubleshooting	Simpler (can trace DNS decision)	Complex (depends on global state of BGP)
Required Expertise	Software Engineering (data pipelines, control loops)	Network Engineering (BGP, traffic engineering)

Given these trade-offs, many large-scale systems use hybrid approaches.

A common hybrid pattern is regional anycast. In this model:

1. GeoDNS makes a coarse-grained decision, routing a user from Asia to an Anycast IP specific to the APAC region.
2. Anycast then makes the fine-grained decision, routing the user to the best PoP within the APAC region (e.g., Singapore vs. Tokyo).

This prevents the worst-case scenario of BGP routing a user across an ocean while still retaining the fast failover benefits of Anycast within a region.

---

Conclusion

In this lesson, we dissected the two primary architectures for global traffic steering. You now have a first-principles understanding of how users are routed to the edge of a global network.

Key Takeaways:

• DNS-based steering offers granular control at the cost of slow failover. It's a software-driven approach, allowing you to incorporate complex business and application logic into routing decisions. Its major weakness is its dependence on the unpredictable nature of DNS caching.
• Anycast-based steering offers superb resilience and fast failover at the cost of control. It's a network-driven approach that is simple to start with and inherently robust, but it operates as a blunt instrument, making graceful operations and performance tuning difficult.
• The choice is a strategic trade-off. As the Edge Networking Playbook noted, the decision often comes down to an organization's core competencies: teams strong in software and data pipelines may prefer DNS, while those with deep network engineering expertise may lean toward Anycast.
• Hybrid models and advanced techniques provide a path forward. Combining DNS and Anycast, and enriching DNS decisions with Real User Metrics (RUM), allows architects to mitigate the weaknesses of each individual approach.

This lesson concludes our deep dive into the individual components of a unified edge platform. We've covered policy distribution, telemetry, edge-to-origin security, and now global traffic management.

In our next and final lesson, we will synthesize these concepts and Design a system for orchestrating security responses across multiple layers. We'll explore how to build a control plane that can take a signal from one layer (like a WAF) and trigger an action in another (like the DDoS or ZTNA layer) to create a truly integrated defense system.