DNSSEC DS vs DNSKEY record publication order question (wrt key algorithm rollover)
bpkroth at gmail.com
Wed Jan 16 21:57:03 UTC 2013
Brian Paul Kroth <bpkroth at gmail.com> 2013-01-15 23:19:
> Hello All,
> First, I'm not currently on the list, so please CC if me if you could.
Let's try this again now that I'm on the list.
> Next, I've been working on some scripts to get KSK rotation
> semi-automated or at least alerting in our environment and I've got
> some questions about the DS record requirements and their relation to
> the files generated and included by dnssec-signzone's smart signing
> RFC 4035 sec 2.2 says
> There MUST be an RRSIG for each RRset using at least one DNSKEY of
> each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
> itself MUST be signed by each algorithm appearing in the DS RRset
> located at the delegating parent (if any).
> This says to me that you can have extra DNSKEY records (that don't
> yet have a corresponding DS pair upstream), but not extra DS records
> (that don't yet have a corresponding DNSKEY downstream), since every
> DS records must have a key and sig associated with it.
> RFC 4035 sec 2.4 says
> A DS RR SHOULD point to a DNSKEY RR that is present in the child's
> apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
> by the corresponding private key. DS RRs that fail to meet these
> conditions are not useful for validation, but because the DS RR and
> its corresponding DNSKEY RR are in different zones, and because the
> DNS is only loosely consistent, temporary mismatches can occur.
> This says to me that the RFC also acknowledges that things might/will
> get out of sync due to caching in DNS, but doesn't describe to me
> what resolvers do in that context. Do they complain that the DS they
> happened to choose to look for a valid chain of trust didn't work and
> throw the whole thing out, or do they just move along to the next one
> in the hopes that it might succeed?
> RFC 5011 sec 6.6 says
> 1. Generate a new DNSKEY and DS record and provide the DS record to
> the parent along with DS records for the old keys.
> 2. Once the parent has published the DSs, add the new DNSKEY to the
> RRSet and revoke ALL of the old keys at the same time, while
> signing the DNSKEY RRSet with all of the old and new keys.
> 3. After 30 days, stop publishing the old, revoked keys and remove
> any corresponding DS records in the parent.
> This says to me that DS records SHOULD be published before the DNSKEY
> is, which seems to contradict the first quote.
To add some more confusion, RFC 4641 (now 6781) sec 4.2.4 also mentions
standby keys and pushing DS records without DNSKEY records for KSK keys.
The way to deal with stand-by keys differs for ZSKs and KSKs. To
make a stand-by ZSK, you need to publish its DNSKEY RR. To make a
stand-by KSK, you need to get its DS RR published at the parent.
> Why to the bind-users list you ask? Well, I'm trying to figure out
> if the dsset-* files generated by the "smart signing" feature of
> dnssec-signzone -S are smart enough to be usable for key rotation
> inclusion and warning scripts, or if I need to come up with that
> logic on my own and generate and include DS records separately from
> the -g option.
> I think it gets particularly tricky when you start considering things
> like key algorithm rollover where one needs to (I think) first yank
> the DS records, wait, then revoke the old algorithm keys, wait, then
> yank the keys (mostly due to the first quote I posted).
> If the parent and child are on the same server and being resigned
> during that waiting period, then dnssec-signzone will continue to
> overwrite and include the olds keys in the dsset-* files, and the -g
> option would normally just include them in the parent. Unless I've
> misinterpreted something above, the only way around that that I see
> is to maintain your own DS records in the parent zones (whether
> they're local or remote), including them manually (ie: via perl/db
> :), and specifically *not* using the -g option (which makes me sad).
> Anyways, thoughts, opinions, advice?
Given the latest RFC evidence I posted, I think my summary view is as
follows, please correct me if it seems wrong:
1) DS records are just used to validate the chain of trust upstream for
DNSKEY records found downstream, so there MUST exist a DS record for
each DNSKEY/RRSIG chain you intend to have used for validating RRSIGs
(though not for just standby keys that are listed in DNSKEY records but
not signing), but there need not exist a DNSKEY/RRSIG chain for each DS
record (which is what contradicts 4035 2.2). So, we could prepublish DS
records without an issue, but DNSKEYs that are published must be
validated by an existing chain of trust (DNSKEY/DS pair) before they can
be used to validate other RRSIGs.
2) dnssec-signzone probably generates the right dsset-* files ("Does the
Right Thing TM") and can be included without much thought.
3) With the above, in an algorithm rollover, I should be able to do
something like this:
- Generate keys with a new algorithm and publish them, but don't
activate them yet.
# dnssec-keygen -a RSASHA256 -P +0 -A none parent.tld
# dnssec-keygen -a RSASHA256 -P +0 -A none -f KSK parent.tld
# dnssec-keygen -a RSASHA256 -P +0 -A none child.parent.tld
# dnssec-keygen -a RSASHA256 -P +0 -A none -f KSK child.parent.tld
- Include them in the zone, but don't sign with them yet - just use the
old algorithm keys for now.
# dnssec-signzone -S -g -x child.parent.tld.db
# dnssec-signzone -S -g -x parent.tld.db
- Publish the dsset-parent.tld. records (which include the old KSK
algorithm record as well) to tld
At least for parent.tld, since dnssec-signzone -g parent.tld.db
will already have included the new ones from
- Wait for max(DS TTL, DNSKEY TTL) to expire so another path to chain of
trust (through the new keys) is established.
- Activate the new keys and sign the zone with them.
# dnssec-setting -A+0 $new_alg_zsk_key
# dnssec-setting -A+0 $new_alg_ksk_key
- Revoke the old algorithm's KSK key, and inactivate the old algorithm's
ZSK key and mark them to be removed entirely in 30 days (the
HOLD_DOWN increment per 5011).
# dnssec-settime -I +0 -D +30d $old_alg_zsk_key
# dnssec-settime -R +0 -I +30d -D +60d $old_alg_ksk_key
- Resign the zone as above but this time it should only include
signatures for the new algorithm.
- After the 60 days have passed and the new dsset-* files generated from
periodic zone resigning no longer include the old algorithm's key,
push the new records upstream.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the bind-users