Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01
Hi, On Thu, 6 Sep 2012 10:31:03 -0400 (EDT) Paul Wouters p...@cypherpunks.ca wrote: I find this document does not add enough new information compared to draft-ietf-dnsop-rfc4641bis-12#section-4.2 to warrant a new RFC. The document intent to describe what to do when child zone administrator failed to do KSK rollover. It also intent to advice to parent zone administrator for that case. I think this concept is not included in rfc4641bis. Regards, -- Yoshiro YONEYA yoshiro.yon...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01
On Fri, 7 Sep 2012, Yoshiro YONEYA wrote: The document intent to describe what to do when child zone administrator failed to do KSK rollover. It also intent to advice to parent zone administrator for that case. I think this concept is not included in rfc4641bis. A lot of what can be done there will be framed by lawyers, not engineers. I agree 4641bis tells you how to not get at a failed rollover state. I just don't see much value in a document that tells you what to do when you ignored 4641bis. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01
Hi, On Wed, 05 Sep 2012 13:20:10 -0400 Michael StJohns m...@nthpermutation.com wrote: Hi - As the subject document seems to describe an operations problem rather than a protocol problem, I'm going to use the dnsop mailing list to post some comments. Thank you for bringing this to dnsop mailing list. While I haven't completely internalized this document, I'm pretty sure it's addressing the wrong problem. The issue is not that there are too many DS in the parent zone as compared to DNSKEY in the child. It's actually perfectly correct to publish a DS record in advance of publishing the related DNSKEY. I *think* the issue they may be concerned with is a complete disjunction between the parent DS and child DNSKEY RRSets. But that's not what the document says. Disjunction between DS and DNSKEY will happen. That is premise of the document. And the document (at least, one of the authors) is intent to indicate rational procedure to recover from the validation failure caused by the disjunction as soon as possible. Case 1 - there is no such thing as a failing DS. There is a DS that does not currently match a child DNSKEY, but that is not necessarily a fail. Case 1 - the appropriate problem is no matching DS for zone DNSKEYs - the resolution is add a matching DS to the parent zone, or deploy a DNSKEY that matches an existing DS. Case 2-5 seem to be the same problem as case 1, rather than separate problems - but the title of the cases does not reflect this. In any event, removal of data is mostly not going to help the problem - you need to add the appropriate links in the trust chain. Data that does not provide a link in a trust chain is just extraneous and may be safely ignored until it can be removed with normal practices. Case 1-5 are alternate countermasures in case of disjunction has happened. Of course, add appropriate DS in parent zone is correct way to recover the disjunction. However, if DS is corrected, zone banishing may remain until DS cache is expired in validators. This duration will take huge impact to the internet users. As described above, the document is intent to indicate rational procedure to shorten the duration. At best this is an incomplete ID (and I'd recommend not posting something this incomplete), at worst it's headed in the wrong direction. Indeed, the document is imcomplete, and need feedbacks from experiences. Regards, -- Yoshiro YONEYA yoshiro.yon...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01
Yoshiro YONEYA (yoshiro.yoneya) writes: Indeed, the document is imcomplete, and need feedbacks from experiences. There are indeed many ways to facilitate recovery, not all of them practical or realistic. Here's one that's more in the realm of prevention, but would faciliate recovery, assuming the implementation doesn't suffer from the same operational errors that led the zone owner to consider recovery in the first place, and assuming the DS-set has been completely borked by the parent: Case 6: always have a backup (fallback) DS, published alongside the existing (production) DS record or records (during rollover) currently associated with the currently active (production) KSK. Keep this backup KSK in a safe place, and in case of serious SNAFU with the existing DS-KSK couple, pull the backup KSK out of the Safe Place, and start signing the ZSK with that. The DS-set containing the active + backup KSK being by definition always published, this should allow for faster convergence (assuming a fairly low TTL for the DNSKEY RRset in the signed zone). The problem with the ID may be that there are so many different ways of doing this (hinted at by the phrase Registration system (or zone generation system) of parent zone will be complicated.)... Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01
Hi - As the subject document seems to describe an operations problem rather than a protocol problem, I'm going to use the dnsop mailing list to post some comments. While I haven't completely internalized this document, I'm pretty sure it's addressing the wrong problem. The issue is not that there are too many DS in the parent zone as compared to DNSKEY in the child. It's actually perfectly correct to publish a DS record in advance of publishing the related DNSKEY. I *think* the issue they may be concerned with is a complete disjunction between the parent DS and child DNSKEY RRSets. But that's not what the document says. Case 1 - there is no such thing as a failing DS. There is a DS that does not currently match a child DNSKEY, but that is not necessarily a fail. Case 1 - the appropriate problem is no matching DS for zone DNSKEYs - the resolution is add a matching DS to the parent zone, or deploy a DNSKEY that matches an existing DS. Case 2-5 seem to be the same problem as case 1, rather than separate problems - but the title of the cases does not reflect this. In any event, removal of data is mostly not going to help the problem - you need to add the appropriate links in the trust chain. Data that does not provide a link in a trust chain is just extraneous and may be safely ignored until it can be removed with normal practices. At best this is an incomplete ID (and I'd recommend not posting something this incomplete), at worst it's headed in the wrong direction. Mike ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
