Some comments : 3.1 Operational Motivation for ZSK and KSK
I explicitly agree with Antoin Verschuren [[email protected]] that more criteria should be taken into account, more then listed in the present document (like the ones he proposes). As extra observation, I would prefer "child-parent" rather then "registrar-registry" (globally : any reference to "registrar" or "registry"). Motivation : registrar is linked to the "customer" layer and "registry" to the "tld" layer of a "customer.tld." domain name. But DNSSEC can go below that level ! As I am in Belgium, "just.fgov.be." is a delegated subdomain : if they will, one day, soon ?, implement DNSSEC, the communicating DS information is not between registrar and registry. In broader scope : the document should not limit to DNSSEC between a label and a top-level-domain (or tld - root-domain). 4.1 Key Rollovers For non-tld's, I agree, again, with Antoin Verschuren [[email protected]] : recommend double-sign rollover. The present document states, "neutrally", that double-sign rollover involves more signatures and hence, larger zone files. While this is true, well maintained (public) zone files should be small anyway (except for tld's). The average company does not offer hundreds of services on hundreds of IP addresses. A DNS administrator who leaves data like "test-mx" in hers or his public data should learn not to publish anything not meant to be distributed. Recommending pre-publish for "large" zone files (with "lots" of unnecessary data in it) is "pearls to the pigs" ;-) 4.1.2 Key Signing Rollovers I see some tld's perform rollover with 3 keys (not 2). Assuming a start position with 2 keys : Initial : KSK1 & KSK2 (both being used for signing) Start of rollover : add KSK3 --> KSK1 & KSK2 & KSK3 (all used for signing) End of rollover : remove KSK1 --> KSK2 & KSK3 (both used for signing) Advantage : Only 2 actions to complete key rollover During the rollover, there is one key that is completely untouched. --> if chain-of-trust would break via KSK1 or KSK3, that KSK2 (DS/DNSKEY/RRSIG) is always available. As the KSK signs only the DNSKEY RRset, this "costs" only one extra RRSIG in the zone file. Kind regards, Marc Lampo -----Original Message----- From: Peter Koch [mailto:[email protected]] Sent: 18 April 2011 07:42 PM To: IETF DNSOP WG Subject: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17] Dear DNSOP WG, this is to initiate a working group last call (WGLC) on "DNSSEC Operational Practices, Version 2" <draft-ietf-dnsop-rfc4641bis-06.txt> Owing to the length of the document, the WGLC will last for four weeks instead of the usual two, and will therefore end on Tuesday, 17 May, 23:59 UTC. The IETF tools site gives easy access to the current and previous versions as well as differences and the like at <http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-06>. The document is aimed at a status of "Informational". Please review the document and send any comments you may have to the list. If you have no comments but support (or do not support) the document being published, please send that information to the list. The document is subject to the normal five reviewer threshold. Stephen and Peter DNSOP co-chairs _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
