1 Úno
2025
1 Úno
'25
18:09
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.)