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.)
If you’re curious as to the nature of the vulnerability, it works like this: A querier sends a recursive query to our validating name server with the DO and CD bits set. The DO (DNSSEC OK) bit says, “Please return DNSSEC records,” while the CD (Checking Disabled) bit says, “You don’t need to validate any DNSSEC records in the response before sending them to me, because I’m going to do that myself.” The problem is that our validating name server would add records from the response’s Additional Data section to its cache without validating them. That’s not the behavior prescribed by the RFCs; that data should be passed through to the querier but only added to the cache if it validates.
ISC’s advisory suggests that restricting access to recursion on the vulnerable name server is a workaround, but it’s not a complete fix, since it’s possible an authorized querier could send a query that would induce a vulnerable name server to cache unvalidated records, or that someone with access to an authorized querier acting in collusion with a hacker could do the same. If you do DNSSEC validation, the real solution is to upgrade.
