People often think about DNS as “this technical thing that translates human-friendly website names to machine-friendly IP addresses”. In the Content Delivery business though it plays a much bigger role. If you have been delivering digital content all around the globe for a while, then you know that it’s not enough to have lots of datacenters equipped with modern caching devices. When trying to fetch an object that exists in 50 locations around the world, you would want to be sent to the closest, fastest, cheapest or least congested location automatically. It is clearly not that “one-to-one simple translation” one may have in mind.
A DNS-based load-balancer solution allows companies to distribute application load between global datacenters or cloud providers. This solution, when combined with a Content Delivery Network (CDN), provides benefits such as improved load distribution, faster load times, and high content availability. These benefits result from the user requests being directed to the optimal (often nearby) server. Latency and Packet Loss are therefore minimized due to a shorter physical distance traveled.
How does GeoDNS work
In order to find us the closest data center, DNS needs to have an idea about our location. GPS would have been nice here, but unfortunately, DNS has to work with the common denominator for all type of devices, which is the Source IP. IP address data comes from the regional Internet registries, which allocate and distribute IP addresses amongst organizations located in their respective service regions. Secondary sources include data mining, user-submitted geographic location data, and data contributed by internet service providers.
The Recursive Resolver problem
DNS servers use the IP address of the incoming query to identify the user location. When a DNS server does not know the answer for a query, it acts as a “Recursive Resolver” and throws the query upstream. By design, every hop in the DNS chain terminates the connection and initiates a new one toward the next hop. Since most queries come from intermediate Recursive Resolvers, the source address is that of the Recursive Resolver rather than of the query originator. Traditionally, Recursive Resolvers are reasonably close to the source of queries. For these resolvers, using their own IP address is sufficient for authority servers that tailor responses based upon the location of the queries. However, many ISPs and other organizations use a Centralized Resolver infrastructure that can be distant from the clients the resolvers serve. In these cases, the Authoritative Nameserver may get the wrong idea about the user location, which in turn may lead to a poor server selection.
The Redirect approach
Even though the DNS response may send a user to the wrong data center, there are still ways to mitigate the problem. An edge server that receives an HTTP request for an object may figure out that the user was misrouted by examining the round-trip delay of the TCP handshake. Upon detecting a misroute, the edge server may run another location check, but this time using the real Source IP (a.k.a “the eyeball address”). Luckily, most of the HTTP middle boxes record the original Source IP in HTTP headers, so we’re not hitting the “recursive resolver” problem. Given the right location, the edge server can fix the original DNS assignment and construct a fully qualified redirect URL using the IP address of a closer server. The client can then follow the redirect by resending the request to the “better” server by appropriately setting HTTP headers. This redirection procedure is not only complex and non-standard, it has a performance cost of an additional round-trip. A better approach is to fix the DNS protocol itself.
What’s EDNS all about?
Fixing DNS requires some way of preserving the original location of the user across multiple middle boxes. The original design of DNS restricts the total packet size to 512 bytes, which effectively does not leave any room for a “location extension”, or any other extension like DNSSEC. This is what EDNS (Extended DNS) will solve in a backward-compatible way: if both DNS servers support EDNS, they can exchange packets larger than 512 bytes, and if not — they fall back to the traditional DNS.
What’s EDNS Client Subnet?
In 2011 Google wrote an IETF draft to send Client IP information using the EDNS0 extension and this is usually called ‘edns-client-subnet’. As a DNS client, it means that a truncated version of your IP address will be added into the DNS request. The DNS server will use this truncated IP address to make a more informed decision in how it responds so that you can be connected to the most optimal server. This standard is promoted by the Faster Internet initiative and already adopted by some leading vendors.
Because it is designed to keep privacy, the sender has the freedom to limit the client IP information. Instead of sending a full IP address, the DNS server is able to send partial information such as /24 only. For instance, if your IP address is 66.214.81.22, the DNS server will only expose the first three octets, so 66–214–81. Armed with the real IP address of the querying device, the DNS server can now come up with a much more accurate response.
With this more intelligent routing, customers have a better Internet experience with lower latency and faster speeds. Best of all, this integration is being done using an open standard that is available for any company to integrate into their own platform.
