When implementing redundancy as far as DNS is concerned, automated is always better. In a hosting environment, new zone files are constantly being created.
This need for a DNS master/slave implementation where new zone files are transferred between the master nameserver and the slave became apparent as operations grew and geographic DNS redundancy became apparent.
Obviously some commercial dns products provide this type of functionality out-of-the-box, but I will show you how to do this with a simple Bind DNS distribution.
I wrote this tutorial to help you, hopefully, to create an automated DNS slave / zone file transfer environment. Obviously you can create as many slave servers as you feel necessary.
MASTER Server
1. Edit /etc/named.conf and add the following to the options section where xx.xx.xx.xx is the ip of your slave server.:
2. Create a script with the following, where somedirectory is the directory on your SLAVE server to store the slave zones and where yy.yy.yy.yy is your MASTER server ip and somewwwdir is a directory browsable via http and finally someslavefile.conf is the output file to write you slave config:
3. Test the script to ensure it is writing out the appropriate format.
4. Run the script as any user with permission to write to an http visible directory via cron.
SLAVE SERVER
1. Transfer the rndc.key file from your master server to the slave :
2. Edit ns1rndc.key and change the name of the key definition.
3. Edit named.conf and add the following to the options section:
4. Append the following to the named.conf file:
5. Run the following commands
6. Create a script:
7. Add to root’s crontab
In the second slave script, you see that the transfer is done via wget. This can be replaced by many other more secure methods. If ssh based key authentication is employed, a simple scp or even rsync can be utilized to accomplish the actual zone transfer.
This need for a DNS master/slave implementation where new zone files are transferred between the master nameserver and the slave became apparent as operations grew and geographic DNS redundancy became apparent.
Obviously some commercial dns products provide this type of functionality out-of-the-box, but I will show you how to do this with a simple Bind DNS distribution.
I wrote this tutorial to help you, hopefully, to create an automated DNS slave / zone file transfer environment. Obviously you can create as many slave servers as you feel necessary.
MASTER Server
1. Edit /etc/named.conf and add the following to the options section where xx.xx.xx.xx is the ip of your slave server.:
allow-transfer { xx.xx.xx.xx; };
2. Create a script with the following, where somedirectory is the directory on your SLAVE server to store the slave zones and where yy.yy.yy.yy is your MASTER server ip and somewwwdir is a directory browsable via http and finally someslavefile.conf is the output file to write you slave config:
#!/bin/sh
#
for domain in `/bin/grep ^zone /etc/named.conf |/bin/grep "type master" |/bin/awk '{print $2}' |/bin/awk -F" '{print $2}'`
do
/usr/bin/printf "zone "${domain}" { type slave; file "/var/named/slaves/somedirectory/${domain}.db"; masters { yy.yy.yy.yy; }; };n"
done > /var/www/html/somewwwdir/someslavefile.conf
#
for domain in `/bin/grep ^zone /etc/named.conf |/bin/grep "type master" |/bin/awk '{print $2}' |/bin/awk -F" '{print $2}'`
do
/usr/bin/printf "zone "${domain}" { type slave; file "/var/named/slaves/somedirectory/${domain}.db"; masters { yy.yy.yy.yy; }; };n"
done > /var/www/html/somewwwdir/someslavefile.conf
3. Test the script to ensure it is writing out the appropriate format.
4. Run the script as any user with permission to write to an http visible directory via cron.
0 4 * * * /path/to/script > /dev/null 2>&1
SLAVE SERVER
1. Transfer the rndc.key file from your master server to the slave :
scp MASTERSERVER:/etc/rndc.key /etc/ns1rndc.key
2. Edit ns1rndc.key and change the name of the key definition.
3. Edit named.conf and add the following to the options section:
allow-transfer { zz.zz.zz.zz; };
4. Append the following to the named.conf file:
include "/etc/ns1rndc.key";
include "/path/to/someslavefile.conf";
include "/path/to/someslavefile.conf";
5. Run the following commands
touch /path/to/someslavefile.conf
mkdir /var/named/slaves/somedirectory/
chown -R named:named /var/named/slaves/somedirectory/
/etc/init.d/named restart
mkdir /var/named/slaves/somedirectory/
chown -R named:named /var/named/slaves/somedirectory/
/etc/init.d/named restart
6. Create a script:
#!/bin/sh
/usr/bin/wget http://yy.yy.yy.yy/somewwwdir/someslavefile.conf -O /var/named/slaves/someslavefile.conf
/etc/init.d/named restart
/usr/bin/wget http://yy.yy.yy.yy/somewwwdir/someslavefile.conf -O /var/named/slaves/someslavefile.conf
/etc/init.d/named restart
7. Add to root’s crontab
0 4 * * * /path/to/script
In the second slave script, you see that the transfer is done via wget. This can be replaced by many other more secure methods. If ssh based key authentication is employed, a simple scp or even rsync can be utilized to accomplish the actual zone transfer.
150 - master DNS, 162 - slave DNS
ReplyDeleteexample.com is the master zone on 150
On master machine, 150, named.conf
zone "example.com" {
type master;
file "/var/named/example.hosts";
};
On /var/named/chroot/var/named/example.hosts
$ttl 38400
example.com. IN SOA example.com. jho.email.com. (
1173888569
10800
3600
604800
38400 )
example.com. IN NS example.com.
www.example.com. IN A 172.16.95.150
On slave machine, 162, /etc/named.conf
include "/etc/rndc.key";
include "/var/named/slaves/example.hosts";
On 162, /var/named/slaves/example.hosts
[root@mail slaves]# cat example.hosts
zone "example.com" {
type slave;
masters {
172.16.95.150;
};
file "/var/named/slaves/example.hosts";
};
service named restart, zone update occur. The db-XXnFLVQa is the backup text file of the pre-update zone config. The example.hosts is the updated zone config.
[root@mail slaves]# ls
db-XXnFLVQa example.hosts
[root@mail slaves]# cat example.hosts
$ORIGIN .
$TTL 38400 ; 10 hours 40 minutes
example.com IN SOA example.com. jho.email.com. (
1173888569 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
38400 ; minimum (10 hours 40 minutes)
)
NS example.com.
$ORIGIN example.com.
www A 172.16.95.150
http://www.zytrax.com/books/dns/ch7/xfer.html
ReplyDeleteoptions {
....
// ban everyone by default
allow-transfer {"none";};
};
...
zone "example.com" in{
....
// explicity allow the slave(s) in each zone
allow-transfer (172.16.95.164;); //not our slave server
};
From /var/log/messages:
Mar 6 18:13:34 mail named[5641]: transfer of 'example.com/IN' from 172.16.95.150#53: failed while receiving responses: REFUSED
Mar 6 18:13:34 mail named[5641]: transfer of 'example.com/IN' from 172.16.95.150#53: end of transfer
http://www.itworld.com/it-managementstrategy/72646/serial-numbers-zone-files-yours-and-nameds
ReplyDeleteSerial numbers in DNS zone files provide a way for the server to verify that the contents of a particular zone file are up-to-date. If the serial number in a zone file hasn't changed since that zone was last loaded, named figures that it can ignore the file. This means that sysadmins have to remember to update the serial number every time they make a change to a zone file -- otherwise, their changes won't be picked up and published.
http://forums.cpanel.net/f5/dns-zone-file-values-20480.html
ReplyDeletewell, this is basic DNS stuff and I recommend reading about it since it can turn all your sites dark if you make a mistake.
DNS is a serious science and not to be taken too lightly!
>refresh: 28800
this line defines that every 28800 seconds the secondary nameservers will be refreshed with the current zone file information
>retry: 7200
this line defines that every 7200 seconds a secondary nameserver will retry to get the current zone file information if the previous attempt failed
>expire: 3600000
this line defines how long secondary nameservers will give out zone file data if they are no longer able to connect and update zone file information from the primary name server.
the default value in cpanel is extremely long and much longer than normally suggested by the developers of bind
>minimum ttl: 86400
This line is probably the most important. It defines the ttl (time to live) for the zone. But be careful since every record within the zone can have its own ttl value. This means how long other caching nameservers on the net will store your zonefile information after it has been requested.
Here a couple of comments from me and what I learned in Cricket Liu's classes about DNS (he is called Mr. DNS after all and has written great books on DNS and bind):
1. The nameserver configuration in cpanel allows non-authoritative lookups. That is not good practice and means that someone can abuse your nameserver and your bandwidth even if they are not a customer.
2. The nameserver configuartion in cpanel allows for zone transfers to everyone! This is a huge security risk since someone can look at your zonefile and sees right away what you have in there and what might look weak. For example there might be a host called beta.domain.com - perfect for a hacker to try to get to. If zonetransfers are only enabled between primary and secondary nameservers this cannot happen.
3. The default refresh time is 28800 in cpanel but the default ttl is 14000 for all records. This can create totally out of sync nameservers. Here is why. lets say I change a record in the primary nameserver for a domain and the update to the secondary does not work (and that happens a lot in cpanel) then the secondary has old information. This is normally not a problem but the old information will be stored twice as long as the ttl time for that record! This means that if a request comes in after the 14400 seconds are over but goes to one of the secondary DNS servers, they will give out the old information even though you might think and might have planned for a switch to happen after this time is up!
hope this helps and Josh can make this sticky since a lot of people ask this stuff.