Re: dnskey algorithm update
On Thu, Jan 7, 2016 at 3:00 PM, Carl Byingtonwrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Thu, 2016-01-07 at 08:34 -0600, Jeremy C. Reed wrote: > > On Wed, 6 Jan 2016, Carl Byington wrote: > > > > Is there a more authoritative document that describes the algorithm > > > roll over procedure? It seems that I need to: > > > ISC has a DNSSEC Guide. See this section: > > > http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#advanced- > > discussions-DNSKEY-algorithm-rollovers > > > (Also in PDF format at the same directory.) > > > We still have some feedback to integrate into the guide, but if anyone > > would like to participate, also see the GitHub site: > > https://github.com/isc-projects/isc-dnssec-guide > > > Based on RIPE experience at https://labs.ripe.net/Members/anandb/dnssec- > algorithm-roll-over, where Unbound and Verisign make assumptions about > the DS record set, we need to ensure that: > > adding an algorithm - you need to generate both KSK and ZSKs for the new > algorithm, publish them in the DNSKEY rrset, and sign the zone with > them. No, the RRSIGs for the algorithm need to be published in the zone *before* the keys, at least for the value of the largest TTL in the zone, plus propagation time. This is because you don't want a resolver to find a set of DNSKEYs and have to try to validate an RRset with only a subset of the algorithms found in those keys. > Then wait one TTL cycle before updating the DS records in the > parent. > > removing an algorithm - you need to remove the old algorithm DS records > from the parent, then wait one TTL cycle before removing the old KSK and > ZSKs using that algorithm, and resigning the zone using only the new > algorithm. > > > > Also, based on https://tools.ietf.org/html/rfc6781#page-31, it seems we > need to be able to sign the zone with a key that is not published in the > DNSKEY rrset. Consider the case of adding a ZSK with the new algorithm, > where we publish that ZSK in the DNSKEY rrset and resign the zone using > both old and new ZSKs. A resolver might have an old cached MX rrset only > signed with the old algorithm; and then retrieve the new DNSKEY rrset > which mentions both algorithms. > > RFC6781 implies that this will break validation. Is that correct? Yes, in certain cases. Validators with strict validation policies or validators that understand one algorithm but not the other will fail to validate the RRset. Casey ___ 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
dnskey algorithm update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My zones are currently using algorithm 5 (RSASHA1), with two KSKs and two ZSKs with overlapping timers. In preparation for updating to algorithm 8 (RSASHA256), I read: The bind-users thread "KSK signing all records; NSEC3 algorithm status?" https://tools.ietf.org/html/rfc6781#page-31 https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over Is there a more authoritative document that describes the algorithm roll over procedure? It seems that I need to: generate new ZSK and KSKs using algorithm 8 sign the zone with all the keys wait one ttl cycle, then publish a new dnskey rrset wait one ttl cycle, then upload the new ds rrset ... eventually, remove the old KSKs from the dnskey rrset, but still use them to sign the zone wait one ttl cycle, then resign the zone without the old KSKs. For that to work, I need to get dnssec-signzone to sign a zone without publishing the keys (activate < publish) and (inactivate > delete). 'man dnssec-signzone' under -S smart signing, talks about the following timers - (publication, activation, revocation, unpublication, deletion). That man page implies that dnssec-signzone will always publish keys that it has used to sign the zone. The use of 'unpublication' and lack of mention of 'inactivate' seems to be an oversight. 'man dnssec-settime' documents the following timers - (P publication, A activation, R revocation, I retired (inactive?), D deleted) 'dnssec-settime -p all' uses (Created, Publish, Activate, Revoke, Inactive, Delete) names. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlaNdXsACgkQL6j7milTFsFQ6wCffo9wlY7roi2U3iI/6TSahK7R 6hQAn3HgFbGeJBXsMza6IRAuDLBx2Wr3 =bTLc -END PGP 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
Re: dnskey algorithm update
On Wed, 6 Jan 2016, Carl Byington wrote: My zones are currently using algorithm 5 (RSASHA1), with two KSKs and two ZSKs with overlapping timers. In preparation for updating to algorithm 8 (RSASHA256), I read: The bind-users thread "KSK signing all records; NSEC3 algorithm status?" https://tools.ietf.org/html/rfc6781#page-31 https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over Is there a more authoritative document that describes the algorithm roll over procedure? It seems that I need to: generate new ZSK and KSKs using algorithm 8 sign the zone with all the keys wait one ttl cycle, then publish a new dnskey rrset wait one ttl cycle, then upload the new ds rrset ... eventually, remove the old KSKs from the dnskey rrset, but still use them to sign the zone wait one ttl cycle, then resign the zone without the old KSKs. Carl: When I did that algorithm upgrade, I used something close to this process (based on the dual-signature method): # generate new RSASHA256 ZSK & KSK (active & published) dnssec-keygen -K Keys.dnssec -a RSASHA256 -b 1024 -n ZONE $ZONE dnssec-keygen -K Keys.dnssec -a RSASHA256 -b 4096 -n ZONE -f KSK $ZONE # re-sign the zone, using smart signing to pick up all keys dnssec-signzone -K $KEY_DIR -d $KEY_DIR -S -o $ZONE $DIR/$ZONE # re-load the zone (add any other required rndc args) rndc reload $ZONE # add DS record(s) for new KSK in parent zone; # left as an exercise for the reader # wait at least 1 TTL cycle (minimum of that for $ZONE & that for the # DS records in the parent zone) to let new DNSKEY, RRSIG, & DS records # propagate # move old keys out of key dir so they don't get used mv $KEY_DIR/K$ZONE.+005+* $TMP_DIR # re-sign the zone (with just new keys) dnssec-signzone -K $KEY_DIR -d $KEY_DIR -S -o $ZONE $DIR/$ZONE # re-load the zone (add any other required rndc args) rndc reload $ZONE # delete DS record(s) for old KSK in parent zone; # left as an exercise for the reader # if all good, delete old keys rm $TMP_DIR/K$ZONE.+005+* where: $ZONE is the zone being upgraded $KEY_DIR contains the key files $DIR contains the zone files $TMP_DIR contains old keys temporarily You can get by with activating the new (RRSIG,DNSKEY,DS) set as a group immediately after creation & re-signing because the old set is still present as the basis for validation while the new set propagates around. Likewise, after the TTL cycle you can delete the old (RRSIG,DNSKEY,DS) set as a group because by then the new set is present as the basis for validation. It worked for me. As always, your experience might vary. I recommend working through this for a zone which: o doesn't matter o has the parent under your direct control These tools are extremely useful: http://dnsviz.net/ http://dnssec-debugger.verisignlabs.com/ Use them to view & verify things at each stage. To really have some fun, purposefully break some part of your test zone & see how the above tools show it. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ 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