Google wants to see client addresses in DNS queries

Does this suggestion have a Dark Side?

http://www.linuxtoday.com/infrastruc...12903135NWNTSD

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (x86_64 Ubuntu 9.10) Linux 2.6.32.7
^ ^ 19:03:01 up 2 days 3:09 1 user load average: 1.18 1.21 1.14
�借貸! ��騙! ��交! �打交! �打劫! �自殺! 請考慮綜� (CSSA):
http://www.swd.gov.hk/tc/index/site_...sub_addressesa

Man-wai Chang to The Door (24000bps) wrote:

> Does this suggestion have a Dark Side?
>
> http://www.linuxtoday.com/infrastruc...12903135NWNTSD
>

Stupid, don't know if it's real (didn't bother to check). But, it
should rely on the server with the quickest response. If one's down,
to use the secondary, or so on. DNS already works fine as it is. If
they want to check the closest geographical server, it would be better
to have checks for other things. Anyway, doesn't matter what google
wants to see, luckily they can't change the way it works (though I
understand their influence on some providers). Personally, I'm not too
concerned about this happening or being a requirement.
--
Not really a wanna-be, but I don't know everything.

> Stupid, don't know if it's real (didn't bother to check). But, it
> should rely on the server with the quickest response. If one's down,

Thansk

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (x86_64 Ubuntu 9.10) Linux 2.6.32.7
^ ^ 13:48:01 up 2 days 21:54 1 user load average: 1.20 1.19 1.18
�借貸! ��騙! ��交! �打交! �打劫! �自殺! 請考慮綜� (CSSA):
http://www.swd.gov.hk/tc/index/site_...sub_addressesa

Wanna-Be Sys Admin wrote:
> Man-wai Chang to The Door (24000bps) wrote:
>> Does this suggestion have a Dark Side?
>>
>> http://www.linuxtoday.com/infrastruc...12903135NWNTSD
>
> Stupid, don't know if it's real (didn't bother to check). But, it
> should rely on the server with the quickest response. If one's down,
> to use the secondary, or so on. DNS already works fine as it is.

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktn0sUACgkQ5jrP7hWxSO8G/ACgnlcyYMh2JdaXi16cEWG/q63T
k8AAoK7wFv8WVqql4SZtbYl6pDumrwU4
=U0Ju
-----END PGP SIGNATURE-----

David Schwartz wrote:
> On Feb 1, 11:22Â*pm, Tobias Nissen <t...@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.
>
> 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.
>
> So what is the case where this is useful?

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.

There are other cases where the approach doesn't work. Think of clients
using a proxy for HTTP only. The draft¹ doesn't cover that, I think.

The discussion on DNSEXT² is a very good read for those who want to dig
a little deeper. It is safe to say that Paul Vixie does not like the
idea³ :-)

¹ http://www.ietf.org/id/draft-vanderg...ient-ip-00.txt
² http://ops.ietf.org/lists/namedroppers/
http://news.gmane.org/gmane.ietf.dnsext
³ http://ops.ietf.org/lists/namedroppe.../msg00079.html
http://ops.ietf.org/lists/namedroppe.../msg00090.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktn3c4ACgkQ5jrP7hWxSO9tCACeLUe3B5dYEH Zv6+4QRQ/NQRDb
OFkAoKgZnTK9bivXbHmk8VALEJoVrI/D
=V/UW
-----END PGP SIGNATURE-----

On 02/02/2010 08:48, David Schwartz wrote:
> On Feb 1, 3:04 am, "Man-wai Chang to The Door (24000bps)"
> <toylet.toy...@gmail.com> wrote:
>
>> Does this suggestion have a Dark Side?
>>
>> http://www.linuxtoday.com/infrastruc...12903135NWNTSD
>
> It completely defeats the logic of the DNS system. The whole point of
> having a DNS server is that you can issue one request and return that
> response to any number of clients. There are many places where it
> makes sense to figure out the closest server, but bundling it into DNS
> seems like one of the worst possible choices to me.
>
> DS

I haven't read the details of the suggested system as yet, but
presumably responses from the upstream DNS server would contain the
resolved address, and an ip address and netmask for which that address
is valid. Then the downstream server could pass on the same result to
any clients with matching client addresses. This would give you almost
as much caching as today, since the majority of clients use their ISP's
DNS server (or a local server on their own network), and will having
matching ip addresses in most cases.

There are other situations where knowing the client address can be
useful for the DNS server - look at OpenDNS for an example.

Another use could be for embedded appliances of various sorts. Suppose
you buy a NAS box and plug it into your network (I'm thinking of home
networks, or small company networks here). It gets an IP address from
your DHCP server. To be able to use it, you've got to know the IP
address. There are a range of ways to do this today, none of which are
really ideal - certainly not ideal for all users. Client addresses in
DNS queries would give another way to deal with this situation. The box
could contact nasboxcompany.com and give it a copy of its local ip
address - the nasboxcompany.com server sees the packet as coming from a
particular IP address (the address of the network's NAT router in a
typical small network), and it stores this pair of addresses. The
customer can then point their webbrowser at mynasbox.nasboxcompany.com,
and nasboxcompany.com's DNS server will see the query coming from the
same global IP address, and be able to return the specific local ip
address for that customer's box.

> Stupid, don't know if it's real (didn't bother to check). But, it
> should rely on the server with the quickest response. If one's down,
> to use the secondary, or so on. DNS already works fine as it is. If
> they want to check the closest geographical server, it would be better
> to have checks for other things. Anyway, doesn't matter what google
> wants to see, luckily they can't change the way it works (though I
> understand their influence on some providers). Personally, I'm not too
> concerned about this happening or being a requirement.

On second thought, were there similar attempt by Micro$oft (http-mail)
and Novell (ipx)?

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (x86_64 Ubuntu 9.10) Linux 2.6.32.7
^ ^ 17:53:02 up 3 days 1:59 1 user load average: 1.24 1.25 1.24
�借貸! ��騙! ��交! �打交! �打劫! �自殺! 請考慮綜� (CSSA):
http://www.swd.gov.hk/tc/index/site_...sub_addressesa

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...

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/namedroppe.../msg00133.html
http://ops.ietf.org/lists/namedroppe.../msg00140.html
http://ops.ietf.org/lists/namedroppe.../msg00156.html

Well, it's just a first draft.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktonKwACgkQ5jrP7hWxSO//pQCeJbgkQpU861O14POmEwXR1jdx
vxkAn3Z/90CLE/BxdWqZYpaOrBBnqket
=tz6l
-----END PGP SIGNATURE-----

On 03/02/2010 03:05, Moe Trin wrote:
> On Tue, 02 Feb 2010, in the Usenet newsgroup comp.os.linux.networking, in
> article<(E-Mail Removed)> , David Brown wrote:
>
>> 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.
>
> It certainly is a benefit to the advertising service, and the company
> that is paying them to get the word of their products/services to
> customers who may be interested. The way it is now - the server has
> to wait until the client connects before it knows which set of ads
> to serve - and not knowing this in advance means either having all
> content on all servers, redirecting, or having the server reach out
> and get the ``correct'' content.
>

That's correct. And while I have no more love for the advertising
industry than the average person, I have no objection to something that
helps them if it does no harm to anyone else. The only disadvantage is
perhaps that it will lower the cost of advertising, and that might lead
to more adverts.

>> 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.
>
> There are many solutions.
>

Indeed - Adblock is just one easy method.

>> 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.
>
> Even the authors admit it's going to increase the caching load on
> those DNS servers that may "support" clients in more than one
> geographical area - the "OpenDNS" being one example. Depending on
> what this service is actually used for, it can impact multi-national

I can see it being a particular issue for OpenDNS. Since google has a
rival system to OpenDNS, I suppose they are not going to be too
concerned about that...

> networks. My company is ``registered'' in New York state (whois
> data), has gateways and clients on five continents (what you'd see
> using traceroute or equal - assuming the firewall permitted such
> traffic), and we don't publish the location of every/any hosts.
> Ads are no problem, because our web proxy servers scrub content,
> but there are a shedload of other services/protocols that use the
> Internet besides web traffic.
>

Surely in cases like this, you could simply continue to use your
existing DNS servers and caches - you would then see no difference from
the current situation. But if you decided to move to new DNS software
with support for client IP tracking (perhaps to improve locality when
accessing websites that run through big proxying companies), you'd need
to arrange for it to work in your wide network.

>> 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.
>
> Proxy server addresses
>

Or NAT router address. Either way, that address is typically
geographically close to the client.

>> 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.
>
> The important thing is that this draft... standard quote from any
> such draft:
>
> Internet-Drafts are draft documents valid for a maximum of six
> months and may be updated, replaced, or obsoleted by other docu-
> ments at any time. It is inappropriate to use Internet-Drafts as
> reference material or to cite them other than as "work in progress."
>
> is unlikely to be adopted as it currently exists. Drafts may take many
> revisions before they get adopted, Quicky scan of the list of current
> drafts shows (among others)<draft-hixie-thewebsocketprotocol-68.txt>
> which is the sixty-NINTH try at one document. The "multicast DNS"
> protocol (similar to but intentionally incompatible with Avahi) went
> to draft-ietf-dnsext-mdns-47.txt, while the competing service supported
> by Avahi got to draft-cheshire-dnsext-multicastdns-08.txt before it was
> dropped.
>
> Old guy

I don't expect that this will be a quick change - even if it gains
popular support and the concept is refined so that "everyone" agrees on
it, it is going to take a very long time before it is implemented in
practice.