Hi Peter,
I wonder how often you observe a missed NOTIFY. Knot uses TCP for sending
NOTIFY and if it fails, another attempt is scheduled.
Also I'm not convinced that the zone serial property can improve the situation.
It just moves individual zone NOTIFYs to more
frequent catalog updates and sending NOTIFYs. Have you already seen this
concept in practice?
Daniel
On 2/1/25 11:49, Peter Thomassen via knot-dns-users wrote:
Hi,
On 1/31/25 10:18, Daniel Gröber wrote:
option to allow UPDATE to create zones (if they are in the catalog already)
would still be useful.
Just random stuff that comes to mind:
Instead of an option, one could also store the member zone serial as a member
property (which could be useful for tracking missed NOTIFYs anyway*), and then
accept an UPDATE containing both SOA and NS iff the SOA serial matches that
property.
(The latter would need some thinking-through if DNSSEC signing is done by the
receiving end in a way that affects the serial.)
Cheers,
Peter
* Catalog-based replication: I've thought for a long time that it would be
really nice to have catalog zones with member serial numbers, and use IXFR at a
high rate (say, governed by the catalog zone's SOA REFRESH interval) to inform
secondaries about what to update. When running more than just a few zones, this
is much better than doing SOA REFRESH checks on all member zones at that same
rate. (Especially if member zones change rarely, but one wants changes to
propagate quickly.) This would work particularly well where NOTIFYs are
unreliable (because the regular catalog IXFR catches all lost NOTIFYs,
regardless of when they were lost), and it would unity the mechanism for
initial provisioning and replication of changes. At deSEC, we'd really
(really!) like that! (I understand it's not a trivial addition.)
--
