BIND slave stops updating from master after 1-3 days

Brandon Whaley brandonw at inmotionhosting.com
Mon Jul 29 22:41:30 UTC 2013


Hi all, I've recently upgraded from a CentOS5 install of BIND 9
(bind-9.3.6-20.P1.el5_8.6) to a CentOS6 install
(bind-9.8.2-0.17.rc1.el6_4.4.x86_64) for one of my two nameservers.  The
config I'm using is nearly identical (added rate limiting only) and the
server that has not yet been updated is still having no problems.  The
upgraded server will stop receiving updates for zones after 1-3 days of
completely normal operation.  Restarting named (but not reloading) corrects
the problem for another 1-3 days.

I have logs showing what happens before and after a restart of the service.
 I've changed the IPs in these logs and the config file which follows.  In
them, 10.0.x.1 represents a master server and 10.10.10.1 is the slave
having issues.  These logs are basically "tail -f named.log | grep
example.com" where example.com is the test domain I'm using (it happens
with all domains).  I update the zone file's serial on 10.0.4.1, then do an
rndc reload there, these are the logs that come up:

Before named restart
=====
29-Jul-2013 10:17:29.567 notify: info: client 10.0.4.1#37224: received
notify for zone 'example.com'
29-Jul-2013 10:17:30.069 notify: info: client 10.0.4.1#32206: received
notify for zone 'example.com'
29-Jul-2013 10:17:30.069 general: info: zone example.com/IN: notify from
10.0.4.1#32206: refresh in progress, refresh check queued
29-Jul-2013 10:18:59.568 general: info: zone example.com/IN: refresh: retry
limit for master 10.0.1.1#53 exceeded (source 10.10.10.1#0)
29-Jul-2013 10:18:59.568 general: info: zone example.com/IN: Transfer
started.
29-Jul-2013 10:18:59.569 xfer-in: info: transfer of 'example.com/IN' from
10.0.1.1#53: connected using 10.10.10.1#55992
29-Jul-2013 10:18:59.570 xfer-in: info: transfer of 'example.com/IN' from
10.0.1.1#53: Transfer completed: 0 messages, 1 records, 0 bytes, 0.001 secs
(0 bytes/sec)

After named restart
=====
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



In case it's necessary, here is the config for the slave where these logs
were produced:

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};

include "/etc/rndc.key";

acl "notifytrusted" { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };

logging{
  channel simple_log {
    file "/var/log/named.log" versions 3 size 65m;
    #severity warning;
    severity debug 0;
    print-time yes;
    print-severity yes;
    print-category yes;
  };
  category default{
    simple_log;
  };
};

zone "." {
        type hint;
        file "/var/named/named.ca";
};

options {
        statistics-file "/var/named/data/named_stats.txt";
        directory "/var/named";
        forwarders {10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
        forward only;
        transfers-in 50000;
        transfers-per-ns 50000;
        serial-query-rate 10000;
        transfer-source 10.10.10.1;
        use-alt-transfer-source no;
        rate-limit {
                responses-per-second 200;
                window 5;
        };
        allow-transfer { none; };
        notify no;
        allow-notify {notifytrusted; };
};


After this is just zone definitions.  Has anyone else seen this problem?

-- 
Best Regards,
Brandon W.
Tier 3 System Administrator
InMotion Hosting Inc.

888-321-4678
757-416-6575 (Int'l)
NEW: 24x7 EMAIL and PHONE Technical Support

Did you know?
We'll Build, Update and Promote Your Site for You! Visit
www.inmotionhosting.com/webdesign
Answers to commonly asked questions, as well as other useful tools, can be
found at http://support.inmotionhosting.com

How am I doing? Please feel free to email my manager at
manager_feedback at inmotion.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130729/476086e7/attachment-0001.html>


More information about the bind-users mailing list