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]
