Installing and Configuring the DNS slave Server.

h3. Installing and Configuring the DNS slave Server.

We are using the chrooted environment for Bind. so that the base configuration path would be {code}/var/named/chroot/var/named{code}

For non glam dns we will build the caching name server.


h5. Install the required packages

{code}
# yum update -y
# yum install bind bind-utils -y
# yum install bind-chroot -y
#yum install caching-nameserver.x86_64


You should have following packages installed,

bind-chroot-9.3.6-20.P1.el5_8.5
bind-9.3.6-20.P1.el5_8.5
ypbind-1.19-12.el5_6.1
bind-utils-9.3.6-20.P1.el5_8.5
bind-libs-9.3.6-20.P1.el5_8.5
caching-nameserver-9.3.6-20.P1.el5_8.5


{code}

h5. Next step would be to create the named.conf file. Rather than  creating it from scratch, it would be much easier to copy it from any existing slave server.

So take backup of existing /etc/named.conf and scp the  named.conf file from existing slave server at location {code}/var/named/chroot/etc/named.conf{code}

And then create the softlink

{code}
# ls -l /etc/named.conf
lrwxrwxrwx 1 root root 32 Oct 17 00:50 /etc/named.conf -> /var/named/chroot/etc/named.conf

Verify the named configuration, using below command,

# named-checkconf ; echo $?
0

{code}


h5. Master server setup

On master you have to perform two major changes,

* Edit the named.conf and add the IP range of the new slave server in the acl "my_networks"


* Add the NS record of new slave server in every zone file, e.g.

{code}

;  This is a list of all of the named servers for this domain.   The first
;  is the primary (us) and the rest are our various secondaries
;
;  WARNING: cannot list as a nameserver any machine that forwards to mac

@                       IN      NS              tiber.tipsntraps.com
@                       IN      NS              slavetiber.tipsntraps.com


{code}

* Restart the named on both master and slave.

make sure you perform the configtest before restarting the named.


h5. how to perform the confitest

{code}


# named-checkconf ; echo $?
0

# /etc/init.d/named configtest
zone tipsntraps.com/IN: loaded serial 2013121908
{code}


h3. Make sure all the zone files are transferred in the newly configured slave properly, the zone defination files would be located at,

{code}/var/named/chroot/var/named/slaves/{code}

h3. Testing

Change the Serial of one of the zone file on master and do rndc reload , confirm that the change is propagated successfully on the new slave.



h3. Monitoring

We have DNS-Zone-CHECK monitoring in place on master server, which checks that all the zone files defined in master are also setup on the slave server. This monitoring also checks the Serial of every domain of slave server against the master server.

To enable this monitoring, add  the line in file {code}

/etc/check_mk/mrpe.cfg

Note- please pass the appropriate slave server name as second argument

### DNS zone check for rsukapp2
DNS-ZONE-CHECK-slavename /etc/nagios/scripts/check_dns_slave.sh  <master>  <slave>


{code}

once you have added this line in mrpe.cfg, take the re-inventory of the master dns server in check_mk and restart it.

DNS replication slow

Recently at work  I added two new DNS slave servers. We are using BIND 9 as a DNS server.

To my surprise I noticed that the the slave replication on these two boxes were extremely slow, infact after changing the SOA of the zone file it  was taking almost hours to replicate that to these slave boxes.

The other slave boxes were working perfectly fine.

I started digging into it.

/etc/named.conf on both the slaves was looking fine , in fact it was copied from the older running slave servers.

From master the telnet to port 53 was working.

There was no symptoms of any error in the log files.



The gotcha :

after much of debugging and goggling I found the gotcha, that none of the zone files on my master had declared these new slave servers as NS. so ... I added those entries chnaged the serial and restarted named on master. And issue resolved.

@                       IN      NS              tiber1.tipsntraps.com.
@                       IN      NS              tiber1.tipsntraps.com.


Conclusion :

After looking around I found that -

When the serial number is changed on the master, it will notify the slave immediately. In other words,notify is enabled by default. 

BUT, the way notify works is, the master looks at the NS records of that particular domain in the zone file, and notifies the servers listed in the NS record, excluding itself.

if your slave server's hostname is not  listed as an NS record in the zone file;  The slave will  contact the master, listed in the slave's config file - masters { X.X.X.X; }; at the defined Refresh interval.

 And that is why it is taking long time to update to the slave initially. 

YUM rollback in Centos 5 and 6

http://kernelmount.com/content/view/147/9/

Preserving the Environment variable for sudo

There is setting in the suodoers file , using which you can preserve the environment variable while using sudo.


Its called env_keep, see how  I have preserved the YUM0 variable for sudo access.

{code}

#
# Preserving HOME has security implications since many programs
# use it when searching for configuration files. Note that HOME
# is already set when the the env_reset option is enabled, so
# this option is only effective for configurations where either
# env_reset is disabled or HOME is present in the env_keep list.
#
Defaults    always_set_home

Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults    env_keep += "YUM0"

{code}