Google Proposes DNS Extension 271
ElusiveJoe writes "Google, along with a group of DNS and content providers, hopes to alter the DNS protocol. Currently, a DNS request can be sent to a recursive DNS server, which would send out requests to other DNS servers from its own IP address, thus acting somewhat similar to a proxy server. The proposed modification would allow authoritative nameservers to expose your IP address (instead of an address of your ISP's DNS server, for example) in order to 'load balance traffic and send users to a nearby server.' Or it would allow any interested party to look at your DNS requests. Or it would send a user from Iran or Libya to a 'domain name doesn't exist' server."
True face of google (Score:0, Informative)
This is horrible. This is so GOOG can monitor ALL of your web activity, all the time.
If you ever use Google, or see adwords anywhere, they already have your ip--all 4 octets.
With this DNS extension, they can see what sites buckets of people are visiting when they're NOT on google sites or where goog ads are being served. It's not resolved down to the user, but it's bucketed, and over time, they can guess what's happening.
This proposal is absolutely about google getting more data about your internet habits, and more data about the market spaces they don't (yet) control.
Not as evil as suggested (Score:5, Informative)
Bad summary (Score:3, Informative)
The proposal says they would only use the first three octets. And users could just use a different DNS server if they had a restrictive servers that blacklisted Iran or whatever.
Re:Do no evil, eh? (Score:3, Informative)
Google, you are wrong here. (Score:4, Informative)
Internet already work withouth the need to propagate this information. Following the OS concept of "Less power", the less information about you that is propagated, the less problems.
"By returning different addresses to requests coming from different places, DNS can be used to load balance traffic and send users to a nearby server. For example, if you look up www.google.com from a computer in New York, it may resolve to an IP address pointing to a server in New York City. If you look up www.google.com from the Netherlands, the result could be an IP address pointing to a server in the Netherlands. Sending you to a nearby server improves speed, latency, and network utilization."
It seems this balancing is already possible withouth the need to propagate that data. I choose here safety/privacy, over a potential speed gain. Also the risk is for everyone, but the gain is just for a few ones (the people that has lots of servers and need a balancing solution)... hence, is unfair. My view of this.
Think about how this is working... (Score:4, Informative)
With this DNS extension, they can see what sites buckets of people are visiting when they're NOT on google sites or where goog ads are being served.
Umm, how is that, exactly? Assume this gets adopted - Google's DNS servers aren't authoritative for anyone other than Google - so they won't see your DNS requests... and even if they were, they'd only see traffic for the sites that Google DNS is authoritative for.
Consider the fact that Google runs a caching DNS already, they don't need this - they'll already have the data for everyone using their resolver service, which would be much more data than this would get them.
In short, I think your tinfoil hat is a little tight. This sounds to me like Google's DNS service has turned out to be using more of their bandwidth than they anticipated, and they're looking to reduce it.
Re:This is important! (Score:2, Informative)
If you're attempting to contact the domain, the DNS server will have your domain anyway. The privacy stuff here is specious.
You're thinking that this is about loadbalancing the DNS requests. That isn't the case, RTFA, etc. This about what HaeMaker said-- getting the user to the server closest to them, instead of to a completely arbitrary server halfway around the globe!
How are you proposing to do loadbalancing when:
0) If you haven't noticed, large sites DO have a sit-ton of traffic coming to and from them.
1) HTTP doesn't allow for a redirect to another IP address using the same hostname (it relies *entirely on DNS for that)
2) If you can't use DNS to direct to the appropriate host (via IP), then you have to route the traffic over the "wrong" links *twice*. That is a lot of bandwidth.
Re:Do no evil, eh? (Score:3, Informative)
Re:Wow, Slashdot editors hate Google (Score:5, Informative)
These days?
Re:Not as evil as suggested (Score:2, Informative)
I guess there could be some way to track what sites you're looking up from different tiers of DNS servers. If you were using google DNS, they'd have your entire DNS anyways, and if you were using another, then they'd only get your IP if you're connecting to google.com
Re:Do no evil, eh? (Score:5, Informative)
On your point about the Iran point...I think there is still the issue of intermediate servers sending "domain doesn't exist" messages to Libyan requests before the packet even reaches the intended destination.
What intermediate servers? The only parties involved here are you, the website and a 3rd-party resolver that you have chosen to use.
If you don't trust your 3rd-party resolver then you're screwed with or without this extension because this resolver can see your full IP address and can lie to you about DNS (e.g. sending you to an ad site instead of saying "no such domain" or whatever).
If you don't trust the website then why are you trying to connect to it? The website will get your full IP address as soon as you connect and can then do whatever it likes with that.
Assuming you are actually planning on connecting to the website and not just doing DNS requests for the sake of it, nobody gets any information that they weren't going to get anyway and nobody has any opportunity to block you that they weren't going to have anyway.
Re:Do no evil, eh? (Score:3, Informative)
"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."
Re:Not as evil as suggested (Score:1, Informative)
I'll never get modded up far enough being an AC, but i want to point out that it is not just 254.
Any netmask greater than 255.255.255.0 will allow some .0s and some .255s. (Thus the GP is correct it could be a max of 256)
Example my ISP uses 255.255.252.0 (/22s) for their networks. Plenty of .0 and .255s that will be in use (and are).
Re:Do no evil, eh? (Score:5, Informative)
I'm confused at your assertion. Maybe I'm missing something in the article (as opposed to the summary, which is just making shit up to be scary).
At the moment, I make a DNS request for a given domain. The DNS server sees if it has an entry cached and, if it does not, it asks an authoritative server for that domain what IP address should be used. Then it returns that IP address to me. That IP address is a fixed entity and could be located anywhere in the world. My initial connection to the domain, at least, is made using the server attached to that IP address. Then, if the data center wants to get clever, they can redirect me to a local data center by mangling the domain on all of their image loads, etc, to refer to a server closer to me. But it's clumsy, and I still have to talk to a distant server.
Under Google's proposal, my DNS server would send the domain I'm interested in and my approximate location (first three octets of my four-octet IPv4 address). The authoritative DNS server can then make a decision whether to send me to a data center in my general area, or a data center located on the other side of the planet. The IP address I receive is determined accordingly, so I contact the local data center. The local server represents the actual domain as far as I'm concerned, so no mangling is necessary, and I never have to talk to a datacenter half a planet away. I get faster results, the domain giving me the results has a greatly simplified time doing so, and life is good.
The only new information going to the authoritative DNS server is my approximate location. If I'm using Google's DNS servers, hell, they already have all four octets with the original DNS request. If I'm using someone another DNS server that supports this and I'm visiting Google, they'll give Google the first three octets. But, as soon as I have the IP address, I'm visiting the website itself and therefore the website has my full IP address. So it's not like I'm giving away any new information.
About the only "evil" I could see is an authoritative DNS server looking at the first three octets and deciding to return a black holed address because they don't like that country. But that's already very possible without it. I do it all the time on my PHPNuke discussion boards - NukeSentinel allows me to enter large ranges of IP addresses to block, and anyone visiting from those ranges gets a very low-bandwidth "go away" message.
I suppose my authoritative DNS server could gather more information about people looking up my domain, but then again they are my host provider, so if they want the data all they need to do is pull the IP connection logs and get the full IP.
So I'm really struggling to figure out how this introduces any new risks of monitoring or censorship. The only entity that will receive this new data already gets far more data as soon as you visit the site. And censorship is far more easily done at the routing layer, not the DNS layer.
Re:Do no evil, eh? (Score:4, Informative)
That would depend on the DNS server you chose to use. You might be able to set it to slightly randomize the first three octets to something still in your vicinity but not quite as close, or you might be able to ask your DNS server to spoof it entirely.
But think about the flow of data as it stands today:
1. You do a DNS lookup. Your DNS server has your full IP address.
2. Your DNS server does an authoritative lookup (assuming it's not cached). The authoritative DNS server now has the first three octets of your DNS server.
3. Authoritative DNS server returns poorly geolocated IP address to your DNS server.
4. Your DNS server returns the IP address to you.
5. You use that IP address to visit the web site. That web site now has your full IP address.
Chances are, the authoritative DNS server is run by the same organization that runs the host you are accessing, or at least the last few routers leading to it.
If the authoritative DNS server wants your IP address, they've already got it the instant you try to use the IP address they gave you as a result of the DNS lookup. Having the first three octets is now useless to them.
From the censorship side, having you spoof those first three octets to get an IP address to reach them will do you no good because it's FAR more effective to block or redirect requests through their routers by your source IP address. In other words, they'd give you an accurate IP address but you wouldn't be able to use it.
Yes, you could use TOR or a proxy, but then you'd already be proxying the DNS lookup anyway, so again there's nothing to gain by spoofing the first three octets in the DNS lookup.
This scheme has no impact on privacy - the organization that runs the authoritative server gets FAR more information the instant you use the IP address they gave you.
It also has little impact on censorship, because censorship via DNS is going to be highly ineffective. If I knew my country used DNS-based censorship, I'd just give out IP-address-based URLs that don't need to use a DNS lookup at all. Countries that do blocking will (and already do) use blocking at the HTTP or routing layer, not DNS.
Re:Google is further away than your ISP (Score:2, Informative)
Why the fuck would anyone want to use Google for DNS, instead of something closer (e.g. either their ISP or even a box on their very own LAN)?
Sadly, Google's DNS is something closer than the DNS server my ISP tells me to use if I don't want them hijacking misses.
Re:Do no evil, eh? (Score:2, Informative)
Maybe I'm misunderstanding this, but it sounds like this DNS "fix" will require that before I can read web sites I have to submit some information about my location.
You absolutely are misunderstanding it (or rather you are correctly understanding most of the posts here but they have little to do with the real proposal). You will not have to submit anything before doing anything. Nobody is getting any extra information here. If you think websites don't already know where you are, think again [ip2location.com]!
In terms of telephone calls, DNS is the telephone directory service. You want to phone www.google.com, so you phone .com and ask them for the google.com number. Then you phone google.com and ask them for the www.google.com number. Because google has branches of www all over the country, they give you a number for www in your local area, so the call is cheaper and better line quality. They can do this because they can see your caller id so they know roughly where you live.
Now lets say you don't like having to do so many steps all the time so you use a 3rd party service, let's call it ultraphone. You always ring the same number for ultraphone and they perform all the steps and give you back the final answer. The problem is that the google.com now sees ultraphone's caller id not yours so you get back a number that's in ultraphone's home-town not your home-town.
This proposed extension just allows ultraphone to tell google "I'm calling on behalf of please give me the number you would give them".
So you get a number that's local for you instead of one that's local for ultraphone.
The problem that is being fixed here is that ultraphone saves you hassle while getting the phone number but it gets you a bad phone number (not a wrong one just not the best one for you). Right now you have to decide which you prefer, fast lookups with sub-optimal results or awkward lookups with optimal results.
This extension lets you have fast lookups with optimal results.
Assuming you were going to call www.google.com (and not just looking up their number for fun) then google was going to see your caller id anyway. This extension just changes when it sees it. Right now if you use a 3rd party DNS provider it gets your IP too late to do good load balancing and that hurts users and may consume extra bandwidth.
Chances are that if you don't know about this stuff then you're using your ISP's DNS service and for some big ISPs that may mean a server hundreds of miles away, giving you sub-optimal answers.