On 13. 02. 26 21:28, Philip Homburg wrote:
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.
All points well made Philip. I support adoption as well.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
