Incremental transfers generate complete zone reloading

[Bob McDonald]

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 <bmcdonaldjr at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230116/b1f96024/attachment.htm>