DNS Fool

DNSSEC Deployment Moves Forward, Slightly

2008-12-22T16:31:18Z

Although DNSSEC has been in the works for over a decade now, until recently there has been little motivation to begin working on a widescale deployment. Of course, after Dan Kaminsky’s announcement this past summer there is now a scramble to increase the security of the domain name system.

Earlier this year the U.S. Government issued an order for the .gov domain to be signed by January 2009. Furthermore, all subdomains of .gov are required to be compliant by December 2009. According to IETF participants the first goal has been met, and the .gov domain is already signed ahead of the deadline. There are also immediate plans to sign the .mil domains used by the U.S. Military.

The directive by the U.S. Government was the first major push for DNSSEC deployment and it has spurred action by other big players in the DNS world. Recently several major DNS vendors announced they had formed the DNSSEC Industry Coalition to help facilitate DNSSEC deployment. The member venders are VeriSign, The Public Internet Registry, Nominet UK, Afilias, NeuStar, The Foundation for Internet Infrastructure, and Educause.

In October the U.S. National Telecommunications and Information Agency (NTIA) issued a Notice of Inquiry asking for feedback regarding the deployment of DNSSEC. The responses were overwhelmingly in favor of a quick and widespread DNSSEC deployment, which is not surprising considering a large number of the respondants represent organizations who stand to profit from such a rushed deployment.

However, not everyone is convinced that DNSSEC is the best solution at this time. Until the root servers are signed there is no way to authenticate the DNS session and verify the integrity of the entire response. This is part of the reason that the IETF has yet to decide on an immediate solution to the problems raised by the bug Kaminsky found. Paul Hoffman put it simply (PDF):

“Let’s say the root is signed tomorrow. Let’s say all the important top-level domains are signed. It’s still no good unless all of the domains are signed. You can’t just deploy DNSSEC. You have to deploy it universally.”

This is the heart of the “chicken and egg” problem that DNSSEC advocates have struggled to fight for years. Until it is deployed everywhere, DNSSEC isn’t really 100% effective. And no one wants to deploy a solution that isn’t 100% effective, especially when it comes to an issue of security. As of December 20, 2008, DNSSEC has yet to be deployed to even 15,000 domains.

No matter what route the Internet community decides to take to secure the DNS, we still have a very long road ahead of us.

U.S. Government Mandates DNSSEC

2008-08-27T23:18:04Z

In response to claims of “foot-dragging” with regards to DNS security, the United States government has ordered the administrators of all .gov domains to implement DNSSEC before January 2009.

DNSSEC is a somewhat controversial set of extensions to the DNS protocol designed to provide protection from forged data. Although it was first proposed in 1995, DNSSEC has not been widely adopted and as of a few weeks ago only 99 .com domains were using it (here’s a map of worldwide deployments). Of the many concerns preventing deployment, the two most controversial have been “zone enumeration” and the issue of who controls the master keys.

The matter of key ownership was raised again last year when the U.S. Department of Homeland Security announced that it wanted to manage the root keys. Operators of many other top level domains took issue with this, and proposed that ICANN/IANA be tasked with root key management.

Update: A PDF of the mandate is available from the Whitehouse website.

Looking Back on Kaminsky’s DNS Bug

2008-08-18T17:14:17Z

A lot has happened in the world of DNS since July 8th. Of course, that is when Dan Kaminsky revealed his now famous DNS bug and the patching panic began. Since that time there have been many explanations of the bug, along with much discussion about also how the bug can be exploited and why it is a big deal. I’ve contributed to this discussion in the form of two articles posted on LinuxJournal.com:

Understanding Kaminsky’s DNS Bug - An overview of how the bug can be exploited.
The DNS Bug: Why You Should Care - A look at the importance of this bug to everyone on the Internet.

It isn’t often that the New York Times covers topics like the Domain Name System, but this security issue was enough to warrant two articles on the award winning news site.

It’s been said many times by many people, but it really is amazing that this bug went undiscovered for 25 years. Once it is explained it just seems so simple. How could we not have seen it?

But how do we know that someone else didn’t discover this bug long ago? For all we know, a bad guy may have been exploiting this issue for years, undetected. This is why it is so important that the Internet community embrace full-disclosure security practices. Information exists, and it’s better for it to be available to everyone, publicly, than to just the bad guys, privately.

Even if the bug had not been known before, and Dan didn’t accidentally find it, how do we know a bad guy wasn’t on the brink of discovering it? How would the news media have reacted to the story in that case?

Let’s just be glad Dan Kaminsky is on our side.

BIND Addresses Performance and Stability Issues

2008-08-02T14:43:27Z

The initial patches provided for better port randomization in BIND caused it to experience performance issues. Today ISC has provided a second patch for each of the Unix versions of 9.3.5, 9.4.2, and 9.5.0 that addresses the problems introduced in the first patch. As stated in the release notes, this update provides:

