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]
