> > This message starts a dnsop WG Call for Adoption of: > > draft-fobser-dnsop-dnssec-keyrestore-01 > > I am not in favour of adopting this document. The hypothetical > scenario where one has lost the key, but the zone is still working > seems fairly unlikely. It is far more likely one finds out about > the missing key once it is needed to sign something and can't, at > which point it is going to be too late. > > I also don't think people who messed up and are in a panic, are > going to search for an RFC on his to recover from their mistake.
I'm in favor of adopting this. Even if it doesn't get adopted, I plan to reference and possibly summarize it in our documentation. Many signers sign a lot more frequent than is needed to keep signatures for expiring. Many TLDs have frequent updates that require signing. For zones without frequent updates, it is more pleasant to refresh signatures incrementally. That simplifies scheduling. And even if a zone with very infrequent changes only resigns when needed, a prudent operator can resign the zone one week before signatures expire. So there is plenty of time to recover if something goes wrong. > A side effect of RFCs like this is that it will be misused by > opponents to say that DNSSEC is so brittle, it needs RFCs to talk > about operator errors. So we should remain silent about operator error to make DNSSEC look good? I think it is the other way around. People who think about deploying DNSSEC worry about operator errors and make plans for recovery. Currently the main approach is to go insecure, which is very unpleasant. > This could make a nice blog post, but I don't think meets the bar > for an RFC. Can you explain how high the bar should be for an informational RFC? This draft describes a techincal problem and provides a technical solution for that problem. Sounds like something that can be documented in an RFC. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
