Log in

DNSSEC with BIND 9.8.0 - Tony Finch

dotatfanf wrote
on 4th May 2011 at 18:03
Previous Entry Share Next Entry

DNSSEC with BIND 9.8.0

(Leave a comment)
Date:2011-05-06 01:54 (UTC)


Isn't the KSK and ZSK stuff divide made so that the ZSK is used to only sign a few records (that being the DNSKEY and DS RR sets for the zone apex if I understand correctly) so that it won't have to be rolled over as frequently due to frequency/replay attacks?
(Reply) (Thread)
Date:2011-05-06 09:08 (UTC)

Re: KSK-only

Basically, yes.

The idea is that the KSK (not ZSK as you said) just signs the DNSKEY records at the apex of the zone. The ZSK signs the rest of the zone. (In fact any key in the DNSKEY RRset can sign any RRset in the zone, but you normally only make use of this flexibility during a key rollover.)

There is a flag called the "secure entry point" bit which is used to mark KSKs. This says to third parties that if the hostmaster has told them they can set up their own trust anchors for the zone, then these are the keys they should use. In fact this is almost never done and instead you rely on the chain of trust from the root, though you might want to install trust anchors for your own zones on your own resolvers. So the SEP bit usually just informs tools which keys are KSKs and which are ZSKs.

At your delegation point in the parent zone there is at least one DS record that corresponds to a KSK. The DS record is signed by the parent to authenticate the security of the delegation.

Now you don't want gratuitous churn with your KSK, because of the work this creates to update your delegation in the parent zone and the disruption to people who have configured it as a trust anchor. So you want the KSK to be kept very secure - ideally offline - so that it isn't accidentally compromised. But you need an online key for everyday signing duties - signing changes to the zone, and re-signing as signatures expire.

The KSK/ZSK split allows you to keep the KSK offline, and only bring it out occasionally just to sign the DNSKEY RRset, which you can keep more stable than the rest of the zone. If a ZSK is compromised it isn't too much of a disaster since you can quickly produce a new DNSKEY RRset and re-sign the zone without also having to deal with third parties. The dnssec-dnskey-kskonly option helps to keep this separation clear.

For most purposes this level of operational complexity isn't necessary. You can in fact just have one key for a zone and sign everything with it. (This isn't particularly risky if the key is stored in a hardware security module.) But the tools encourage the split keyset model since you have to use non-default settings to make the single key model work - see the "update-check-ksk" option.
(Reply) (Parent) (Thread)

(Leave a comment)

Powered by LiveJournal.com