Incremental transfers generate complete zone reloading

Bob McDonald bmcdonaldjr at gmail.com
Mon Jan 16 14:02:32 UTC 2023


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/10eff148/attachment.htm>


More information about the bind-users mailing list