Google and OpenDNS, two of the most popular public name resolution services on the network, have proposed and implemented an extension of the DNS protocol that will improve browsing speed when using resources from a content distribution network.Large content distribution companies have servers spread around the world in systems called the Content Delivery Network (CDN). A good example of this is, for example, Akamai, which serves as a file store for third parties.
If we assume that cdNs have an exclusive server to serve a country with all available content replicated, the great advantage obtained with respect to having everything centralized in a single location is that in theory the time of access to the contents (latency) is minimized since, for example, a user in Seville, instead of communicating with the headquarters in the United States, it will do so with the server they have in Spain.
To achieve this, CDNs use a DNS system that, based on the IP address of the computer making the request, can find out its origin and respond with the IP of the content server closest to that country or area.
However, this is no longer ideal when there are many, and more and more, network users who do not use the DNS provided by their operator and configure public ones on their computer, such as those of Google or OpenDNS, to name the two examples involved in the article.
Improving DNS performance when accessing CDNs
The problem of the DNS systems for traditional CDNs that we mentioned is the following: as the DNS negotiation to obtain the IP of the desired destination is carried out by the intermediate server, the CDNs detect as the source of the request the Google DNS servers, which are in the United States. Faced with this, the CDN responds with the IP of its servers for the United States and not for Spain. We lose throughput because latency increases.To solve this, a modification of the DNS protocol has been devised that takes advantage of the extensions proposed in RFC 2671 to provide greater intelligence to the resolution of names.
The idea, which is called The Global Internet Speedup and is still in the draft phase, is helped by the original address of the client, which adds as one more data field to the request ("edns-client-subnet").
Although really, to maintain the privacy of the user what is sent is part of the user's public IP address (bits are removed from the end), so instead of sending 1.2.3.4 (if this were the user's public IP), it is truncated by 1.2.3.0 (all intermediate DNS servers will be able to read this information), accompanied by a 24-bit netmask.
With this, it does not matter that Google DNS is used, since by going the user information attached as data in the request, if the destination server is compatible with this new initiative you can correctly determine from where you really want to access its contents and answer with the server closest to the client, minimizing latency and, therefore, improving browsing speed.
For those who are more suspicious of their privacy, it can be configured so that no part of the user's IP address is sent (0.0.0.0/0 is sent). In these cases we understand that the service would work like traditional DNS on CDNs. That is, having no clue as to its actual origin, the CDN would respond with the IP closest to the DNS server that makes the request.
At the moment, both Google and OpenDNS have already installed this new function in their systems, which they have developed together with CDNetworks, EdgeCast, BitGravity and Akamai itself, which has lent a hand in the drafting of the draft.
Although it still seems unclear how much impact this will have on the actual performance of the network, it is not at all far-fetched that the IETF ends up adopting this technique as a standard that could also be adopted by operators, either in its current draft version, or in the final one.
Source: Broadband
