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