Late Wednesday evening, Google employees posted an "Internet-Draft" outlining proposed changes to the DNS protocol that allow authoritative DNS servers to see the addresses of clients. This way, geographically distributed content delivery networks can tailor their answers to a specific client's network location. So a client from California would talk to a server in California, while a client in the Netherlands would talk to a server in the Netherlands.
Currently, authoritative DNS servers don't see the client address, only the address of the resolving server that is typically operated by the client's ISP. So in the current situation, if our Californian and Dutch clients both use a DNS resolver in New York, a location-optimizing authoritative DNS server would give them both the addresses of servers in or around New York. By including the client's address in the request, the authoritative server can send a better response and improve the subsequent interactions between the client and server because the request/response round-trip times across the network are shorter.
Google does have a plan to avoid the most egregious privacy concerns. "Recursive Resolvers are strongly encouraged to conceal part of the IP address of the user by truncating IPv4 addresses to 24 bits." Coincidentally, 24 bits maps directly to the minimum address block that can be carried in the Internet's routing system. Carrying any more than that won't help solve the network distance problem using the routing tables. For IPv6, there is no corresponding number that everyone agrees to, but the authors of the draft suggest truncating IPv6 addresses as well. Of course, the owner of the authoritative DNS server still gets to see the client's full IP address when the HTTP request for the actual content is sent.
Internet-Drafts are working documents within the Internet Engineering Task Force. Anyone in possession of a keyboard and time on their hands can write one. Drafts live on the IETF servers for six months and are then deleted, so authors must post updates twice a year. If there is interest and no technical objections, a draft may progress to become an RFC (Request For Comments). The bar is relatively low for "experimental" and "informational" RFCs, but much higher for those that are intended to become Internet standards. Very few drafts get that far.
In this particular case, it's not clear whether purists will object to embracing "two-faced DNS" so explicitly. Although many organizations have DNS servers that serve up different answers to internal users than to external users, this practice isn't held in high esteem by those in the IETF who care about the Internet's architecture.
Interestingly, the Google and Neustar employees who wrote the document chose a model where the authoritative server sees the client addresses, rather having the authoritative server publish the full list of server addresses so that the resolving server can figure out which is closest. And if Web protocols and practices weren't so sensitive to round-trip times, this effort would be largely irrelevant. (Altough not having to carry packets from continent to continent would still save bandwidth costs.)
It's too early to make guesses about the success of this effort at the IETF, but Paul Vixie, well known as the original author of the BIND DNS software and no less for his strong opinions, set the tone in a message to the IETF DNSEXT mailing list. "if we're going to add client identity to the query, can we do so in a more general way? i'd like to know lat-long, country, isp, language, and adult/child."
