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

Hi Petr,

On 15/07/2026 16:06, Petr Špaček wrote:
>> 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.
There are several issues with this:

1. Making this a random value would mean the receiver needs to track all 
values. An incrementing value means only the highest value needs to be kept.

2. It does not address Philip's concern about not knowing which upstream 
nameserver has a recent enough copy of the zone.

3. A received AXFR would need to be matched to a previously received 
NOTIFY(AXFR) to insert the correct UUID in NOTIFY(AXFR)'s to be sent 
out. If the value is passed on to the AXFR request and response this can 
be handled asynchronously.

I'm not an implementer though, so feel free to correct me if I'm wrong.

 > 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.

Can you elaborate how the timestamp-based sequence would break? I 
believe a mid-process change would only trigger a new round of 
NOTIFY(AXFR)'s with the higher timestamp.

Kind regards,
Martin

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