Hi Jasper,

> I have a domain but my registrar dosn't do dnssec so i use the isc dlv 
> system to publish my KSK.
> This all works ok.

> my current KSK is nearing the end of it's life so i want to do the ksk 
> rollover and get the new ksk in the isc dlv system.
To be honest, there is no _need_ (by the DNSSEC protocol) to do a
regular KSK rollover. It's up to you to use the key for a longer period
if you like.

But anyway, I never tried a KSK rollover with ISC DLV, but it should
work nearly in the same way as with a parent domain.

First of all, there are three dedicated options to help you to do a KSK
rollover. Please have a look at "zkt-keyman --ksk-rollover" how to use it.
> afaict the sequence is something like:
> # generate new ksk
> zkt-keyman -k -C pointless.net
> # and resign and reload zone
> zkt-signer -r -v -v
Now you have a so called "standby key" created.
A standby key is a pre-published KSK. It is useful for an emergency
rollover, because you do not have to wait for the propagation of the new

> # find keyid and publish (?) (not needed?)
> zkt-keyman -P <keyid>
> # and resign and reload zone
> zkt-signer -r -v -v
This is not needed (see above), but you have to wait for propagation of
the key plus DNSKEY ttl.

> # give DS etc to upper zones, wait for propergation/ttl etc.
> # after waiting make new key active
> zkt-keyman -A <keyid>
> # and resign and reload zone
> zkt-signer -r -v -v
You should first activate the key, which means signing the DNSKEY RRset
with both KSKs, and then (after waiting) *replace* the old DS (or DLV
record) with the new one. You are using two keys for a while, but the
parent has just one DS record.

> # wait for propergation/ttl etc.
> # now depreciate the old key
> zkt-keyman -D <oldkeyid>
> # and resign and reload zone
> zkt-signer -r -v -v

> I've done the first step and i can see the DNSKEY record with dig and so can 
> dnsvis
> etc.
> zkt-ls shows it in 'sta' state
This means "standby".

> If I try to publish the new key i get:
> zkt-keyman: Couldn't change status of key 16611: 1
That's ok, because the key is already published (sorry for the really
meaningless error message).

> looking in the dir i see:
> Kpointless.net.+005+16611.key
> Kpointless.net.+005+16611.published
> so it's there, but .published rather then .private?
Yes, that means that the key will not be used by zkt-signer (or
dnssec-signzone) for signing.

> Looking through the source that means it's already published.
Yes, that's right.

> ISC DLV system can see the key, and can fetch it etc, but it complains that:
> 4.208:INFO VERIFY-DNSKEY: 1 keys found after filtering.
> 4.208:DEBUG VERIFY-DNSKEY: Using keys:
> 4.209:DEBUG VERIFY-DNSKEY: tag=16611 flags=257 alg=RSASHA1 
> BQEAAAAB...g0n0rOBbw==
> 4.209:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY
> 4.212:FAILURE DNSKEY signature verification failed: Signing key not found
It seems that ISC tries to verify that you are already using the DNSKEY,
so they want to prevent to install a DLV which points to a not used
DNSKEY, which is far good.
> Looking with dig (as far as i can tell) the rrsig's use the existing ksk and
> zsk.
> So is there some bit in the dnskey record that needs setting?
No, just activate the key.

> I guess that i can go ahead and activate it, but I want to check that that
> won't replace the existing key.
No, instead the DNSKEY RRSet will be signed by two key signing keys.

> Presumably it's ok to have 2 KSK's for a short time?
Yes, of course. Because of this, the rollover is called a "double
signature" rollover.

Be aware that during the KSK rollover, the DNSKEY RRSet has at least
three DNSKEY's (maybe more if a ZSK rollover is ongoing) plus two RRSIG
records, so the size of the DNSKEY RRset is maybe to big to fit in a
single DNS UDP packet (depends on edns0 bufsize).

> I'm using zkt-1.1.0 (compiled myself) on debian.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
zkt-users mailing list

Reply via email to