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

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

Kind regards,
Martin

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