A system administrator I knew at HP Labs, Mike Rodriquez, named his personal workstation "walstib."  Mike explained that it was an acronym for "What A Long, Strange Trip It's Been," which, he said, was a kind of motto among Deadheads.  (I gather it's a line from one of the many indistinguishable Grateful Dead songs.  Sorry, Mike.)

So "WALSYIB" is my acronym for "What A Long, Strange Year It's Been."  (And yes, I realize that I used a similar title for a previous blog post.)  2009 was a productive year:  We made more progress in deploying DNSSEC in the last 12 months than in the previous 10 years.  But we saw more attacks on DNS infrastructure, including cache poisoning attacks in the wild.  And we saw the discovery (and subsequent patching) of more vulnerabilities in BIND.

Read more...

Last week, Neustar announced an interesting new feature to their zone hosting service, called the DNS Real-time Directory.  In an effort to address some of the shortcomings of DNS's loose coherence, Neustar is publishing changes to the zones they host on their constellation of authoritative name servers through Amazon's EC2 service.  Subscribers, including OpenDNS, are notified of those changes and can remove outdated resource records from their recursive name servers' caches in response.  This would help avoid the recent mess caused by the accidental appending of an extra ".SE" to domain names in Sweden's .SE zone:  While the problem was fixed on the authoritative name servers right away, the operational effects lingered for up to a day--the TTL on resource records in the .SE zone, and hence the maximum time recursive name servers would cache the bogus records.

Read more...

With the press frenzy over Google's announcement of their Public DNS Service, you'd think that they'd announced that they had taken over running the root name servers.  At the very least, the press is presenting it as a power grab, a way for Google to insert themselves into still more Internet transactions.  (I'm sympathetic to this interpretation, incidentally.)  Others have suggested that Google's looking to replace the Internet's DNS infrastructure entirely, and possibly introduce new, private top-level domains.  (I'm skeptical about this.)

What is Google really doing?  Put simply, they're offering recursive name service from their cloud, based on their own implementation of a recursive name server.  From the writeup, they included nearly every anti-spoofing mechanism in the book in their name server, which means it should be highly resistant to cache poisoning.  I say "nearly" because they don't support the DNS Security Extensions, so they can't take advantage of the long-term solution to cache poisoning, which is being deployed either "soon" or "now," depending on what part of the namespace you live in.  They also pre-fetch information about popular domain names, which should provide better performance than your average recursive name server.

Read more...

Just yesterday, ISC announced the release of several versions of BIND to address a new vulnerability.  The vulnerability could allow unsigned data to be cached on a recursive name server configured to perform DNSSEC validation.

While that's alarming, it's not a systemic problem with DNSSEC; it's simply a flaw in BIND's implementation of DNSSEC.  (How could it be anything else if it was addressed by releasing new versions?)  Implementations of the latest incarnation of DNSSEC are still relatively new, so it should come as no surprise that we're still finding flaws.  (I'm proud to say that this particular defect was found by Michael Sinatra, who works for my alma mater, Berkeley.)

Read more...

Most of the results of our recent DNS Survey were pretty scary, especially the news that nearly 80% of the name servers we found in our sweep of 5% of the Internet's address space were open to recursion.  But the results contained some good news, too, and for that we should be thankful.

Read more...