Back in October 2010, I posted Whither DNSSEC? which speculated on DNSSEC's second act.  If the Internet had a fully DNSSEC-secured namespace, we could add email authorization data and SSH fingerprints to DNS.  Two commenters, Chris Angelico and John Speno, suggested storing web site certificates and certs for signing applets in DNS, too.

Either Chris and John were remarkably prescient or they knew about the work being done in the IETF's DANE Working Group.  DANE would store web site certificates in records in DNSSEC-signed zones, allowing web site administrators to generate and sign certificates themselves, without the need for a Certification Authority.

Read more...

A few weeks ago, the press announced a possible threat against the Internet's DNS infrastructure by the hacking group Anonymous.  Anonymous allegedly planned to mount a DDoS attack against the root name servers to "shut the Internet down," in order "to protest SOPA, Wallstreet [sic], our irresponsible leaders and the beloved bankers who are starving the world."

While many people in the DNS community are skeptical of the validity of the threat - scheduled (coincidentally?) for March 31, the day before April Fools' Day - it's still interesting to consider whether such an attack could succeed.

At first glance, the root name servers appear to be an easy target:  There are only 13 of them, and their IP addresses are widely known.  How hard could it be to take down 13 name servers simultaneously?

Read more...

For another angle on the risks of browser prefetching, read this paper by Srinivas Krishnan and Fabian Monrose.  The authors describe algorithms that allow a hacker with access to a shared name server's cache to determine--with remarkable accuracy--what terms users with prefetching browsers are searching for.

Read more...

Wired's Webmonkey column today features a short article on some new behavior in the latest Google Chrome beta:  prefetching and prerendering web content.  Basically, if Chrome autcompletes the URL you're typing, it'll start loading web content for that URL, even though you may end up typing something unexpected and different.

In the best case, of course, this could save you a little time - especially if you type as slowly as I do - because some portion of the web page will already have loaded by the time you finish typing.  In the worst case, the URL you type isn't what Chrome anticipated so it simply discards the prefetched content.  No harm done, right?

Except that the web content had to be served by a web server somewhere on the Internet and transmitted across said Internet to your web browser.

Read more...

Apparently there's a "massive" attack against DNS infrastructure underway in Brazil.  Much of the initial reporting refers to the attack as cache poisoning, though Rod Rasmussen correctly points out that it's not "classic cache poisoning":  the culprits allegedly worked at a Brazilian ISP and used default passwords to change the DNS settings on customer premises equipment, and modified the configurations of the ISP's recursive name servers to direct customers to bogus sites.  ("Classic" cache poisoning attacks, of course, require no such special access to resolver or name server configuration to carry out.)

Besides raising the upsetting specter of collusion by the employees of ISPs, this threat brings us back to DNSSEC's "last mile" problem.  While this would seem like a textbook example of the kind of threat DNSSEC should protect against, in fact DNSSEC wouldn't have been much help to most of the ISP's subscribers.  Without a secure channel between a stub resolver, like the one on the laptop I'm typing on, and the local recursive name server, there's no foolproof way of determining that your name server has been replaced.

Read more...