performance improvement over the P1 releases, namely
- significantly remedying the port allocation issues
- allowing TCP queries and zone transfers while issuing as many
  outstanding UDP queries as possible
- additional security of port randomization at the same level as P1

Additionally, the patch for 9.5.0 includes “fixes for several bugs in the 9.5.0 base code.”

Those using BIND for Windows will need to wait a little longer for the performance fixes as these patches do not fix the issues on that platform.

The updated versions can be downloaded directly from the BIND page on the ISC website.

BIND Issues on High Traffic Caches

2008-07-30T16:12:08Z

ISC has issued a statement about the performance issues that many BIND administrators are seeing.

Evidently, the new security updates to BIND are causing problems in high traffic recursive environments (more than 10k queries/sec). Specifically, the issue exists with BIND 9.5.0-P1. Their statement recommends that systems affected by this be immediately downgraded to BIND 9.4.2-P1, which does not exhibit the problem.

There is speculation that this is the reason that Apple has delayed providing an update for Mac OS X Server. It’s been three weeks since the exploit was first announced and Apple has been noticably quiet among the companies publishing security updates.

An Exploit is in the Wild

2008-07-24T02:51:32Z

Well that didn’t take long.

Mere days after the details of the recent DNS attack were made public there is already an exploit out in the wild. HD Moore and I)ruid have added an exploit to the Metasploit project, a popular penetration testing framework. These are the good guys, but the bad guys have the same access to the code as everyone else.

It doesn’t seem like anyone outside DNS and networking communities really understand how significant this issue is. Noted DNS expert Cricket Liu has suggested that this may be the biggest DNS vulnerability in the history of the Internet, and certainly the biggest vulnerability right now.

Also, there’s a good interview with Dan Kaminsky over at Wired where he talks about discovering the vulnerability and reiterates that “this (attack takes) ten seconds to hijack the net”.

Dan provides a “DNS Checker” on his website to see if your DNS is vulnerable. Please go check. If you find that you are not safe, OpenDNS is ready for your traffic. If you are a network administrator, now might be a good time to consider switching to djbdns.

DNS Attack Details Come Early

2008-07-24T02:49:48Z

It was just 14 days ago that Dan Kaminsky announced that he had found a critical security flaw in DNS, but that the details would be kept secret until he took the stage at Black Hat on August 6th. This 29 day gap between the announcement of the discovery and the detailed description of the attacks was to give ISPs and software vendors time to update their systems so that more people on the ‘net would be protected when exploits hit the wild. Also, it would give Dan’s Black Hat talk a lot of well deserved attention.

That all changed yesterday when Halvar Flake speculated what the attack may be. He wasn’t sure of it himself, but as it turned out his guess was pretty close. The Matasano team posted an entry on their blog that gave details of the attack, which quickly spread around the Internet. Although the post has since been taken down, and the Matasano team has apologized, the text of the post is available all around the Internet. The cat is out of the bag, so everyone needs to make sure their systems are patched right away.

The attack is interesting indeed, and it is amazing that no one has considered this approach until now. If you have a few minutes, you may want to read what is available.

A Big Day for DNS Security

2008-07-09T19:37:57Z

Dan Kaminsky has done it again.

Kaminsky found a security vulnerability in the design of DNS itself. Yea, let that sink in. The problem was in the DNS protocol, not just certain implementations. That means BIND is affected (of course), Microsoft DNS is affected, and so on. A full list of affected systems is available in the CERT advisory.

Something to note is that BIND 8 is not being patched. If you are running BIND then you should consider upgrading to BIND 9 immediately.

Several systems are not susceptible, including dnscache from djbdns, OpenDNS, and PowerDNS. Kaminsky comments on how Dan Bernstein was years ahead of everyone else with djbdns:

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that’s no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got “lucky” here — he ended up defending himself against an attack he almost certainly never encountered.

Here is a PDF of the executive overview of the vulnerability.

This is being called the largest coordinated security update in the history of the Internet, and it probably is. Kaminsky coordinated the announcement of the security issue with all the major vendors, allowing everyone to have patches available at the same time and prevent chaos across the Internet.

The Internet is lucky to have Dan Kaminsky looking out for us.

More Free DNS Utilities

2008-06-27T07:05:36Z

Bite my Bytes has collected a list of free DNS reporting utilities.

ICANN and IANA DNS Compromised

2008-06-27T07:01:32Z

ICANN and IANA were the victims of a DNS redirection attack this week.

Turkish crackers were able to take over the icann.com, icann.net, iana.com and iana-servers.com and redirect them to a hosting account at atspace.com.

Zone-H is hosting a mirror of the defacement.