BIND slave stops updating from master after 1-3 days

Steven Carr sjcarr at gmail.com
Tue Jul 30 22:28:47 UTC 2013


On 30 July 2013 23:19, Brandon Whaley <brandonw at inmotionhosting.com> wrote:

> That's certainly disconcerting (and diverges from the behavior we continue
> to see with BIND 9.3).  Is there any reason these updates would work
> without issue immediately after a restart but stop working at some point
> later?  As you can see in the logs I provided in my initial post (relevant
> lines copied below) it does work as I described after a restart, for an
> as-yet-determined amount of time:
>
> 29-Jul-2013 10:43:34.879 notify: info: client 10.0.4.1#42576: received
> notify for zone 'example.com'
> 29-Jul-2013 10:43:34.890 general: info: zone example.com/IN: serial
> number (2011061500) received from master 10.0.1.1#53 < ours (2013022611)
> 29-Jul-2013 10:43:34.900 general: info: zone example.com/IN: refresh:
> non-authoritative answer from master 10.0.2.1#53 (source 10.10.10.1#0)
> 29-Jul-2013 10:43:34.904 general: info: zone example.com/IN: refresh:
> non-authoritative answer from master 10.0.3.1#53 (source 10.10.10.1#0)
> 29-Jul-2013 10:43:34.915 general: info: zone example.com/IN: Transfer
> started.
> 29-Jul-2013 10:43:34.916 xfer-in: info: transfer of 'example.com/IN' from
> 10.0.4.1#53: connected using 10.10.10.1#44081
> 29-Jul-2013 10:43:34.919 general: info: zone example.com/IN: transferred
> serial 2013072910
> 29-Jul-2013 10:43:34.919 xfer-in: info: transfer of 'example.com/IN' from
> 10.0.4.1#53: Transfer completed: 1 messages, 23 records, 719 bytes, 0.002
> secs (359500 bytes/sec)
> 29-Jul-2013 10:43:35.379 notify: info: client 10.0.4.1#43038: received
> notify for zone 'example.com'
> 29-Jul-2013 10:43:35.380 general: info: zone example.com/IN: notify from
> 10.0.4.1#43038: zone is up to date
>

So looking at that log it would seem to indicate that on a restart it does
consult masters in sequence until it finds one that has a higher serial
than what it currently has. It tried 1.1 and got a very old serial, skipped
2.1 and 3.2 as there was a non-authoritative answer, then got a response
from 4.1 with a higher serial and initiated transfer, it has no need to
consult 5.1 as it shouldn't be any higher than the one it has just
transferred (because BIND doesn't do multi-master).

After receiving the notify it goes back to the first master to check for an
update, which fails (as it's older) and eventually leads to the zone
expiring.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130730/13c94480/attachment.html>


More information about the bind-users mailing list