Have you found a solution? Did u allow master dns server to update the slave in /etc/named.conf ? -----Original Message----- From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of John R Pierce Sent: Monday, January 12, 2015 7:02 AM To: centos at centos.org Subject: Re: [CentOS] Zone file not written to slave DNS server On 1/11/2015 9:28 PM, Emmett Culley wrote:> I have mostly succeeded in getting master and slave DNS servers operational. Mostly, because the zone file is not written when a zone is updated on the master server when the notify and transfer process happens. > > The slave DNS server gets the changes to the modified zone, but the slave zone file remains as before. I've found a few tutorials and lots of discussions, many of which talk about the slave's zone file getting written upon transfer, but none mention what configuration option would cause the slave's files to get updated. > > The master is on a Cantos 6 server and the slave is on a Cantos 7 machine.does the named service have write access to the slave directory ? chown named.named /path-to-named/slave oh, is your slave chrooted? are you looking in the right directory, eg, /var/named/chroot/var/named/slave ? -- john r pierce 37N 122W somewhere on the middle of the left coast _______________________________________________ CentOS mailing list CentOS at centos.org http://lists.centos.org/mailman/listinfo/centos
On 01/13/2015 12:10 PM, Mateusz Guz wrote:> Have you found a solution? > > Did u allow master dns server to update the slave in /etc/named.conf ? > > > > -----Original Message----- > From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of John R Pierce > Sent: Monday, January 12, 2015 7:02 AM > To: centos at centos.org > Subject: Re: [CentOS] Zone file not written to slave DNS server > > On 1/11/2015 9:28 PM, Emmett Culley wrote: >> I have mostly succeeded in getting master and slave DNS servers operational. Mostly, because the zone file is not written when a zone is updated on the master server when the notify and transfer process happens. >> >> The slave DNS server gets the changes to the modified zone, but the slave zone file remains as before. I've found a few tutorials and lots of discussions, many of which talk about the slave's zone file getting written upon transfer, but none mention what configuration option would cause the slave's files to get updated. >> >> The master is on a Cantos 6 server and the slave is on a Cantos 7 machine. > > does the named service have write access to the slave directory ? chown > named.named /path-to-named/slave > > oh, is your slave chrooted? are you looking in the right directory, eg, > /var/named/chroot/var/named/slave ? > >I am seeing the following in the log: Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.792 general: info: zone mydomain.com/IN: Transfer started. Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.885 xfer-in: info: transfer of 'mydomain.com/IN' from xx.xx.xxx.xxx#53: connected using 66.208.208.151#40226 Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.948 general: info: zone mydomain.com/IN: transferred serial 112 Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.948 xfer-in: info: transfer of 'mydomain.com/IN' from xx.xx.xxx.xxx#53: Transfer completed: 1 messages, 38 records, 898 bytes, 0.063 secs (14253 bytes/sec) Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.949 notify: info: zone mydomain.com/IN: sending notifies (serial 112) Yet the slaves/mydomain.com.db file does not get updated. There must be an option I am not setting correctly. Slave config: Global: options { allow-notify { mas.ter.IPa.ddr; }; allow-transfer { mas.ter.IPa.ddr; }; . . . }; Per zone: zone "mydomain.com." IN { type slave; file "slaves/mydomain.com.db"; masters { mas.ter.IPa.ddr; }; }; Master config: Global: options { allow-transfer { sla.ve.IP.net/28; 127.0.0.1; }; also-notify { sla.ve.IPa.ddr; }; allow-update { none; }; notify explicit; . . . }; I also tried it with allow-update set to slaves IP address, even though I was sure that option was about dynamic DNS, not zone transfer to a slave. Of course that didn't work either. Emmett
On 14/01/2015 03:56, Emmett Culley wrote:> On 01/13/2015 12:10 PM, Mateusz Guz wrote: >> Have you found a solution? >> >> Did u allow master dns server to update the slave in /etc/named.conf ? >> >> >> >> -----Original Message----- >> From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of John R Pierce >> Sent: Monday, January 12, 2015 7:02 AM >> To: centos at centos.org >> Subject: Re: [CentOS] Zone file not written to slave DNS server >> >> On 1/11/2015 9:28 PM, Emmett Culley wrote: >>> I have mostly succeeded in getting master and slave DNS servers operational. Mostly, because the zone file is not written when a zone is updated on the master server when the notify and transfer process happens. >>> >>> The slave DNS server gets the changes to the modified zone, but the slave zone file remains as before. I've found a few tutorials and lots of discussions, many of which talk about the slave's zone file getting written upon transfer, but none mention what configuration option would cause the slave's files to get updated. >>> >>> The master is on a Cantos 6 server and the slave is on a Cantos 7 machine. >> >> does the named service have write access to the slave directory ? chown >> named.named /path-to-named/slave >> >> oh, is your slave chrooted? are you looking in the right directory, eg, >> /var/named/chroot/var/named/slave ? >> >> > I am seeing the following in the log: > > Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.792 general: info: zone mydomain.com/IN: Transfer started. > Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.885 xfer-in: info: transfer of 'mydomain.com/IN' from xx.xx.xxx.xxx#53: connected using 66.208.208.151#40226 > Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.948 general: info: zone mydomain.com/IN: transferred serial 112 > Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.948 xfer-in: info: transfer of 'mydomain.com/IN' from xx.xx.xxx.xxx#53: Transfer completed: 1 messages, 38 records, 898 bytes, 0.063 secs (14253 bytes/sec) > Jan 13 12:08:44 g1 named[16370]: 13-Jan-2015 12:08:44.949 notify: info: zone mydomain.com/IN: sending notifies (serial 112) > > Yet the slaves/mydomain.com.db file does not get updated. There must be an option I am not setting correctly. > > Slave config: > > Global: > options { > allow-notify { mas.ter.IPa.ddr; }; > allow-transfer { mas.ter.IPa.ddr; };Neither of these are needed on slave servers.> . > . > . > }; > > Per zone: > zone "mydomain.com." IN { > type slave; > file "slaves/mydomain.com.db"; > masters { mas.ter.IPa.ddr; }; > }; > > > Master config: > > Global: > options { > allow-transfer { sla.ve.IP.net/28; 127.0.0.1; }; > also-notify { sla.ve.IPa.ddr; };This is not needed on the master server, unless the slave is not listed in the zone, or if the salve is on a different IP to the on defined in the zone (e.g. if the slave is behind a NAT and DNS lists it's NAT IP)> allow-update { none; }; > notify explicit; > . > . > . > }; > > I also tried it with allow-update set to slaves IP address, even though I was sure that option was about dynamic DNS, not zone transfer to a slave. Of course that didn't work either. > > Emmett >You should check the permissions on the slaves folder to make sure named can write to it, also you should check if you have SElinux enabled, and if so check that the slaves folder is labelled as named_cache_t For example: [root at ns5 ~]# ll -Zd /var/named/slaves drwxrwx---. named named system_u:object_r:named_cache_t:s0 /var/named/slaves [root at ns5 ~]# ll -d /var/named/slaves drwxrwx---. 2 named named 4096 Jan 14 10:47 /var/named/slaves Tris ************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster at bgfl.org The views expressed within this email are those of the individual, and not necessarily those of the organisation *************************************************************