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 key. > # 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.
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 zkt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/zkt-users
