On 30 July 2013 23:19, Brandon Whaley 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 t
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 c
On 30 July 2013 22:52, Brandon Whaley wrote:
> Once every few minutes the reload occurs on the master, which sends the
> notify to our slave servers, who should check serials on all the masters
> and transfer from the latest.
>
I think this is your problem. From what I understand BIND does not d
The logs do seem to only check the first 1-2 servers in the forwarders
section when the problem is occurring. If named is restarted on this
slave, it will check all the servers, as expected when it receives a notify.
We have our zones distributed among 5 masters to speed updates. The
software we
In article ,
"Lawrence K. Chen, P.Eng." wrote:
> Oh, guess I got it mixed up because the slave is saying it got
> non-authoritative answers from 10.0.x.1.. where I think of the master should
> at least be authoritative for its domain.
It *should* be. But if it gets an error loading the zone
Oh, guess I got it mixed up because the slave is saying it got
non-authoritative answers from 10.0.x.1.. where I think of the master should at
least be authoritative for its domain.
- Original Message -
> Hey Lawrence, this is the zone entry as seen on the 10.10.10.1 slave.
> The 10.0.
On 30 July 2013 21:38, Brandon Whaley wrote:
> 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; };
> };
>
So given what I mentioned before I would envisage BIND contacting 10.0.1.1
Hey Lawrence, this is the zone entry as seen on the 10.10.10.1 slave. The
10.0.x.1 IPs are the addresses of the masters.
On Tue, Jul 30, 2013 at 4:43 PM, Lawrence K. Chen, P.Eng. wrote:
>
>
> --
>
>
> I think that's what you asked for. In case I misunderstood, here'
- Original Message -
> 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
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 {
On 30 July 2013 20:31, Brandon Whaley 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 BI
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 s
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 st
13 matches
Mail list logo
