On 18. 07. 23 23:53, Viktor Dukhovni wrote:
Currently, it’s 7 days for .com which almost exactly matches the RRSIG
expiry-inception difference and that doesn’t give any wiggle room if
things go wrong.
Expiry in the SOA applies to AXFR, but may deployments are not
AXFR-based. And Verisign apparently did try to isolate the server,
sadly that didn't work out as expected.
. - 7 days SOA expiry and 14 days signature validity
.cz - 7 days SOA expiry and 14 days signature validity
.nl - 28 days SOA expiry and 14 days signature validity
.org - 14 days SOA expiry and 3 weeks signature validity
Do any of these use AXFR? If all the servers are effectively "primary",
with incremental zone updates driven by some other process, the SOA
expiry is of little relevance. Sure they should go offline before
signatures start to go stale (as Verisign tried to do, but failed).
Indeed some of the TLDs listed use good old AXFR/IXFR, but that's
besides the point. See below.
The "go offline" logic should therefore be robust, but that's not
the topic at hand I think. The topic is whether "bogus" should
generally be retriable (or even required to be retriable within
reasonable retry limits, and with error caching holddowns to
avoid thundering herd storms, ...).
I think that SOA EXPIRY is equally relevant to any sort of replication
mechanism. Even if everything is driven by a non-DNS database backend it
presumably has some notion of last successful synchronization with it's
database-peers. Such timestamp can be used to trigger SERVFAIL when
(last sync + SOA EXPIRY) time has passed.
--
Petr Špaček
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
