My pleasure Milton, I strongly believe that this is one of the benefits of being part of a multidisciplinary group like ours, where each one has a venue and opportunity to contribute from its experience and skill sets. While my forte is essentially on the technical side I'm learning a lot about governance and regulations from the rest of the team. Yes the new public DNS resolver service from Google is an interesting alternative to obtain recursive name resolution from a "neutral" provider and avoid some of the manipulation of DNS responses. The Google DNS service has triggered very interesting and lengthy discussions in the network and dns operations mailing lists, including some folks freaking out about Google world's domination. The PCMag article is right on the performance tests, in most of the cases there is not a substantial performance gain using Google services and in some particular cases performance is much lower. But talking with some Google insiders (and Google made it public that they will for sure collect statistical information not associated with other Google services or accounts) by collecting and analyzing usage statistics they will be able to have a better understanding about how the entire system works and where are the bottlenecks that need to be fixed to provide better performance. Anyway, Google has a large group of visionary and smart people and sooner or later they will find the way to monetize that additional knowledge. This is why I insist sometimes that the root zone scaling study is important, but we also need to focus on how to make the entire system better and more secure and reliable. This is just one of many initiatives at Google to improve web browsing performance and end users experience. Another initiative on the browser side already implemented in Chrome (open source and available to other software vendors for implementing in their products) is DNS pre-fetching (http://blog.chromium.org/2008/09/dns-prefetching-or-pre-resolving.html) which basically consists in resolving some names before you actually need them so when you click on a link you don't have to wait for the DNS response. Here is a video from Jim Roskind (ex-Netscape) explaining about DNS pre-etching or pre-resolution and how it improves web browsing performance even when it may increase overall load on the DNS. http://www.youtube.com/watch?v=FhDDwmOyRmk Another Google initiative on the protocol side is called SPDY (http://dev.chromium.org/spdy/spdy-whitepaper) Think about how old HTTP (Hyper Text Transport Protocol) is and how the type and volume of content has changed over the last 10 years making now HTTP not the most efficient way of moving that content. One thing we should keep an eye on, is how some ISPs react to this new service, I'm very concerned that many will impose more strict filters to avoid that you use other nameservers than the ones offered by them. Regards Jorge On Sun, Dec 6, 2009 at 9:53 AM, Milton L Mueller <[log in to unmask]> wrote: > Jorge: > Nice that you're capable of educating the list on some of the interesting games played with DNS. > One way to avoid these games is to use a specialized DNS provider. Open DNS (which has both a paid and a free service) is one of these, and now Google has jumped into this market. > A good article summarizing the benefit or lack thereof of these services is here: > http://www.pcmag.com/article2/0,2817,2356703,00.asp > > --MM > > ________________________________________ > From: Non-Commercial User Constituency [[log in to unmask]] On Behalf Of Jorge Amodio [[log in to unmask]] > Sent: Thursday, November 26, 2009 2:57 PM > To: [log in to unmask] > Subject: Re: [NCUC-DISCUSS] Sitefinder > > There is a good article from Paul Vixie about "What DNS is not" at > http://queue.acm.org/detail.cfm?id=1647302. > > An extended version of Paul's article is featured in the December > issue of Communications of the ACM. > > Also we are having an interesting discussion on different technical > forums about this and similar issues > where some ISPs are not only tampering with DNS traffic but using HTTP > proxies to direct you to sites/pages > of their choice when the original DNS response to a query returns that > a given domain name or host does > not exists. > > Doing that, a non-existent site such as hardcoreporn.icann.org can be > redirected to whatever the ISP chooses. > > This is really a very BAD practice not only for technical reasons but > also for the potential liability and > damage they can create using a domain name that is not under their > control while the real domain > administrator has not a bit of clue that this is going on. > > Somebody also argued that this trick is letting them use domain names > that do not exist without > registering and paying for them, which also have huge security implications. > > Let me give you a few examples to illustrate how this works and how > far some ISPs are going with this. > (DIG is a tool we normally use in a Unix machine to query the Domain > Name System). > > First example, using the name servers of my ISP (Time Warner/Road > Runner) I'll look for address > information for www.this-name-does-not-exist.com which actually does > not exist and should > return a NXDOMAIN. > > A non-tampered response should say: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN > > Instead the TWC/RR server says: > ; <<>> DiG 9.6.1-P1 <<>> www.this-name-does-not-exist.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45528 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.this-name-does-not-exist.com. IN A > > ;; ANSWER SECTION: > www.this-name-does-not-exist.com. 10 IN A 24.28.193.9 > > ;; Query time: 66 msec > ;; SERVER: 24.93.41.127#53(24.93.41.127) > ;; WHEN: Thu Nov 26 12:53:47 2009 > ;; MSG SIZE rcvd: 98 > > Giving you the 24.28.193.9 IP address > > If you try to connect with your browser directly to that address you > will get a response saying that > the page does not exist (classic HTTP 404 error), but if from your > browser you try to go the > the URL http://www.this-name-does-not-exist.com, your browser will > connect to 24.28.193.9 > and request the URL that will land you on a Road/Runner Yahoo search > page with a list > of sponsored links (people pay for them) and other links that may be > related to the URL. > > OK, the previous example is for a 2nd level domain that does not > exist, lets see what happens > if we try to go to hardcoreporn.icann.org. > > ; <<>> DiG 9.6.1-P1 <<>> hardcoreporn.icann.org > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54420 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;hardcoreporn.icann.org. IN A > > ;; AUTHORITY SECTION: > icann.org. 10800 IN SOA dns1.icann.org. > hostmaster.icann.org. 2009112305 10800 3600 1209600 86400 > > ;; Query time: 64 msec > ;; SERVER: 24.93.41.127#53(24.93.41.127) > ;; WHEN: Thu Nov 26 13:20:08 2009 > ;; MSG SIZE rcvd: 91 > > The query returns NXDOMAIN from Time Warner's server 24.93.41.127 and shows > dns1.icann.org as the authoritative server for icann.org. Nothing > wrong here, at least > this ISP respects the authoritative answer from the current domain administrator > for that name. > > But lets see how far other ISPs go, in this case Telefonica de > Argentina (note: I had to ask a friend > who is a customer of Telefonica to do the queries because they filter > queries to their name servers > if you are not a customer). > > Lets look again for the address record for hardcoreporn.icann.org > using Teleconica's server > 200.63.155.204: > > ; <<>> DiG 9.6.1 <<>> hardcoreporn.icann.org. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46746 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;hardcoreporn.icann.org. IN A > > ;; ANSWER SECTION: > hardcoreporn.icann.org. 10 IN A 208.70.188.15 > > ;; Query time: 265 msec > ;; SERVER: 200.63.155.204#53(200.63.155.204) > ;; WHEN: Thu Nov 26 16:45:59 2009 > ;; MSG SIZE rcvd: 78 > > As you can see instead as returning NXDOMAIN like the server from Time > Warner in this case > Telefonica returns the 208.70.188.15 IP address, which is a similar > page with a Yahoo search > box, etc. > > This is extremely bad because Telefonica has not right whatsoever to > say what names are existent or > not under the ICANN.ORG domain, also while they redirect you to a > Yahoo search page they can redirect > you to whatever page/site they please even create fake sites that > people may assume are valid ICANN > sites because are under the ICANN.ORG domain. > > What can be done then ? (that's part of the discussion going on in > NANOG and other > technical forums and related also to the memorandum from ICANN). > > First of all ICANN has no contractual relationship with these ISPs, so > there is no contract > they can enforce to stop this crap. We can argue that this has to do > with "preserving and enhancing > the operational stability, reliability, security, and global > interoperability of the Internet" as stated > on ICANN's bylaws. > > Get DNSSEC deployed, while is not a bullet-proof solution and has some > burden and > other side effects (like most US pharma products), we'll have the > choice to only accept DNS > responses that have a valid signature from the authority for a given domain. > > Class Action Suit "All Internet Users vs All Bad ISPs", probably not > feasible (EFF ?) > > Disseminate information, create conscience and bad publicity for ISPs > doing this ? > > Bypass the ISP name servers and use servers that don't do this ? > doable for a power > or savvy user, I'd not know how to tell grandma how to configure her > resolver, also > some ISPs even filter DNS traffic to other servers so you are forced > to use theirs. > > Regards > Jorge > > PS. Happy Thanksgivings for those who celebrate Turkey Day today. >