A content delivery network (CDN) is a distributed network of servers that delivers content to users based on their location. When Google and OpenDNS started offering their DNS resolver services, many CDNs did not route users to their optimal edge servers.
A CDN needs to decide which of its nodes is the best available edge server for a user and it does so by using a few hints to estimate the user's location. Before public DNS resolvers became available, a CDN could guess a user's location from the location of their DNS server. Most users employed their ISP's DNS servers, which are usually located in the client's ISP network, but this is not the case anymore with public DNS resolvers such as the ones provided by Google or OpenDNS.
A solution to this problem is the use of edns-subnet-client (ECS), a new extension mechanism for DNS (EDNS) that exposes the client's subnet (IETF Draft). With this extension, the DNS recursor sends the client's subnet to the authoritative server so that it can deliver the IP address of the closest edge server.
Before this extension was implemented, a DNS request was harmless in terms of privacy, as the resolving DNS only got to know the IP of the originating DNS server. With ECS, however, it also gets the IP address of the client (or at least part of it). These privacy concerns are explicitly mentioned in the draft:
The mechanisms provided by edns-client-subnet raise various security related concerns, related to cache growth, the ability to spoof EDNS0 options, and privacy. Section 10 explores various mitigation techniques.
Many of these issues are addressed to some extent:
With the edns-client-subnet option, the network address of the client that initiated the resolution becomes visible to all servers involved in the resolution process. Additionally, it will be visible from any network traversed by the DNS packets.
To protect users' privacy, Recursive Resolvers are strongly encouraged to conceal part of the IP address of the user by truncating IPv4 addresses to 24 bits. No recommendation is provided for IPv6 at this time, but IPv6 addresses should be similarly truncated in order to not allow unique identification of the client.
Users who wish their full IP address to be hidden can include an edns-client-subnet option specifying the wildcard address 0.0.0.0/0 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS).
However, by saying "strongly encouraged", the implementing parties are free to ignore such privacy concerns. And even if they do follow these guidelines, a truncated address is usually enough to identify an ISP.
The option to include the wildcard address 0.0.0.0/0 to keep your IP hidden is even more unrealistic, as this not only requires the DNS server to voluntarily respect this but also assumes that your operating system implements this feature, which might not be the case.
Currently, only Google Public DNS and OpenDNS seem to implement ECS, but together they account for a whopping 20% of worldwide DNS traffic.
In the beginning, DNS servers had to register with OpenDNS and Google in order to receive queries with ECS options. However, since June 2014, Google Public DNS can detect nameservers that support ECS and will send them this information automatically (Google Public DNS now auto-detects nameservers that support edns-client-subnet). We have no updated information on how OpenDNS handles this at the moment.
So what should you do about this? First of all, you must know that this is not a highly critical vulnerability, since exploiting it requires that attackers run their own DNS servers and trick ECS-enabled DNS servers into giving them this information. Finally, the amount of data that attackers could obtain is not enough to identify you. Actually, they would need extra information or even a warrant to get your IP.
If you are still concerned about this issue and want to minimize risk, we recommend using the DNS servers of your VPN provider (if any) or public DNS servers that support anonymity.