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