Edge computing is the new black, and it comes in flavors. One of these flavors is the geo-proximate model, where workloads live in regional data centers, telco COs, or even in micro-data centers at the base of cell phone towers. Geo-proximate edge computing is heavily reliant on GeoDNS and other modern DNS tools.
Let’s assume that there’s a company hosting a website, and the organization hosting this website is from the U.S. but has users from around the world. There are any number of reasons why this company might not want to direct all users to a single web server cluster in the U.S.
The first of these is physics. The speed of light is the speed limit of the universe; we cannot transmit information faster than the speed of light. Unfortunately, the world is rather large, and when your requests have to travel halfway around the world and back again, those web servers can be annoyingly far away.
Let’s say that you want to go to www.dnsstuff.com. When you enter the address into your browser, the browser asks the operating system where it can find www.dnsstuff.com. The operating system, assuming it doesn’t have this information in its hosts file, then asks the first configured DNS server.
The DNS server asks its upstream DNS servers, and so on and so forth, until a reply is found. This is basic DNS 101. But what if you want to send different users to different servers? There are two principal ways to direct incoming users to different servers. The first is some form of load balancer. The second is to deliver different users different DNS replies.
Load balancers allow fine-grained control over incoming traffic. Using a load balancer means you can not only direct different users to different servers, but user requests can be filtered at the load balancer.
Filtering user requests at the load balancer would allow, for example, a company to examine requests coming from China, or bound for a Chinese site for any of the words or phrases on the blacklist of the Great Firewall. If the load balancer were outside of China, these requests could be filtered before being directed to servers in China.
Using a load balancer in this fashion saves the site operators from having to perform filtering at the Chinese server, where requests to that server might be examined by the state, and questions asked if there were regular searches for banned phrases. The flip side of this is that if a load balancer is the only form of traffic distribution used, all global traffic for that DNS entry has to go through that load balancer.
A primitive form of load balancing can be accomplished using the DNS round-robin method, in which a single DNS entry has multiple destinations associated with it. In this manner, one could operate a cluster of load-balancing servers, and use DNS round-robin to kind of, sort of prevent any one load balancer from being overloaded. Round-robin DNS, however, isn’t really useful.
With geo-proximate DNS, the DNS provider looks up the IP address of the computer requesting information on a given domain name and compares it to a GeoIP database. The GeoIP database contains mostly accurate information that links a given IP address to a physical location. In this way, the DNS provider can return a different DNS address depending on the geographic location of the requesting computer.
Our user in China, for example, might be sent to a load-balancing cluster near China, where their requests can be dealt with quickly. This prevents Chinese users from having to have all their requests served out of, for example, the U.S. Similarly, European users might be directed to a local load-balancing and web-serving cluster that’s compliant with GDPR privacy regulations.
In both cases, end users are geographically distant enough from the U.S. that having local load balancers and web servers will improve the user experience. Also, in both cases, local regulations create a need to deliver a different user experience than one that might be experienced by users in the U.S.
This is the power of geo-proximate DNS, and the basic concept only becomes more powerful as additional technologies are applied.
Edge Computing and Micro-GeoDNS
Edge computing is one use case in which the distribution of Internet-facing services needs to be more local, rather than broad geographies like “Europe” or “China.” Highly latency-sensitive applications, which are bounded by that annoying speed-of-light thing again, may find that the travel time across a single country is too long.
Some data-processing applications, such as driverless cars, may have real-time requirements. A fraction of a second can mean life or death at 60 miles per hour!
Here, DNS responses may be handed out based on different criteria, such as the latency between the requesting computer and the DNS resolver. In this case, globally distributed content delivery network (CDN)-based DNS services are often used.
CDN providers often have equipment located within the data centers, central offices, and, increasingly, even the cell tower sites of internet service providers (ISPs). This allows CDNs to, for example, cache YouTube videos that are popular in an area, so each request doesn’t have to go all the way back to the primary YouTube server farm.
CDN providers are increasingly offering micro-GeoDNS services supplied by their CDN network to provide the most accurate geographic responses for DNS requests, and can often provide a hosting service that will place some or all the internet-facing application physically near where users are requesting it.
This is the future of DNS, and of the internet: from centralized delivery of services to hyperlocal delivery, DNS is still the backbone of how things on the internet get done.