==== Being a slave DNS server ====

I should point out here that "master" and "slave" is somewhat outdated 
wording. The more modern wording, "primary" and "replica", is more 
accurate. However, since this document was written back when "master" 
and "slave" was standard terminology, since other mainstream DNS 
servers still use the "master" and "slave" terminology, and since the 
relevant DNS RFCs MaraDNS is based on use the words "master" and 
"slave", this document uses that wording. 

=== Having MaraDNS be a slave DNS server ===

MaraDNS does not have direct support for being a slave DNS server. 
However, MaraDNS can transfer zone files from other servers by using 
the fetchzone client. 

fetchzone is a program that can transfer a zone from another name 
server; the transferred zone is in the csv2 zone file format, which can 
then be loaded by MaraDNS. 

Here is an example of using fetchzone to transfer the zone example.com 
from the server with the IP 10.5.6.7, placing the output in the file 
"db.example.com":

fetchzone example.com 10.5.6.7 > db.example.com

== Automating this with a shell script ==

If one wishes to use fetchzone to grab a number of zones, this can be 
automated with a shell script:

#!/bin/bash 
 
cd /etc/maradns 
fetchzone example.com 10.5.6.7 > db.example.com 
fetchzone example.org 192.168.5.67 > db.example.org 
fetchzone example.net 172.19.2.83 > db.example.net

This shell script, however, has a problem. Should there be a 
problem getting a zone file from a remote system, the zone file in 
question will be destroyed. This can be avoided by checking the exit 
status of fetchzone in the shell script, making sure that the zone was 
obtained normally before overwriting the zone file:

#!/bin/bash 
 
# For security reasons, put this file in a directory that only root 
# may write to.   
TEMP=/root/tmp/foo 
 
cd /etc/maradns 
fetchzone example.com 10.5.6.7 > $TEMP 
if [ $? -eq 0 ] ; then 
	mv $TEMP db.example.com 
fi 
fetchzone example.org 192.168.5.67 > $TEMP 
if [ $? -eq 0 ] ; then 
	mv $TEMP db.example.org 
fi 
fetchzone example.net 172.19.2.83 > $TEMP 
if [ $? -eq 0 ] ; then 
	mv $TEMP db.example.net 
fi

Note that this script needs a directory, which only root may 
write to, named /root/tmp (Linux has a long-standing tradition of 
making root's home directory /root; place this file elsewhere on a 
system with a different root directory). 

While this script is workable for a small number of zones, this script 
will quickly become unwieldy for a large number of zones. If one wants 
to grab a large number of zones, it makes more sense to have the list 
of zones in a separate file. We then have the shell script read this 
file (list of zones and IPs), and make the zone files live if the zones 
have been successfully fetched. 

Here is what a shell script may look like:

#!/bin/bash 
 
ZONELIST=/etc/maradns.zonelist 
# For security reasons, put this file in a directory that only root 
# may write to.   
TEMP=/root/tmp/foo 
 
cd /etc/maradns 
 
cat $ZONELIST | awk '{print "fetchzone "$1" "$2" > '$TEMP'" 
                      print "if [ $? -eq 0 ] ; then" 
		      print "    mv '$TEMP' db."$1 
		      print "fi";}' | sh

The list of zones, which is in the file /etc/maradns.zonelist in 
the above example, will look like this:

example.com 10.5.6.7  
example.org 192.168.5.67  
example.net 172.19.2.83

Note that the presence of a given db.name file in the 
/etc/maradns directory is not sufficient for MaraDNS to load a given 
zone file; the zone file in question must be pointed to in the mararc 
file. Note also that maradns must be restarted to reload the updated 
zone files. 

More complicated scripting, such as checking the serial number before 
loading a given zone, is left as an exercise for the reader. 

== Bailiwick ==

For security reasons, the fetchzone client only allows records that end 
in the zone name to be in a given zone. In other words, let us suppose 
we have a zone for example.com that looks like this:

example.com.      10.1.2.3 
www.example.com.  10.99.88.76 
www.google.com.   10.99.88.76

fetchzone, when grabbing this zone, will disable the 
"www.google.com" record because it doesn't end with "example.com". The 
disabling will look something like this when the zone file is grabbed:

example.com. 10.1.2.3 
www.example.com. 10.99.88.76 
# Disabled out-of-bailiwick record follows 
#www.google.com. 10.99.88.76


