[dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region
pspacek at isc.org
Tue Jul 25 05:56:41 UTC 2023
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.
More information about the dns-operations