- 支持EDNS0 client subnet，递归服务器在发送给权威服务器的请求，带上用户客户端的真实IP。当然这是非标准实现，目前递归服务器也只有大型提供商如Google Public DNS、OpenDNS予以支持。
The DNS middleman has three very important implications on traffic management:
- Recursive resolution of IP addresses
- Nondeterministic reply paths
- Additional caching complications
Recursive resolution of IP addresses is problematic, as the IP address seen by the
authoritative nameserver does not belong to a user; instead, it’s the recursive resolv‐
er’s. This is a serious limitation, because it only allows reply optimization for the
shortest distance between resolver and the nameserver. A possible solution is to use
the EDNS0 extension proposed in [Con15], which includes information about the
client’s subnet in the DNS query sent by a recursive resolver. This way, an authorita‐
tive nameserver returns a response that is optimal from the user’s perspective, rather
than the resolver’s perspective. While this is not yet the official standard, its obvious
advantages have led the biggest DNS resolvers (such as OpenDNS and Google) to
support it already.
Not only is it difficult to find the optimal IP address to return to the nameserver for a
given user’s request, but that nameserver may be responsible for serving thousands or
millions of users, across regions varying from a single office to an entire continent.
For instance, a large national ISP might run nameservers for its entire network from
one datacenter, yet have network interconnects in each metropolitan area. The ISP’s nameservers would then return a response with the IP address best suited for their
datacenter, despite there being better network paths for all users!
Finally, recursive resolvers typically cache responses and forward those responses
within limits indicated by the time-to-live (TTL) field in the DNS record. The end
result is that estimating the impact of a given reply is difficult: a single authoritative
reply may reach a single user or multiple thousands of users. We solve this problem in
- We analyze traffic changes and continuously update our list of known DNS
resolvers with the approximate size of the user base behind a given resolver,
which allows us to track the potential impact of any given resolver.
- We estimate the geographical distribution of the users behind each tracked
resolver to increase the chance that we direct those users to the best location.
Estimating geographic distribution is particularly tricky if the user base is distributed
across large regions. In such cases, we make trade-offs to select the best location and
optimize the experience for the majority of users.
But what does “best location” really mean in the context of DNS load balancing? The
most obvious answer is the location closest to the user. However (as if determining
users’ locations isn’t difficult in and of itself ), there are additional criteria. The DNS
load balancer needs to make sure that the datacenter it selects has enough capacity to
serve requests from users that are likely to receive its reply. It also needs to know that
the selected datacenter and its network connectivity are in good shape, because
directing user requests to a datacenter that’s experiencing power or networking prob‐
lems isn’t ideal. Fortunately, we can integrate the authoritative DNS server with our
global control systems that track traffic, capacity, and the state of our infrastructure.
The third implication of the DNS middleman is related to caching. Given that author‐
itative nameservers cannot flush resolvers’ caches, DNS records need a relatively low
TTL. This effectively sets a lower bound on how quickly DNS changes can be propa‐
gated to users. Unfortunately, there is little we can do other than to keep this in mind
as we make load balancing decisions.