In a blog entry late last month, I briefly mentioned an issue with stub resolvers that naively send queries for AAAA records (the DNS record type for IPv6 addresses) but then pass the addresses to applications that can’t consume them, causing timeouts.  (I owe credit to Igor Gashinsky at Yahoo!, from whoseIETF presentation I learned about the issue.)  Here’s a little more on that subject.

Many popular web sites that support IPv6 today use separate domain names to point to their sites; witness www.v6.facebook.com and ipv6.google.com. That scheme won’t hold up over time, though.  As IPv6 becomes pervasive, companies won’t willingly slap protocol identifiers in front of their domain names:

-       “For IPv4 customers, go to www.facebook.com.

-       For IPv6 customers, go to www.v6.facebook.com.”

Read more...

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