> > I am concerned by your last statement..."I debating going to a longer > lifetime KSK". Keys don't expire. Signatures expire, and a set of > keys > in use can re-sign the data with new expiration dates without a key > roll. The idea that keys expire seems very common and leads to > unneeded failures.This confusion is a combination of confusion on how > DNSSEC actually works and careless wording by people who do > understand. I suspect that this was the latter )(careless wording), > but it still contributes to the continuing meme that keys expire. > > If your registrar does not get the new DS in place, just sign the > data > again with the old key and a later expiration date. You can delay a > key roll indefinitely..
That's a good point... guess I can use 'dnssec-settime' to change the metadata on my current KSK so that the automation doesn't seek to rollover at the time that I had set at creation time. This way I can continue to use the current KSK. Though it used to be normal to change keys annually...especially for systems with sensitive data or more sensitive interactions. Though since the switch from 1024-bit keys to 2048-bit keys...it is now permissible to go 3 years on a key. The currently policy doesn't cover DNSSEC, so I've been guessing. Though the subject of key escrow is warming up again. They're now saying it isn't necessary for servers, even though it makes it hard for the box that is on fiber taps in our datacenter to see into SSL streams it doesn't have keys for. But, they're pushing that all client keys are to be escrowed, though most of the current users have them because of a .mil or .gov requirement. Rather than the new reasons for wanting the. Pretty sure DNSSEC doesn't approach that level of sensitivity though. Though when we first started doing DNSSEC, the service provider for our external secondaries weren't running a version of bind capable of RSASHA1-NSEC3. So, I talked of dropping NSEC3, but our IT security group demanded that our service provider upgrade. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
