The Domain Name Service

Slave name servers

A lot of software relies on name resolution. If for any reason a name server is not accessible, it can cause serious problems. This is one of the reasons why most registrars insist on at least two name servers before they will register a domain.

If you run multiple name servers, it doesn’t really matter which one answers. So why a distinction between master and slave name servers? It’s purely organizational: a master name server loads its data from the configuration files you create, as we saw above. A slave name server loads its data from a master name server if it is running. It saves the information in a private file so that if it is restarted while the master name server isn't running, it can reload information about the zones it is serving from this file. This makes it a lot easier to configure a slave name server, of course; everything we need is in /etc/namedb/named.conf:

zone "." {
  type hint;
  file "named.root";
};

zone "example.org" {
  type slave;
  file "backup.example.org";
  masters {
    223.147.37.1;
  };
};

zone "37.147.223.in-addr.arpa" { type slave;
  file "backup.example-reverse"; masters {
    223. 147. 37. 1;
  };
};

zone "0.0.127.in-addr.arpa" {
  type master;
  file "localhost.rev";
};

Although this is a slave name server, there's no point in being a slave for localhost's reverse mapping, so the last entry is still a master.

The numerical address is for freebie.example.org, the name server from which the zone is to be loaded. We use the numerical address because the name server needs the address before it can perform resolution. You can specify multiple name servers if you want. The backup file is the name of the file where the zone information should be saved incase the name server is restarted when the master name server is not accessible.

The next level down: delegating zones

In the previous example, we configured a name server for a single zone with no subzones. We did briefly consider what would happen if we created a sub domain china.example.org. In this section, we'll create the configuration files for this subzone and see how to link it to the parent zone, a process called delegation.

china.example.org

For the sub domain china.example.org, the same considerations apply as in our previous example: we have a domain without sub domains. Only the names and the addresses change.

In the following examples, let’s assume that china.example.org has two name servers, beijing.china.example.org and xianggang.china.example.org. Let’s look at the files we might have on these systems, starting with /etc/namedb/db.china.example.org:

; Definition of zone china.example.org
$TTL 1d
@          IN SOA    beijing.china.example.org zhang.china.example.org. (
                       2001061701 ; Serial (date, 2 digits version of day)
                       1d   ; refresh
                       2h   ; retry
                       100d ; expire
                       2h ) ; negative cache

; name servers
           IN NS     ns
           IN NS     ns1
ns         IN A      223.169.23.1
ns1        IN A      223.169.23.2

; MX records
           IN MX     50 xianggang.china.example.org.
           IN MX     70 bumble.example.org.
           IN MX     100 mail.example.net.

; Hosts
beijing    IN A      223.169.23.1
xianggang  IN A      223.169.23.2
shanghai   IN A      223.169.23.3
guangzhou  IN A      223.169.23.4
gw         IN A      223.169.23.5

; nicknames
www        IN CNAME  shanghai
ftp        IN CNAME  shanghai

Then, /etc/namedb/china-reverse:

; Definition of zone china.example.org
@    IN SOA  beijing.china.example.org. zhang.china.example.org. (
               1997090501 ; Serial (date, 2 digits version of day)
               86400      ; refresh (1 day)
               7200       ; retry (2 hours)
               8640000    ; expire (100 days)
               86400)     ; minimum (1 day)

; name servers
     IN NS   ns.china.example.org.
     IN NS   ns1.china.example.org.

; Hosts
1    IN PTR  beijing
2    IN PTR  xianggang
3    IN PTR  shanghai
4    IN PTR  guangzhou
5    IN PTR  gw

and finally /etc/namedb/named.conf :

zone "." {
  type hint;
  file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
  type master;
  file "localhost.rev";
};

zone "china.example.org" {
  type master;
  file "db.china.example.org";
};

zone "23.169.233.IN-ADDR.ARPA" {
  type master;
  file "china-reverse";
};

These files look very much like the corresponding files for example.org. The real difference happens in the configuration for example.org, not for china.example.org. We'll look at that next.