Brian Paul Kroth <bpkr...@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 feature.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 dsset-child.parent.tld.
- 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.
Seem reasonable? Thanks, Brian
signature.asc
Description: Digital signature
_______________________________________________ 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
