BIND slave stops updating from master after 1-3 days

[Brandon Whaley]

Hey Steve, thanks for the reply.  Here's the top of one of the masters'
named.conf files (they're all the same, with the exception of which zones
are on them:

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

include "/etc/rndc.key";

logging{
  channel simple_log {
    file "/var/log/ramlog/named.log" versions 3 size 65m;
    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";
        recursion no;
        transfers-out 10000;
        notify explicit;
        also-notify {10.10.10.1; 10.10.10.2; };
        allow-transfer {10.10.10.1; 10.10.10.2; };
        files 4096;
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "/var/named/named.local";
};

zone "example.com" {
        type master;
        file "/var/named/example.com.db";
};


I think that's what you asked for.  In case I misunderstood, here's a zone
entry from the slave's named.conf (this immediately follows the options
block in my first email:


zone "example.com" {
        type slave;
        file "/var/named/slaves/example.com.db";
        masters { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
};



On Tue, Jul 30, 2013 at 4:10 PM, Steven Carr <sjcarr at gmail.com> wrote:

> On 30 July 2013 20:31, Brandon Whaley <brandonw at inmotionhosting.com>wrote:
>
>> Sorry for the bump here, but through extensive troubleshooting I've
>> identified a trend in this.  It appears that zones hosted on the
>> lower-numbered masters are still updating without issue.  This leads me to
>> believe that something is causing BIND to "forget" the later cluster
>> servers, as the logs show that it doesn't even try to query them for zone
>> updates.  Is this known behavior?  Perhaps a network failure causes a
>> master to be marked "bad" in newer versions of BIND?  Restarting named on
>> the slave continues to correct the problem, so for now I'm (unfortunately)
>> restarting named frequently on this slave.
>>
>
> Can you post a snippet of one of your secondary zone config stanzas so we
> can see how you have the slave zone configured.
>
> From previous posts to the list I think it was identified that BIND will
> contact the first master server listed and failover to the second master if
> the first wasn't contactable, but then it would ignore any additional
> masters.
>
> Would be good to get some clarification on this from ISC, I've tried to
> trace my way through the source code and can't identify where BIND decides
> which master to update from, all I can find is the code where it goes to
> cleanup if the server isn't contactable (bind-9.9.3-P2/lib/dns/zone.c
> ln:13647), but can't see where it would then choose another one and try
> again.
>
> Steve
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
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/20130730/fe1a9c39/attachment.html>