[DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01

[Michael StJohns <[e-mail]>]

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