[DNSOP] Re: Call for adoption: draft-fobser-dnsop-dnssec-keyrestore-01 (Ends 2026-02-27)

[Petr Špaček <[e-mail]>]

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