| We need Your Support. Make a Donation now! or |  |
DNS is like the phone book for the Internet. It converts human readable domains (www.opendns.com) to an IP address (208.69.38.160) that your computer can connect to. But what happens when you look up a business in the phone book and there are 50 locations? You probably want the location closest to you.
When trying to reach a website that exists in 50 locations around the world, you would want the same thing to happen. You want to be sent to the closest, fastest or least congested location automatically. Until now, figuring out which location is closest to you was not possible with DNS alone.
Today, if you’re using OpenDNS or Google Public DNS and visiting a website or using a service provided by one of the participating networks or CDNs in the Global Internet Speedup then a truncated version of your IP address will be added into the DNS request. The Internet service or CDN 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. With this more intelligent routing, customers will 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.
Below is an example using a patched version of BIND's dig command to add the client-subnet option. Normally, this would be done automatically by your recursive DNS resolver. If you're interested in using dig to play around with this, one of the authors of the IETF draft has created a patch that can be found on his website: http://wilmer.gaa.st/edns-client-subnet/
wilmer@fiona:~$ ./bin/dig @ns1.google.com www.google.com +client=130.89.89.0/24 ; <<>> DiG 9.7.1-P2 <<>> @ns1.google.com www.google.com +client=130.89.89.0/24 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ; CLIENT-SUBNET: 130.89.89.0/24/21 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 604800 IN CNAME www.l.google.com. www.l.google.com. 300 IN A 74.125.79.104 www.l.google.com. 300 IN A 74.125.79.99 www.l.google.com. 300 IN A 74.125.79.147
Are there privacy concerns I should be aware of?
When a user requests a webpage, the two most important steps are the DNS request to find the right server and the HTTP request to request the contents of a page from a web server. HTTP requests already include the full and complete IP address of the requester and always have. Now, with edns-client-subnet, a portion of the user IP address is included in the DNS response. This is information that was not previously included in the DNS requests. If the website the user is connecting to runs their own DNS then the information is being disclosed to the same party who already would have seen it. If the website the user is connecting to is using a different provider for DNS than for web services then the DNS company in question would be seeing information it might not otherwise see. It's not clear if this is a good idea and therefore recursive DNS providers are encouraged to only implement edns-client-subnet with services who provide combined DNS and HTTP so that no new third-party is introduced to even a portion of the user IP address.
What do you mean by a truncated IP address?
If using OpenDNS or Google Public DNS, your complete IP address will not be embedded. Instead, the DNS server will only include enough information for the CDN to know your general location. For instance, if your IP address is 67.215.80.23, the DNS server will only expose the first three octets, so 67 – 215 – 80 instead of 67 – 215 – 80 – 23. A reasonable analogy would be only showing the prefix of your phone number in caller ID. If your number was 415-555-1234 then only 415-555-XXXX would appear in the Caller ID. Not enough to identify you, but enough for the receiving party to know the area code and prefix of the caller.
Who has implemented this?
A number of recursive and authoritative DNS providers including Google, Bitgravity, CDNetworks, DNS.com and Edgecast have deployed this DNS improvement onto their servers around the world. A partial listing can be found on the Participants page. A number of other leading Internet companies will be implementing this in the coming year.
This represents a tremendous step forward in improving the Internet experience for millions of consumers and businesses and we look forward to continued cooperation and innovation.
Can any ISP or Internet service participate?
This initiative is open to other recursive DNS service providers, Content Delivery Networks and anyone else interested in participating.
For help implementing edns-client-subnet or to discuss questions with the participants, please join our mailing list hosted by Google: http://groups.google.com/group/afasterinternet/subscribe?note=1 or email us at afasterinternet at googlegroups dot com. Note that changes or discussions about the specific draft itself (as opposed to implementation questions) should happen within the IETF DNSOP Working Group, which maintains a website with details about how to participate and get involved here: http://datatracker.ietf.org/wg/dnsop/charter/.
If you have implemented the edns-client-subnet draft and want to be listed on http://www.afasterinternet.com/ or have specific questions related to the Global Internet Speedup website, please email webmaster at afasterinternet dot com.
Are recursive DNS services who implement this now sending out truncated IP addresses to all authoritative DNS servers they communicate with? Are all authoritative DNS providers who implement this now sending back more specific responses to all recursive DNS servers?
Section 12.2 of RFC 7871 specifies that implementers MAY use a whitelist to determine who they send the truncated IP address to, and of course, authoritative DNS may choose who they include the edns response to. To date, OpenDNS continues to operate on a whitelist basis, enabling the option only for specific authoritative nameservers or zones. Google now supports probing for edns-client-subnet support.