[CentOS] Zone file not written to slave DNS server

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
*************************************************************