I don’t know about you, but I’m starting to think that DNSSEC being so hot these days is a mixed blessing. Yes, it’s wonderful that after so many years there is finally broad consensus for making DNSSEC happen. But being so prominent also means the protocol is taking shots from those who don’t want to make the necessary software, hardware and operational modifications needed. And DNSSEC has taken some shots from those who just want to be contrarian.

Last year this manifested itself as a prediction that DNSSEC would actually make the DNS system LESS stable than before. Now that sounds strange, doesn’t it?

What’s causing this knee-jerk negativity is the onset of DNSSEC in mainstream operations. Now that the time for talking is over and the time for doing is upon us, administrators are actually grappling with the challenges involved with implementing DNSSEC. And human beings being human, there are now boo birds suggesting that all the new processes, new tools, new code, and the new players means that time-tested network elements can no longer be counted on to be reliable.

Network administrators need to be more reasonable. Yes, there WILL be problems in software, hardware, and operational practices. All these new elements will cause networks to experience some level of disruption. Many privately reported and noticed events have occurred, and of course, what’s in the public domain is usually just the tip of the iceberg.

Here’s the kind of stuff I’m talking about. These are from last September, because well, it’s taken me a while to find the time to write this up. But they illustrate the point.

The first report indicates that newly minted operational practices are encountering errors. To the credit of the organization involved, no public impact occurred because the situation was discovered in an internal testing environment.

Date: Wed, 22 Sep 2010 12:37:52 +0200

Yesterday, 21 September, we were scheduled to perform a roll-over of Key Signing Keys (KSKs) of all our signed zones.

However, during the roll-over we had some issues with our signing infrastructure, which caused some zones to be generated with expired signatures. We therefore rolled back to the state before the roll-over.

In order to allow proper resolution of the problems we encountered, we are delaying our roll-over to the end of October. We will announce a new date before the event.

[Full thread: https://www.ripe.net/ripe/maillists/archives/enum-wg/2010/msg00020.html]

Here’s one that is a bit more specific and is in reaction to an external report of a misstep. Fortunately, missteps at this time have a very small impact and generally are observed by highly informed participants. What is more interesting is that while the cause may have been rooted in some new hardware, the new backup plan apparently had a hole.

Date: Sun, 12 Sep 2010 17:58:13 +0200

Apologies for taken some time to respond. Our main signing system had a failure. We are currently investigating if it is related to the ORACLE (SUN) SCA6000 card on it. Additionally, we decided to fail-over to the backup system just to be on the safe side. Naturally, we did check if that system was up and running and if the DNSSEC data on that system was valid, which was the case. Apparently, OpenDNSSEC’s state machine on the two systems were not completely in sync, and after failing over we noticed the alternate zone signing key. We are investigating the exact cause of the mismatching ZSKs.

[Full thread: http://dnssec-deployment.org/pipermail/dnssec-deployment/2010-September/004368.html]

Finally, here’s one from last month. Because of the emergence of DNSSEC, keeping up to date with all software is more and more important. New cryptographic parameters are added, new strategies for validating data, as well as new ways to find some of the data are added. With all this newness, software refreshes are happening more frequently, putting pressure on the code base.

Wed Feb 2 15:21:09

Following the deployment of DNSSEC in the .net zone, Verisign became aware of issues experienced by users of certain BIND versions when used as a recursive name server and configured for validation.

A user of a BIND 9.7.0-P2, configured for validation with the root trust anchor, experienced SERVFAIL responses for all unsigned .net domains afterthe .net DS record was published in the root zone and after .net NS records expired from his name server’s cache.

[Full thread: https://lists.dns-oarc.net/pipermail/dns-operations/2011-February/006724.html]

So what’s the conclusion? It’s this—that the prediction that DNSSEC would (initially, during implementation) bring more instability to the DNS was correct. These three examples are just a few of the reported events, so I’m not jumping to a conclusion based on a few freak events.

But does that mean DNSSEC isn’t going to happen? In my opinion, absolutely not—it will happen. Apparently too many people have forgotten is what growing pains feel like, since the DNS went decades with virtually no changes or improvements.

DNSSEC eventually will be there to benefit the end user, providing critical data to allow the consumer of the information to have trust the data they receive. The end user benefits, not (necessarily) the producers of the online content. This is why the “business case” for DNSSEC historically has been hard to make, and why implementation has languished for so many years.

The Internet has exploded over the past 20 years, and has become indispensable to commerce, business and personal expression. It’s time for all the players in the Internet infrastructure marketplace to look beyond parochial interests, and make sure we get this right. Stop complaining, and do what’s needed to ensure millions of online consumers don’t lose faith in cyberspace.

We can’t rush through this implementation period. DNSSEC is not a race to see who gets up and running first, or who gets in place before the “big hitter” (.com) finally is signed. The period of maturation will not end with full adoption of DNSSEC across TLDs either, not even with the pending deployment of .com.

So the next time you see an article or a post saying “DNSSEC - it’s a failure, it’s over,” think about how it went the last time your organization deployed a major new technology. And also, try to remember the stakes involved in getting this right.