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
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
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 {
- 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 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. lkc...@ksu.eduwrote:
--
I think that's what you asked for. In case I
On 30 July 2013 21:38, Brandon Whaley brand...@inmotionhosting.com 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
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
In article mailman.968.1375218342.20661.bind-us...@lists.isc.org,
Lawrence K. Chen, P.Eng. lkc...@ksu.edu 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
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
On 30 July 2013 22:52, Brandon Whaley brand...@inmotionhosting.com 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
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
On 30 July 2013 23:19, Brandon Whaley brand...@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
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
13 matches
Mail list logo
