[knot-dns-users] Re: Dynamic update fails after zone creation via catalog

Hi, On 1/31/25 10:18, Daniel Gröber wrote: 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.) -- https://desec.io/