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 <sjc...@gmail.com> wrote:
> On 30 July 2013 20:31, Brandon Whaley <brand...@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@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_feedb...@inmotion.net
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
