[dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Petr Špaček]

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