Mea Culpa. Apparently RPZ IS the issue here. I learn something new every time I read this list.
My apologies for the waste of bandwidth. Bob On Mon, Jan 16, 2023 at 9:02 AM Bob McDonald <bmcdonal...@gmail.com> wrote: > This is just conjecture but I'll take a stab at this problem. > > First, the fact that the zone is RPZ really doesn't have any bearing on > this problem. > > Do you control both the primary and secondary zones? > > Please provide the SOA for the zone. This will allow the list to see some > key timer values. > > 1) Updates are applied to the primary zone which triggers a notify to the > secondary zone and a resulting incremental zone transfer. (IXFR) > > 2) Before the IXFR from item 1 is finished, the refresh timer expires > triggering the secondary zone to request the SOA from the primary. Since > the serial number on the secondary has not yet been updated as a result of > the IXFR from item 1, the secondary requests ANOTHER IXFR from the primary. > This can cause the overlap you are seeing. > > The following suggestions for possible workarounds depend on you having > control of both primary and secondary zones. > > There are a couple of things that could help. the refresh timer for > properly configured dynamically updatable zone sets needs to be set fairly > high. I like 8 hours. YMMV. > > The updates to the primary zone can be effectively batched using the > notify-delay value. This will require some further thought and testing. The > ultimate value depends on the volume of updates being generated. > > Hope that helps, > > Bob >
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
