I think we’ve all seen that text on consumer electronics before. It means that if you crack open your TiVo or your Playstation, you shouldn’t expect to find a product designed for ease of maintenance or repair.
The IETF should have slapped that sticker on DNSSEC, too. The DNS Security Extensions, which provide authentication and integrity-checking of zone data, are critical to securing DNS infrastructure. But some implementations of DNSSEC seem to have been designed with the explicit goal of driving DNS administrators to drink. With early BIND name servers, for example, signing a zone for the first time was a 12-step process (by my reckoning), and most of those steps involved the command line. (Even with current Microsoft DNS Servers, the situation is still much the same.)
Providing more evidence that getting DNSSEC right is tricky, Verisign yesterday apparently muffed a key rollover for the .gov zone, rendering signed data in .gov unvalidatable. That amounted to an inadvertent denial of service, but luckily one that affected only those organizations who care the most about .gov data.
But my point isn’t that Verisign doesn’t know DNSSEC–they do, better than almost any other company. My point is that even the pros can mess up, because DNSSEC is hard.
Since the introduction of DNSSEC, ISC and Infoblox and others have invested resources to automate DNSSEC to the extent possible. That automation is, in my opinion, an absolute necessity when deploying DNSSEC. You don’t want to have to follow a multi-step cookbook of dnscmd commands in order to roll over a key (yo, Microsoft!); you want to specify how often keys should be rolled over and receive a nice notification when the rollover completes.
I hope that if you’re planning to deploy DNSSEC, you won’t be discouraged by Verisign’s little accident, just further convinced that an automated solution is the way to go.
