Remember back in September 2009, when I posted this blog entry on the importance of automation?  No?  (I don’t really blame you.  I only remembered that I’d posted something about automation; I had to re-read it to recall exactly what I’d written.)  My point was that automating as much as possible of the process of administering DNS was about to get even more critical with broader adoption of DNSSEC.

With DNSSEC-signed zones, there are all sorts of tasks to remember:  Re-sign your zone after you make any change to zone data.  Re-sign your zone to refresh signatures before they expire.  Roll your Zone-Signing Key over monthly.  Roll your Key-Signing Key over annually.  Oh, but be sure to wait the requisite amount of time during the rollover for old keys to time out of remote caches or for new keys to propagate.  Then multiply all of these tasks by the number of signed zones you have, and add the complexity of maintaining different re-signing and rollover timers per zone.  That way madness lies.

Read more...

After we published the results of the 2010 DNS Survey last year, I spoke with reporters from several technical magazines and web sites about what the numbers meant.  Many asked how long I felt it would take until we saw widespread adoption of DNSSEC.   The answer depends, of course, on how you define “widespread,” and frankly, I’m not sure any prediction I might hazard is particularly valuable.  But in thinking about the question, I realized that I do believe strongly that 2011 is a make-or-break year for DNSSEC.

In just a couple of months, when VeriSign signs .com, nearly all of the major impediments to broad implementation of DNSSEC will be gone.  The root zone and the three big gTLDs, .com, .net and .org, will have been signed.  Many European ccTLDs have already been signed.  Stable implementations of DNSSEC are available in multiple name servers, including recursive (BIND and Unbound) and authoritative (BIND and NSD).  Commercial products, including Infoblox’s, support and simplify DNSSEC, too.  Documentation on DNSSEC is widely available, in the form of presentations, RFCs, and even books.

Read more...

The results of the 2010 DNS Survey come out this week.  I know you've all been waiting with bated breath, so here’s a summary of some of what I thought were the most interesting results:

We again examined a random sample of subzones of the Big Three gTLDs, .COM, .NET and .ORG.  As in previous surveys, we looked for DNSSEC resource records that would tell us whether these subzones were signed.

Read more...

On my flight from San Francisco to London this past weekend, I passed the one million mile mark.  Those miles were logged over the course of years of flying with United and its partner airlines, but more than half of it was racked up while working for Infoblox, and a good portion of that while talking about DNSSEC.

What does one million miles of flying get you?  On United, truthfully, not a whole lot.  I’m now Premier Executive for life, which means that I get to board planes early and take up all your overhead storage space.  I get to sit in the Economy Plus section of the aircraft for free.  Woo.  For the real perks—lifetime 1K status, equivalent to flying 100,000 miles per year—I need to fly three million miles.  At the rate I’m earning miles, I’ll be so old by the time I hit that milestone that I won’t want to fly anymore.  And accruing miles any faster will earn me free membership in the Red Carpet Club for Recently Divorced Men.

But one million miles of flying, or whatever fraction of it I devoted to talking about DNSSEC, seemingly does buy you some progress in advancing the cause.

Read more...

Stu Bailey, Infoblox's CTO, forwarded me this article about a hidden feature in the latest builds of Google’s Chrome browser.  It allows users to configure Chrome to use a different set of name servers from those that their system uses.  This might come in handy if, for example, your IT organization locks down the ability to modify your system resolver settings and you think you could get better performance from a closer/faster/shinier set of name servers than the ones IT provides.  I think Google’s ulterior motive for introducing the feature may have been to allow users whose default name servers perform NXDOMAIN redirection to configure Chrome to query the Google Public DNS servers, which notably don’t rewrite NXDOMAIN responses.

Read more...