[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bind-users
Subject:    Re: Incremental transfers generate complete zone reloading
From:       Bob McDonald <bmcdonaldjr () gmail ! com>
Date:       2023-01-16 17:10:30
Message-ID: CAM-Yptd6C-6wm9S_F5UY+rPVy5H2WVS8rwPm4b3iGDPdqpaF_g () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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@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
>

[Attachment #5 (text/html)]

<div dir="ltr">Mea Culpa. Apparently  RPZ IS the issue here.<div><br></div><div>I \
learn something new every time I read this list.  </div><div><br></div><div>My \
apologies  for the waste of \
bandwidth.</div><div><br></div><div>Bob</div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Mon, Jan 16, 2023 at 9:02 AM Bob McDonald &lt;<a \
href="mailto:bmcdonaldjr@gmail.com">bmcdonaldjr@gmail.com</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This is \
just conjecture but I&#39;ll take a stab at this problem.<div><br></div><div>First, \
the fact that the zone is RPZ really doesn&#39;t have any  bearing on this \
problem.</div><div><br></div><div>Do you control both the  primary and secondary \
zones?</div><div><br></div><div>Please provide the SOA for the zone. This will allow \
the  list to see some key timer values.</div><div><br></div><div>1) Updates are \
applied to the primary zone which triggers a notify to the secondary zone and a \
resulting incremental zone transfer. (IXFR)</div><div><br></div><div>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.</div><div><br></div><div>The following suggestions for possible workarounds \
depend on you having control of both primary and secondary \
zones.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Hope that \
helps,</div><div><br></div><div>Bob</div></div> </blockquote></div>



-- 
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



[prev in list] [next in list] [prev in thread] [next in thread]