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]
