I have the following layout
DNS01 - Master DNS02 - Remote slave DNS03 - Local network slave
The master is configured so:
acl HLLnetworks { 209.47.176/24; 216.185.71/24; };
options { allow-query { any; }; allow-recursion { HLLnetworks; }; allow-transfer { HLLnetworks; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; query-source address 216.185.71.33; listen-on { 216.185.71.33; }; notify yes; };
The slaves are configured this way (appropriately modified for each ip address:
acl HLLnetworks { 209.47.176/24; 216.185.71/24; };
options { allow-query { any; }; allow-recursion { HLLnetworks; }; allow-transfer { HLLnetworks; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; notify no; // this is a slave server query-source address 209.47.176.33; listen-on { 127.0.0.1; }; listen-on { 209.47.176.33; }; forwarders { 216.185.71.33; }; };
Now, what I am seeing on one of the slaves when I change a zone in the master and reload is this:
Nov 3 12:47:49 inet06 named[9597]: received notify for zone 'byrnejb.ca'
but on the other I see this:
Nov 3 12:47:50 inet04 named[18368]: client 216.185.71.27#33829: received notify for zone 'byrnejb.ca' Nov 3 12:47:50 inet04 named[18368]: zone byrnejb.ca/IN: refused notify from non-master: 216.185.71.27#33829
The master configuration for byrnejb.ca is
zone "byrnejb.ca" { type master; file "/var/named/masters/byrnejb.ca.hosts"; };
On inet06 the slave zone configuration is:
zone "byrnejb.ca" { type slave; masters { 216.185.71.33; }; file "/var/named/slaves/byrnejb.ca.hosts"; };
and on inet04 it is:
zone "byrnejb.ca" { type slave; masters { 216.185.71.33; }; file "/var/named/slaves/byrnejb.ca.hosts"; };
Which is, as far as I can see, identical.
In any case, the real problem is that neither slave actually transfers the updated zone file and I cannot figure out why not. I have verified that the master zone file serial number is greater than that of the slave zones.
So, I have two questions:
1. Why is the source address 216.185.71.27 when the bind named listens on 216.185.71.33 and answers queries from the same address. Admittedly, 216.185.71.33 is a virtual ip hosted on 216.185.71.27 but we have been doing this for over a decade now and I have never seen this behaviour before.
2. Why are the notifies ignored? Again, we have had this set up for over a decade and none of these problems until now, and the only thing that has happened on the dns side of things recently were the CentOS updates last week.
I am not a DNS specialist, I set this up several years ago and I am perplexed as to why it is now giving me these difficulties. Any help would be gratefully appreciated.
Sincerely,
James B. Byrne wrote:
I have the following layout
DNS01 - Master DNS02 - Remote slave DNS03 - Local network slave
The master is configured so:
acl HLLnetworks { 209.47.176/24; 216.185.71/24; };
options { allow-query { any; }; allow-recursion { HLLnetworks; }; allow-transfer { HLLnetworks; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; query-source address 216.185.71.33; listen-on { 216.185.71.33; }; notify yes; };
The slaves are configured this way (appropriately modified for each ip address:
acl HLLnetworks { 209.47.176/24; 216.185.71/24; };
options { allow-query { any; }; allow-recursion { HLLnetworks; }; allow-transfer { HLLnetworks; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; notify no; // this is a slave server query-source address 209.47.176.33; listen-on { 127.0.0.1; }; listen-on { 209.47.176.33; }; forwarders { 216.185.71.33; }; };
Now, what I am seeing on one of the slaves when I change a zone in the master and reload is this:
Nov 3 12:47:49 inet06 named[9597]: received notify for zone 'byrnejb.ca'
but on the other I see this:
Nov 3 12:47:50 inet04 named[18368]: client 216.185.71.27#33829: received notify for zone 'byrnejb.ca' Nov 3 12:47:50 inet04 named[18368]: zone byrnejb.ca/IN: refused notify from non-master: 216.185.71.27#33829
The master configuration for byrnejb.ca is
zone "byrnejb.ca" { type master; file "/var/named/masters/byrnejb.ca.hosts"; };
On inet06 the slave zone configuration is:
zone "byrnejb.ca" { type slave; masters { 216.185.71.33; }; file "/var/named/slaves/byrnejb.ca.hosts"; };
and on inet04 it is:
zone "byrnejb.ca" { type slave; masters { 216.185.71.33; }; file "/var/named/slaves/byrnejb.ca.hosts"; };
Which is, as far as I can see, identical.
In any case, the real problem is that neither slave actually transfers the updated zone file and I cannot figure out why not. I have verified that the master zone file serial number is greater than that of the slave zones.
So, I have two questions:
- Why is the source address 216.185.71.27 when the bind named
listens on 216.185.71.33 and answers queries from the same address. Admittedly, 216.185.71.33 is a virtual ip hosted on 216.185.71.27 but we have been doing this for over a decade now and I have never seen this behaviour before.
- Why are the notifies ignored? Again, we have had this set up for
over a decade and none of these problems until now, and the only thing that has happened on the dns side of things recently were the CentOS updates last week.
I am not a DNS specialist, I set this up several years ago and I am perplexed as to why it is now giving me these difficulties. Any help would be gratefully appreciated.
If you want the master to use a certain one of several possible source addresses for notify operations you should probably set 'notify-source'.
On Tue, 2009-11-03 at 13:34 -0500, James B. Byrne wrote:
zone "byrnejb.ca" { type slave; masters { 216.185.71.33; }; file "/var/named/slaves/byrnejb.ca.hosts"; };
Which is, as far as I can see, identical.
In any case, the real problem is that neither slave actually transfers the updated zone file and I cannot figure out why not. I have verified that the master zone file serial number is greater than that of the slave zones.
So, I have two questions:
- Why is the source address 216.185.71.27 when the bind named
listens on 216.185.71.33 and answers queries from the same address. Admittedly, 216.185.71.33 is a virtual ip hosted on 216.185.71.27 but we have been doing this for over a decade now and I have never seen this behaviour before.
- Why are the notifies ignored? Again, we have had this set up for
over a decade and none of these problems until now, and the only thing that has happened on the dns side of things recently were the CentOS updates last week.
I am not a DNS specialist, I set this up several years ago and I am perplexed as to why it is now giving me these difficulties. Any help would be gratefully appreciated.
---- why not add the other ip address just in case on the slaves...
masters { 216.185.71.33; 216.185.71.27; };
you might also want to specifically add them to allow update...
acl HLLmasters { 216.185.71.33; 216.185.71.27; };
allow-update { HLLmasters; };
Craig
On Tue, November 3, 2009 13:34, James B. Byrne wrote:
In any case, the real problem is that neither slave actually transfers the updated zone file and I cannot figure out why not. I have verified that the master zone file serial number is greater than that of the slave zones.
This problem was mainly my own doing. Earlier today I had made a change to the allow-transfer clause on the master while trying to track down another issue and I forgot about it. Allow-transfer should, in almost all cases, be set to 'any;'.
I still have some named issues that have me puzzled but, no doubt, these will eventually yield to further investigation. One source of problems is that some of the servers are CentOS-4.8 running Bind 9.2.4 while others are centOS-5.4 running Bind 9.3.6 and there are differences in how the named.conf file is parsed.
Regards,