[DNSOP] Re: I-D Action: draft-ietf-dnsop-dnssec-keyrestore -01.txt

Peter Thomassen <[email protected]>
Newsgroups gmane.ietf.dnsop
Message-ID <[email protected]>
Hi Martin,

On 8/5/26 14:34, Martin Pels wrote:
>>> "While performing this procedure to recover from an unusable ZSK or CSK the SOA record of the zone cannot be changed. This is because at the moment the new DNSKEY gets introduced into the zone, the _SOA_ RRset cannot be signed with the old, unusable key."
>>
>> I guess that depends on whether the replication mechanism used for the zone relies on SOA record changes at all.
> 
> Correct.
> 
> The draft currently says "To ensure the zone is still propagated, any secondary name servers _relying on IXFR/AXFR_ need to be manually forced to load the new version of the zone.". Is that clear enough or should we word it more broadly?

XFR is a DNS-embedded zone transport mechanism, but it does not imply that the SOA record changes upon a zone change. For example, you could have a system where a small zone is simply AXFR'ed every 5 minutes and the SOA serial is always 1.

Conversely, you could have a system that *does* compare serials but uses some non-XFR transport.

I therefore think it's better to say "relying on SOA serial comparisons for triggering zone transfers", or something like that.

Best,
Peter

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.