Waaaay back when I ran hp.com, I had what I only now realize was an enviable position:  I was HP’s hostmaster (the somewhat-ceremonial title given to the person responsible for a zone) but not much else.  I dabbled in NTP and ran a big mail relay, but the bulk of my responsibility was DNS.  From when I got to work in the morning to when I left in the evening, I could concentrate on DNS.

At the time, I didn’t realize what a luxury that was.  I figured every big company probably had a person dedicated to DNS.  And in those days, some did. Partly, this was because we hostmasters could get away with it.  DNS was such a black art that you could simply assert that it took up most of your time and your management wouldn’t know any better.

How the times have changed.  I’ve had the opportunity to meet the folks responsible for DNS at many big companies, but I hesitate to call them “hostmasters”—not because they don’t deserve the customary title, but because it sells them short.  These people run routers, switches, firewalls, mail servers, and more.  Almost no one has the luxury of specializing in DNS any more.  The economic climate dictates that we all take on more responsibilities to make our employers more competitive.

Read more...

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