Over the past few years – I can’t remember exactly when, which is part of the problem – I’ve become alarmingly forgetful. I’ll get up, walk across the building to do something, and forget completely what it was that I intended to do. Talk to Julie about upcoming roundtables? Ask Eric or Arlen a question about UI design?
That’s a nuisance for me around the office, but it would be downright dangerous if anyone still let me manage a production zone or name server.
Even in the simplest DNS environments, there’s a lot to remember: An SOA record has seven RDATA fields. Use a trailing dot to prevent the origin from being appended to a domain name. After editing a zone data file, increment the serial number and reload. Forget any one of those and you’ve caused an operational issue, maybe even an outage.
One of the major benefits of IP address management products is that administrators are insulated from much of this underlying complexity: Serial numbers are incremented automatically, and the name server is reloaded when needed.
But add DNSSEC into the mix and managing DNS gets even trickier. Now, in between incrementing the serial number and reloading, you need to re-sign the zone. Periodically, you’ll need to roll over your Zone-Signing Key, or ZSK. There are two ways to do that (described in RFC 4641, and called pre-publishing and double signature) and both are time-dependent; that is, you need to wait a prescribed amount of time before taking certain actions, such as removing a ZSK or re-signing the zone. Let’s take a look at what the RFC has to say.
Regarding pre-publishing: “The minimum duration of this pre-roll phase is the time it takes for the data to propagate to the authoritative servers plus TTL value of the key set.”
Regarding double signature: “The rollover period will need to continue until all data from version 0 of the zone has expired from remote caches. This will take at least the Maximum Zone TTL of version 0 of the zone.”
So now you’ll need a kitchen timer or a stopwatch at your desk to remind you of when you need to take the next step in the rollover process. Fun!
And, of course, the consequences of messing up are considerably more dire with DNSSEC. Flub a ZSK rollover and your zone data will fail validation, effectively resulting in a denial of service.
These sorts of tasks beg for automation, and it’s up to vendors like Infoblox to provide it. Take the case of key rollover, in particular: There’s a well defined procedure for rolling over to a new Zone-Signing Key (two of them, in fact!), so why not make the whole process automatic? Once an administrator has chosen a key type and length for his ZSKs and a ZSK rollover interval, “the system” can simply generate a new ZSK at the appointed time and follow one or another technique in RFC 4641 to roll over to that new key. And the administrator can go back to trying to remember where he parked his car.
