Google wants to see client addresses in DNS queries
in [Linux Networking]
|
From: David Schwartz on 2 Feb 2010 02:50 On Feb 1, 11:22 pm, 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. 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? DS
From: Tobias Nissen on 2 Feb 2010 03:09 David Schwartz wrote: > On Feb 1, 11:22 pm, 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. > > 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-vandergaast-edns-client-ip-00.txt ² http://ops.ietf.org/lists/namedroppers/ http://news.gmane.org/gmane.ietf.dnsext ³ http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00079.html http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00090.html
From: David Brown on 2 Feb 2010 03:30 On 02/02/2010 08:48, David Schwartz wrote: > On Feb 1, 3:04 am, "Man-wai Chang to The Door (24000bps)" > <toylet.toy...(a)gmail.com> wrote: > >> Does this suggestion have a Dark Side? >> >> http://www.linuxtoday.com/infrastructure/2010012903135NWNTSD > > 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.
From: Chipmunk on 2 Feb 2010 03:37 David Schwartz wrote: > On Feb 1, 3:04 am, "Man-wai Chang to The Door (24000bps)" > <toylet.toy...(a)gmail.com> wrote: > >> Does this suggestion have a Dark Side? >> >> http://www.linuxtoday.com/infrastructure/2010012903135NWNTSD > > 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 Unless of course you want to target marketing by geographic location, i seriously doubt this has anything to do with speed.
From: Man-wai Chang to The Door (24000bps) on 2 Feb 2010 04:53
> 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_pubsvc/page_socsecu/sub_addressesa |