The Start
Mr. Wang from Beijing is a startup founder who built an app and is worried about how to store images. A friend told him UPYUN is good: fast, stable, and cheap, so he decides to check it out. He types "www.upyun.com" into his browser and sends a request. After the request is sent, the browser needs to resolve the domain into an IP address the computer understands. The browser first checks the local hosts file for a matching IP, and if there is one, uses it directly.
The Request
If the local hosts file has nothing, the browser sends a resolution request to a DNS server. DNS resolution is recursive: the recursive DNS server first checks its local DNS cache. On a cache hit, it returns the IP to the browser; otherwise it forwards the query upward, gets the NS server's address from the root name servers, and then asks that NS server for the IP. Since we use DNSPod for DNS resolution, DNSPod sees that this DNS server belongs to Beijing Telecom, so it returns the IP of our Beijing Telecom node to the browser.
Once the browser has the IP, it builds an HTTP request, the Beijing Telecom CDN node returns the resource, and Mr. Wang sees the UPYUN cloud storage homepage.
Problem
Looking back at this process, we notice a problem: if a user changes their local DNS to some arbitrary address that happens to be overseas, DNSPod will decide from its IP list that the request comes from abroad and return an overseas node IP to the browser. So I'm in China visiting a Chinese website, yet requesting resources from an overseas node. Because of the distance and network latency, access will be very slow and the experience poor.
The Fix
As the largest free DNS provider, Google recognized this problem and has been actively pushing for a fix. In April 2012, Google submitted version 01 of a draft. The core of the proposal is to extend the existing DNS protocol with a new client-subnet field that carries network information about the user. The local DNS server generates this field from the user's IP address and passes it upward level by level.
Google Public DNS and DNSPod already support this protocol. If a user changes their local DNS to 8.8.8.8, then during resolution DNSPod uses the user's IP to determine they're a Beijing Telecom user and returns the address of UPYUN's Beijing Telecom node to the browser. The browser then requests resources directly from the Beijing Telecom node, which is much faster.
Current Situation
However, since most ISPs don't support the EDNS protocol yet, DNSPod still mostly determines the region from the IP of the ISP's default DNS server. That's usually accurate, so users can still reach a nearby node and get better speed. On Linux, you can use the dig command to check whether EDNS is supported.
|
|
From the dig output, you can see that UPYUN uses DNSPod for resolution, and the enterprise flagship plan at that. The OPT PSEUDOSECTION indicates EDNS support.