[DNSOP] Re: Fwd: New Version Notification for draft-pels-d nsop-axfr-notify-00.txt

On 18. 06. 26 10:33, Martin Pels wrote:
> Hi Philip,
> 
> Thanks you for the feedback.
> 
> On 19/05/2026 09:33, Philip Homburg wrote:
>> I'm a bit worried what will happens if the graph that connects the 
>> nameservers
>> is not a tree.
>>
>> 1) A secondary may receive multiple notifies. Without a SOA check the
>>     number of zone transfers may get out of hand.
> 
> Section 5 specifies that a secondary must rate-limit how often they will 
> request an AXFR from their primaries. That should prevent excessive 
> amounts of zone transfers.
> 
>> 2) A loop in this graph may cause an endless series of zone transfers.
>>
>> 3) A secondary could receive a notify but not know which upstream 
>> nameserver
>>     has a more recent version of the zone.
> 
> Good catch on both of these!
> 
>> I wonder, the SOA serial is an in band mechanism. Maybe it is easy enough
>> to add an out of band mechanism. For example, we have the ZONEVERSION
>> ENDS(0) option. Maybe that can be added to both the notify an and the 
>> AXFR
>> request.
> 
> Right. This would have to contain an incrementing value, distinct from 
> the SOA serial.
> 
> What we could do is pass a (64-bit) timestamp in EDNS(0) with the AXFR 
> as well as the NOTIFY(AXFR). Secondaries would have to store the highest 
> timestamp they received with the AXFR response to deal with (2). 
> Comparing the timestamp in a received NOTIFY(AXFR) with that in the AXFR 
> response would deal with (3). If the AXFR has a lower timestamp, another 
> primary should be tried. If a timestamp is not attached to the AXFR, 
> chained NOTFIFY(AXFR)'s must not be sent out.
> 
> This would have to be a new EDNS(0) option instead of a new ZONEVERSION 
> type. NOTIFY(AXFR) is a type of query, and "OPTION-LENGTH for the 
> ZONEVERSION option MUST have a value of 0 for queries".

I think there's an alternative way out:

Pair NOTIFY(AXFR) message with an a random value of some form. (Say 
random UUID.) Additional NOTIFY requests to secondaries triggered by 
this top-level NOTIFY would inherit the same UUID. If a duplicate 
request is detected it is rejected.

Of course it requires keeping extra state, which is hard to design 
properly. OTOH it does not break when zone version changes while all the 
requests are being processed, which might easily happen on large zones 
and slow/unreliable links.


Yet another alternative is getting rid of linear SOA serial and 
replacing it with more verbose alternatives, which would bring DNS to 21 
century and potentially away from single-source-of-truth model, which 
quite often does not hold anymore. But that would be even more work.

-- 
Petr Špaček

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]