Secondary name servers – how to be a backup DNS for someone else

Secondary name servers – how to be a backup DNS for someone else

This topic was incomplete for far too long.  My apologies.  I finished it on
7 July 1999.

In this article, references to a "zone" are often made.  In
simple terms, you can think of a zone as a domain.  In practice, a zone file may deal
with a whole domain or just part of that domain (i.e. a sub-domain).  In most cases,
if you are looking at doing DNS for your own personal domain, my guess is that you will
have one file for that domain.  You can refer to that file as the zone or zone-file.

Primary/Secondary

It’s important to note the difference between a primary and a secondary
name server.  They are more correctly deemed master and slave.  A master DNS
server contains the zone files which dictate the IP addresses and hostnames for a zone. A
slave DNS server contains the same information, but must obtain its information from a
master DNS server.  For example, when a primary name server starts, it reads the zone
information from files on the disk.  However, when a slave name server starts, it
asks the primary for the information.

Zone setup

I’ve started to look into secondary DNS.  Mostly because I wanted someone else to
provide me with that service and they didn’t know how to do it.

Here’s what you need for
BIND8.  Add the following extract to named.conf.   The default
location for this file is /etc/namedb/named.conf.

zone "racingsystem.cx" {
	type slave;
	file "secondary/db.racingsystem.cx";
	masters {209.222.164.7;};
	}

The name of the domain you are being secondary server for is racingsystem.cx.  The
zone files, as obtained from the master server, will be stored in secondary/db.racingsystem.cx.
  This path will be relative to whatever is defined in /etc/named.conf as
the directory for named to use.  In my case, this is:

options {          
        directory "/etc/namedb";
	}

With this setup, the zone files for racingsystem.cx will be stored in:

/etc/namedb/secondary/db.racingsystem.cx

The master DNS server is located at 209.222.164.7.

After you add the above to your named.conf file, do an ndc reload,
check your /var/log/messages for an errores, and you’re set

allowing transfers

It is a good idea to allow only your secondary servers to transfer the
zone information.  From a security point of few, the less you provide to third
parties, the better it is for you.  Most people have no valid reason for doing a zone
transfer (a zone transfer occurs when a slave server asks the primary server for the zone
information).  Fortunately, BIND provides an easy way to accomplish this security
goal.

You can permit zone transfers on a global basis or on a zone by zone basis.  
Which option you choose depends on what you prefer to do.  In my case, each of my
domains uses the same set of secondary servers.  Rather than repeat the same set of
IP addresses over and over again for each domain, I use the global approach.   Here’s
my example:

allow-transfer {127.0.0.1; 192.168/16;
                aa.bb.cc.dd; ee.ff.gg.hh; };

In this case, I’m allowing zone transfers to the local host, my local subnet, and my
two secondary servers, as identified by aa.bb.cc.dd and ee.ff.gg.hh.
  The allow-transfer statement goes in the main section of named.conf.

You can also include the allow-transfer statement within a particular zone.  
Here’s an example:

zone "freebsddiary.org" {
        type master;
        file "freebsddiary.org.db";
        allow-transfer {127.0.0.1; 192.168/16; aa.bb.cc.dd; };
        // local host, subnet, my secret secondary server
        };

In this example, I’m again allowing transfers to localhost, local subnet, and to my
secondary server.

  • 127.0.0.1 – this allows me to run nslookup on the DNS server and
    do a zone transfer.  That capability can be very useful when debugging your DNS.
  • 192.168/16 – this allows any machine in the 192.168.*.* subnet to do a zone
    transfer, much the same as localhost.
  • aa.bb.cc.dd – a secondary server must be allowed to do a zone transfer.
      If it can’t, then it won’t be able to read the zone information and will not be
    able to act as a DNS server.

named.conf

As mentioned above, the default location for this file is /etc/namedb/named.conf.
  However, I like to keep things in /etc.  So I created the following
symbolic link:

# cd /etc/namedb
# ln -s /etc/named.conf named.conf

Note that I already had a named.conf in /etc, so I did the link
as above.  However, if you prefer to keep your named.conf in /etc/namedb,
then you need to make the link the other way around.

# cd /etc
# ln -s /etc/namedb/named.conf named.conf

Additional notes (added on 17 July 2000)

Sid Lambert wrote in with these tips
in case you are having trouble.  The first is to add the word "IN".  
The second is add a space before and after the IP address of the primary.   Taking my
original case as an example:

zone "racingsystem.cx" IN {
	type slave;
	file "secondary/db.racingsystem.cx";
	masters { 209.222.164.7; };
	}

Note there is a space before the IP address and a space following the semi-colon after
the IP address.

1 thought on “Secondary name servers – how to be a backup DNS for someone else”

  1. It’s one thing to set up a secondary server. It’s another to make it used. Unless your secondary servers are specified in the DNS with an NS record *and* listed in your names servers with your DNS registrar, the secondaries are useless.

Leave a Comment

Scroll to Top