Finding the Best Servers to Answer Queries—Edge DNS and Anycast

TL;DR

• IP Anycast is a network addressing and routing methodology that allows IP addresses to be announced from multiple points on the internet
• With the proper implementation, Anycast can reduce DNS RTTs and offer innate DDoS protection
• Akamai's authoritative name service, Edge DNS, combines global scale with strategic network advertisements to optimize performance and reliability
• Domain owners can further promote a performant DNS posture by maximizing record TTLs and enabling Akamai's Zone Apex Mapping
• Third-party open source networks such as RIPE Atlas are helpful tools to monitor DNS Anycast performance without vendor and cloud service bias

What Is Anycast?

While Unicast defines a single destination endpoint for a given IP, Anycast is an addressing technique in which the same IP is advertised from multiple servers simultaneously. Routers determine which node will ultimately service an incoming packet via BGP and IGP, protocols designed to calculate the shortest topological path between a source/destination pair. With these consistent sets of principles in mind, administrators can minimize client-server round-trip times (RTTs) with strategic networking practices and server deployments. In addition, Anycast offers innate DDoS resilience, as numerous machines can absorb a distributed attack against an individual IP instead of a single point of failure. As a result, Anycast is often a viable addressing method for network administrators aiming to achieve optimal reliability and performance via distributed computing.

DNS and Anycast

The technical underpinnings of the Domain Name System make the protocol particularly well suited for Anycast routing. When an end-user sends a DNS query, recursive resolvers will contact an authoritative nameserver delegated by the parent zone (such as .com or .net) to fulfill the request. Domain owners are encouraged to delegate multiple, distributed nodes to promote redundancy. However, a Unicast posture can result in lengthy RTTs, as the resolver may select an IP belonging to a distant authoritative machine. While more sophisticated resolvers remember previous RTTs for every nameserver IP and favor proximal nodes, this advanced functionality has yielded mixed results in the wild. Many resolvers do not oversee enough DNS traffic to gather sufficient data for accurate estimates, while more popular resolvers do not always choose the lowest RTT nameserver IP. Finally, many resolvers simply do not possess these advanced capabilities in the first place, and decisions are thus made without any regard for latency.

While DNS RTTs are ultimately at the mercy of resolvers' decisions in a Unicast model, Anycast offers domain owners greater opportunity to influence these distance vectors via strategic deployments. When a resolver chooses a nameserver IP belonging to an Anycast network, multiple authoritative servers can announce this address, as shown in the below diagram. This distributed networking scheme grants admins the ability to embed nodes in prudent topological locations to ensure routers organically discover the closest machine -- an impossibility under Unicast since each IP is tied to a single endpoint. As a result, domain owners can be confident that lookups will remain performant no matter which nameserver IP is chosen by the resolver.

DNS is also a smart fit for Anycast routing since requests and responses are delivered by stateless UDP, a reliable protocol partnership since DNS messages fit inside a single layer 4 packet. Conversely, Anycast can prove problematic for more complex, chatty applications built on connection-oriented TCP. While rare, packets belonging to the same TCP connection can theoretically be routed to different Anycast endpoints -- an outcome that often results in disruptions and resets. Nevertheless, DNS providers can leverage Anycast without any such affinity complications since queries are reliably fulfilled without an established layer 4 connection. As a result, it is no surprise that critical DNS infrastructures like root nameservers rely on Anycast to respond to queries in a reliable, performant manner.

Edge DNS and Anycast Resilience

Akamai's external authoritative name service, Edge DNS, includes a number of unique features to help customers fully realize the benefits of Anycast routing. From a reliability perspective, the impressive scale of the platform complements Anycast's innate DDoS resilience. With over 300 points of presence (PoPs) across the globe, standard customer traffic typically consumes less than 1% of total nameserver capacity, leaving malicious actors little opportunity to successfully administer distributed, volumetric attacks. In addition, each customer is assigned a unique combination of six "clouds," or Anycast IPs, to properly load balance client queries. Edge DNS can even rate limit DNS traffic from individual IP addresses issuing a suspicious number of requests. 

This holistic approach to DDoS resilience is designed to safeguard Edge DNS from the most sophisticated and grandiose attack vectors. However, in the unlikely event one or several nodes are rendered unresponsive, the platform will continue to fulfill end-user queries without interruption. Akamai can commit to a 100% uptime SLA by strategically limiting the number of clouds announced from each PoP. While resolvers will typically contact another delegated IP if an initial nameserver fails to respond, a downed Edge DNS PoP could serve as a single point of failure if every resolver retry was routed to this unresponsive region -- a possible outcome if every cloud IP was announced from the PoP router. To avoid this exposure, Edge DNS PoPs advertise a limited number of clouds to ensure at least one retry will be directed to a healthy Akamai nameserver. As a result, no resolver is inextricably tied to a single point of failure.

Along with resilience against the largest DDoS attacks, Edge DNS can quickly recover in the unlikely event of hardware malfunctions such as a disk or network card failure. By orchestrating automatic prefix withdrawals from nodes that suffer spontaneous defects, the platform can quickly divert traffic away from trouble -- yet another example of how Akamai utilizes Anycast routing to guarantee uninterrupted service. Every nameserver is monitored by a local software agent that will detect improper responses. If a failure is detected, the machine's BGP speaker will withdraw advertisements to ensure traffic will be directed to healthy nodes within the PoP. If every machine within the PoP is marked down, the PoP router will withdraw all cloud prefixes from the public internet, so queries will be routed to a healthy Edge DNS region instead. 

Edge DNS and Anycast Performance

Similar to how Edge DNS maintains unyielding availability via shrewd network practices, the platform relies on Anycast's distributed model to optimize DNS performance. Anycast incentivizes network admins to advertise the same IP from ample, diverse deployments to reduce the distance between every client/server exchange. One of the largest DNS platforms in the world, Edge DNS strategically positions its thousands of nameservers near the most popular resolvers servicing the public internet. Every Edge DNS customer is guaranteed comprehensive coverage since all of Akamai's 24 Anycast clouds include highly geo-diverse nodes. In addition, Akamai engineers constantly evaluate how to maximize cloud advertisements from every machine without jeopardizing the platform's unrelenting uptime. 

While Akamai DNS boasts unmatched geographic coverage, the scale of an Anycast platform only correlates with improved RTTs if client requests are routed to the closest server -- an outcome that can prove elusive without proper peering practices. Take the following scenario:

• End user in Country A makes a request that will be fulfilled by a server belonging to an Anycast cloud 
• Anycast cloud includes a PoP in Country A
• Anycast cloud only peers with Transit Provider R in Country A
• Country A has a number of local ISPs that traditionally peer with Transit Provider Q

Under these circumstances, it is possible the request could be routed to another country -- or even another continent -- since transit providers have financial incentives to keep traffic within their own network. As a result, a remote server may fulfill the request even if a proximal Anycast node is available in the same country, as illustrated by the diagram below: