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]
