Subdomains and Slaves

Adding a subdomain to a DNS server is a simple matter of creating an additional master entry in the named.conf file, and then placing name server and authority entries for that subdomain in your primary DNS server's zone file. The subdomain, in turn, has its own zone file with its SOA record and entries listing hosts, which are part of its subdomain, including any of its own mail and news servers.

Subdomain Zones

The name for the subdomain could be a different name altogether or a name with the same suffix as the primary domain. In the following example, the subdomain is called beach.mytrek.com. It could just as easily be called mybeach.com. The name server to that domain is on the host crab.beach.mytrek.com, in this example. Its IP address is 192.168.0.33 and its zone file is beach.mytrek.com. The beach.mytrek.com zone file holds DNS entries for all the hosts being serviced by this name server. The following example shows zone entries for its named.conf:

zone "beach.mytrek.com" {
          type master;
          file "beach.mytrek.com";
          };
   
zone "1.168.192.IN-ADDR.ARPA" {
          type master;
          file "192.168.0";
          };

Subdomain Records

On the primary DNS server, in the example turtle.mytrek.com, you would place entries in the master zone file to identify the subdomain server's host and designate it as a name server. Such entries are also known as glue records. In this example, you would place the following entries in the mytrek.com zone file on turtle.mytrek.com:

beach.mytrek.com.   IN    NS    beach.mytrek.com.
beach.mytrek.com.   IN    A     192.168.0.33.

URL references to hosts serviced by beach.mytrek.com can now be reached from any host serviced by mytrek.com, which does not need to maintain any information about the beach.mytrek.com hosts. It simply refers such URL references to the beach.mytrek.com name server.

Slave Servers

A slave DNS server is tied directly to a master DNS server and periodically receives DNS information from it. You use a master DNS server to configure its slave DNS servers automatically. Any changes you make to the master server are automatically transferred to its slave servers. This transfer of information is called a zone transfer. Zone transfers are automatically initiated whenever the slave zone's refresh time is reached or the slave server receives a notify message from the master. The refresh time is the second argument in the zone's SOA entry. A notify message is automatically sent by the master whenever changes are made to the master zone's configuration files and the named daemon is restarted. In effect, slave zones are automatically configured by the master zone, receiving the master zone's zone files and making them their own.

Slave Zones

Using the previous examples, suppose you want to set up a slave server on rabbit.mytrek.com. Zone entries, as shown in the following example, are set up in the named.conf configuration file for the slave DNS server on rabbit.mytrek.com. The slave server is operating in the same domain as the master, and so it has the same zone name, mytrek.com. Its SOA file is named slave.mytrek.com. The term "slave" in the filename is merely a convention that helps identify it as a slave server configuration file. The masters statement lists its master DNS server—in this case, 192.168.0.1. Whenever the slave needs to make a zone transfer, it transfers data from that master DNS server. The entry for the reverse mapping file for this slave server lists its reverse mapping file as slave.192.168.0.

zone "mytrek.com" {
         type slave;
         file "slave.mytrek.com";
         masters { 192.168.0.1;
         };
   
zone "1.168.192.IN-ADDR.ARPA" {
          type slave;
          file "slave.192.168.0";
          masters { 192.168.0.1;
          };

Slave Records

On the master DNS server, the master SOA zone file has entries in it to identify the host that holds the slave DNS server and to designate it as a DNS server. In this example, you would place the following in the mytrek.com zone file:

         IN       NS       192.168.0.2

You would also place an entry for this name server in the mytrek.com reverse mapping file:

         IN       NS       192.168.0.2

Controlling Transfers

The master DNS server can control which slave servers can transfer zone information from it using the allow-transfer statement. Place the statement with the list of IP addresses for the slave servers to which you want to allow access. Also, the master DNS server should be sure its notify option is not disabled. The notify option is disabled by a "notify no" statement in the options or zone named.conf entries. Simply erase the "no" argument to enable notify.

Incremental Zone Transfers

With BIND versions 8.2.2 and 9.0, BIND now supports incremental zone transfers (IXFR). Previously, all the zone data would be replaced in an update, rather than changes such as the addition of a few resource records simply being edited in. With incremental zone transfers, a database of changes is maintained by the master zone. Then only the changes are transferred to the slave zone, which uses this information to update its own zone files. To implement incremental zone transfers, you have to turn on the maintain-ixfr-base option in the options section.

maintain-ixfr-base yes;

You can then use the ixfr-base option in a zone section to specify a particular database file to hold changes.

ixfr-base "db.mytrek.com.ixfr";