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