I realized last week that I'd never actually traced all the queries sent and responses received by a recursive name server resolving a domain name in a zone signed with DNSSEC.  I decided to trace the recursive resolution of an RRset in a signed top-level domain, since I wanted to see the "chain of trust" in action.  I knew .org was signed and figured isc.org (the Internet Systems Consortium's domain) would probably already have a DS (Delegation Signer) record.

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

One brief note about yesterday's DDoS vulnerability:  This is the latest in a long line of vulnerabilities caused, arguably, by a development philosophy ISC employed in BIND 9, which amounts to, "If you see something funky, exit."

Read more...

In case you haven't seen the news yet, there's a serious new vulnerability in BIND 9.  A carefully tailored dynamic update can crash your BIND 9 name server.  Administrators of BIND 9 name servers - even those that don't allow dynamic updates - are advised to upgrade immediately, as exploits are already public.  You can find more information on ISC's web site.  ISC has released BIND 9.6.1-P1, 9.5.1-P3 and 9.4.3-P3 to address the vulnerability.

Read more...