Google wants to see client addresses in DNS queries
in [Linux Networking]
|
From: David Schwartz on 2 Feb 2010 07:36 On Feb 2, 12:37 am, Chipmunk <rt...(a)NOSPOOMblueyonder.co.uk> wrote: > Unless of course you want to target marketing by geographic location, i > seriously doubt this has anything to do with speed. Honestly, I don't see how it helps you do that. Again, there are two cases: 1) The client is close to the server netwise. In this case, you can already do this. 2) The client is not close to the server netwise. In this case, all the clients that get the cached entries will get the wrong ones. DS
From: Rick Jones on 2 Feb 2010 14:20 It should be up to the client whether or not some portion of his IP address is given up the chain, not a server. rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Moe Trin on 2 Feb 2010 15:01 On Tue, 2 Feb 2010, in the Usenet newsgroup comp.os.linux.networking, in article <20100202090950.12457be0(a)hal.movb.de>, Tobias Nissen wrote: >David Schwartz wrote: >> Tobias Nissen <t...(a)movb.de> wrote: >>> Google's proposal is not about DNS speed. It takes into account the >>> client's network in order to resolve to a host more "fitting" for >>> the client. It does not try to improve the response times of DNS. Looking at the draft, the word 'speed' isn't even included. >> It makes no sense. There are two possibilities: >> >> 1) The DNS server is close netwise to its clients. In this case, >> you already know the IP address of the server, so why do you need >> the client's? >> >> 2) The DNS server is not close netwise to its clients. In this case, >> the IP address of the one client that happened to cause this query >> may not be representative of the clients that will get cached copies. >> In this case, acting on the IP address of that client is foolish. I strongly suspect that this is the more common scenario >> So what is the case where this is useful? Remember that google is an advertising service - that is the ONLY reason they exist. They want to improve the delivery of ads, and not need to have the same ads located on all geographical servers, and don't want to waste their bandwidth and CPU cycles when they discover that the IP of the actual client is somewhere else. Think about someone in Hong Kong (203.0.113.22) who is using OpenDNS (San Francisco) and wants to view all of the web pages for The Clueless Idiots Society. They receive a pointer to a spam server loaded with ads for clueless idiots in Northern California, maybe even just the Bay Area alone. They connect but their address is 203.0.113.22 which is clearly not Nor-Cal, and now the spam server has to either redirect them to the server with all the spam targeting clueless idiots in Hong Kong, _or_ the spam servers have to have all of the ads for clueless idiots in all places and waste time figuring out which is the correct set to deliver. Redirection may not work because of ad-blocking software, and having to have all ads on all servers costs extra money and CPU cycles. Of course, not delivering the ads is unacceptable and isn't even an option. >If think 80% or 90% of Akamai|Youtube|Google users could benefit from >it. But there may be 10% or 20% having a really hard time with it. If getting more targeted advertisements is a benefit - I'm not sure how many victims would agree. >There are other cases where the approach doesn't work. Think of clients >using a proxy for HTTP only. The draft=C2=B9 doesn't cover that, I think. No, it seems to be solely related to DNS resolution. However this is a (literally) first draft - and will likely get refined if it lasts. For example, it assumes that subnetting is done on a CIDR mask boundary, which is not a reliable assumption. There is a reason the five RIR databases indicate IPv4 network size by address _count_ rather than mask size (example - there are 582 allocations/assignments of blocks with 768 addresses, which the clueless might better understand as three ``Class C'' blocks mashed together). Even where the allocation/ assignment is sized as a power of two value, it may well not be the address still doesn't start/end on a bit boundary address - one example being the 2048 addresses (/21) beginning at 196.6.123.0 or 196.11.239.0 (look 'em up). This happens much more often that people might think. Old guy
From: David Brown on 2 Feb 2010 16:18 Moe Trin wrote: > On Tue, 2 Feb 2010, in the Usenet newsgroup comp.os.linux.networking, in article > <20100202090950.12457be0(a)hal.movb.de>, Tobias Nissen wrote: > >> David Schwartz wrote: > >>> Tobias Nissen <t...(a)movb.de> wrote: > >>>> Google's proposal is not about DNS speed. It takes into account the >>>> client's network in order to resolve to a host more "fitting" for >>>> the client. It does not try to improve the response times of DNS. > > Looking at the draft, the word 'speed' isn't even included. > >>> It makes no sense. There are two possibilities: >>> >>> 1) The DNS server is close netwise to its clients. In this case, >>> you already know the IP address of the server, so why do you need >>> the client's? >>> >>> 2) The DNS server is not close netwise to its clients. In this case, >>> the IP address of the one client that happened to cause this query >>> may not be representative of the clients that will get cached copies. >>> In this case, acting on the IP address of that client is foolish. > > I strongly suspect that this is the more common scenario > >>> So what is the case where this is useful? > > Remember that google is an advertising service - that is the ONLY reason > they exist. They want to improve the delivery of ads, and not need to > have the same ads located on all geographical servers, and don't want to > waste their bandwidth and CPU cycles when they discover that the IP of > the actual client is somewhere else. > > Think about someone in Hong Kong (203.0.113.22) who is using OpenDNS > (San Francisco) and wants to view all of the web pages for The Clueless > Idiots Society. They receive a pointer to a spam server loaded with > ads for clueless idiots in Northern California, maybe even just the Bay > Area alone. They connect but their address is 203.0.113.22 which is > clearly not Nor-Cal, and now the spam server has to either redirect > them to the server with all the spam targeting clueless idiots in Hong > Kong, _or_ the spam servers have to have all of the ads for clueless > idiots in all places and waste time figuring out which is the correct > set to deliver. Redirection may not work because of ad-blocking > software, and having to have all ads on all servers costs extra money > and CPU cycles. Of course, not delivering the ads is unacceptable > and isn't even an option. > >> If think 80% or 90% of Akamai|Youtube|Google users could benefit from >> it. But there may be 10% or 20% having a really hard time with it. > > If getting more targeted advertisements is a benefit - I'm not sure how > many victims would agree. > Getting more geographically targeted adverts /is/ a benefit. After all, the Hong Kong user may conceivably have the occasional interest in clueless idiot ads in Hong Kong, but will definitely have no interest in the ads for San Francisco. A slight chance of a little interest is not much, but it is more than no chance of any interest. And for those with no interest in any adverts, there is always Adblock Plus - then it doesn't matter where the adverts don't come from. I've yet to hear of a good reason why this suggested change to DNS would be a bad thing - as long as it still works well with DNS caching, and plays well with current DNS servers and clients. I can't see that anyone is harmed by DNS queries for ad servers being resolved geographically - after all, these servers already handle geographic ads, and already have your client IP address. If the end result is that the same "content" ends up in the same place, just by a shorter route, then that's surely a good thing - less wasted bandwidth on the main trunks. >> There are other cases where the approach doesn't work. Think of clients >> using a proxy for HTTP only. The draft=C2=B9 doesn't cover that, I think. > > No, it seems to be solely related to DNS resolution. However this is a > (literally) first draft - and will likely get refined if it lasts. For > example, it assumes that subnetting is done on a CIDR mask boundary, > which is not a reliable assumption. There is a reason the five RIR > databases indicate IPv4 network size by address _count_ rather than > mask size (example - there are 582 allocations/assignments of blocks > with 768 addresses, which the clueless might better understand as three > ``Class C'' blocks mashed together). Even where the allocation/ > assignment is sized as a power of two value, it may well not be the > address still doesn't start/end on a bit boundary address - one example > being the 2048 addresses (/21) beginning at 196.6.123.0 or 196.11.239.0 > (look 'em up). This happens much more often that people might think. > > Old guy
From: Tobias Nissen on 2 Feb 2010 16:44
David Brown wrote: [...] > I've yet to hear of a good reason why this suggested change to DNS > would be a bad thing - as long as it still works well with DNS > caching, and plays well with current DNS servers and clients. And there's the chance it will be optional, with the default being the way it works now. http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00133.html http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00140.html http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00156.html Well, it's just a first draft. |