9.4.1. Creating a Subdomain in the Parent's Zone

Partial contents of file db.movie.edu:

brazil.personnel      IN  A      192.253.253.10
                      IN  MX     10 brazil.personnel.movie.edu.
                      IN  MX     100 postmanrings2x.movie.edu.
employeedb.personnel  IN  CNAME  brazil.personnel.movie.edu.
db.personnel          IN  CNAME  brazil.personnel.movie.edu.

Notice that there's no SOA record for personnel.movie.edu ? There's no need for one, since the movie.eduSOA record indicates the start of authority for the entire movie.edu zone. Since there's no delegation to personnel.movie.edu, it's part of the movie.edu zone.

9.4.2. Creating and Delegating a Subdomain

We need to create a new subdomain of movie.edu for our special effects lab. We've chosen the name fx.movie.edu -- short, recognizable, unambiguous. Because we're delegating fx.movie.edu to administrators in the lab, it'll be a separate zone. The hosts bladerunner and outland, both within the special effects lab, will serve as the zone's name servers (bladerunner will serve as the primary master). We've chosen to run two name servers for the zone for redundancy -- a single fx.movie.eduname server would be a single point of failure that could effectively isolate the entire special effects lab. Since there aren't many hosts in the lab, though, we feel two name servers should be enough.

The special effects lab is on movie.edu's new 192.253.254/24 network.

Partial contents of /etc/hosts:

192.253.254.1 movie-gw.movie.edu movie-gw
# fx primary
192.253.254.2 bladerunner.fx.movie.edu bladerunner br
# fx secondary
192.253.254.3 outland.fx.movie.edu outland
192.253.254.4 starwars.fx.movie.edu starwars
192.253.254.5 empire.fx.movie.edu empire
192.253.254.6 jedi.fx.movie.edu jedi

Contents of file db.fx.movie.edu:

$TTL 1d
@  IN  SOA  bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. (
            1       ; serial
            3h      ; refresh
            1h      ; retry
            1w      ; expire
            1h )    ; negative caching TTL

    IN  NS  bladerunner
    IN  NS  outland

; MX records for fx.movie.edu
    IN  MX  10 starwars
    IN  MX  100 wormhole.movie.edu.

; starwars handles bladerunner's mail
; wormhole is the movie.edu mail hub

bladerunner  IN  A   192.253.254.2
             IN  MX  10 starwars
             IN  MX  100 wormhole.movie.edu.

br           IN    CNAME    bladerunner

outland      IN  A   192.253.254.3
             IN  MX  10 starwars
             IN  MX  100 wormhole.movie.edu.

starwars     IN  A   192.253.254.4
             IN  MX  10 starwars
             IN  MX  100 wormhole.movie.edu.

empire       IN  A   192.253.254.5
             IN  MX  10 starwars
             IN  MX  100 wormhole.movie.edu.

jedi         IN  A   192.253.254.6
             IN  MX  10 starwars
             IN  MX  100 wormhole.movie.edu.

$TTL 1d
@  IN  SOA  bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. (
            1       ; serial
            3h      ; refresh
            1h      ; retry
            1w      ; expire
            1h )    ; negative caching TTL

       IN    NS    bladerunner.fx.movie.edu.
       IN    NS    outland.fx.movie.edu.

1      IN    PTR   movie-gw.movie.edu.
2      IN    PTR   bladerunner.fx.movie.edu.
3      IN    PTR   outland.fx.movie.edu.
4      IN    PTR   starwars.fx.movie.edu.
5      IN    PTR   empire.fx.movie.edu.
6      IN    PTR   jedi.fx.movie.edu.

Next, we create an appropriate named.conf file for the primary master name server:

options {
                directory "/var/named";
};

zone "0.0.127.in-addr.arpa" {
                type master;
                file "db.127.0.0";
};

zone "fx.movie.edu" {
                type master;
                file "db.fx.movie.edu";
};

zone "254.253.192.in-addr.arpa" {
                type master;
                file "db.192.253.254";
};

zone "." {
                type hint;
                file "db.cache";
};

directory     /var/named

primary       0.0.127.in-addr.arpa      db.127.0.0  ; loopback
primary       fx.movie.edu              db.fx.movie.edu
primary       254.253.192.in-addr.arpa  db.192.253.254

cache         .                         db.cache

% h2n -d fx.movie.edu -n 192.253.254 -s bladerunner -s outland \
-u hostmaster.fx.movie.edu -m 10:starwars -m 100:wormhole.movie.edu

9.4.3. An fx.movie.edu Slave

9.4.4. On the movie.edu Primary Master Name Server

Partial contents of file db.movie.edu:

fx    86400    IN    NS    bladerunner.fx.movie.edu.
      86400    IN    NS    outland.fx.movie.edu.

These two records alone aren't enough, though. Do you see the problem? How can a name server outside fx.movie.edu look up information within fx.movie.edu ? Well, a movie.edu name server would refer it to the name servers authoritative for fx.movie.edu, right? That's true, but the NS records in db.movie.edu give only the names of the fx.movie.edu name servers. The foreign name server needs the IP addresses of the fx.movie.edu name servers in order to send queries to them. Who can give it those addresses? Only the fx.movie.edu name servers. A real chicken-and-egg problem!

A BIND 4.9 or later name server automatically ignores any glue you include that isn't strictly necessary and logs the fact that it has ignored the record(s) to syslog on the primary master or in the slave's backup copy of the zone data. For example, if we had an NS record for movie.edu that pointed to an off-site name server, ns-1.isp.net, and we made the mistake of including its address in db.movie.edu on the movie.edu primary master name server, we'd see a message like this in named 's syslog output:

Aug  9 14:23:41 terminator named[19626]: dns_master_load: 
db.movie.edu:55: ignoring out-of-zone data

; Ignoring info about ns-1.isp.net, not in zone movie.edu
; ns-1.isp.net 258983  IN      A       10.1.2.3

Also, remember to keep the glue up to date. If bladerunner gets a new network interface, and hence another IP address, then you should add another A record to the glue data.

We might also want to include aliases for any hosts moving into fx.movie.edu from movie.edu. For example, if we were to move plan9.movie.edu, a server with an important library of public domain special effects algorithms, into fx.movie.edu, we should create an alias in movie.edupointing the old domain name to the new one:

plan9           IN      CNAME   plan9.fx.movie.edu.

You shouldn't put any information about domain names in fx.movie.edu into the db.movie.edu file. The plan9 alias is actually in the movie.edu zone (the owner of the record is plan9.movie.edu), so it belongs in db.movie.edu. An alias pointing p9.fx.movie.edu to plan9.fx.movie.edu, on the other hand, is in the fx.movie.edu zone, and belongs in db.fx.movie.edu. If you were to put a record in the zone data file that was outside the zone the file described, a BIND 4.9 or later name server would ignore it, as shown earlier in the unnecessary glue example. An older name server might load it into cache or even into authoritative data, but since the behavior is unpredictable and is eliminated in newer versions of BIND, it's best to do it the right way even if the software doesn't force you to.

9.4.5. Delegating an in-addr.arpa Zone

9.4.6. Adding a movie.edu Slave

Contents of file named.conf:

options {
	directory "/var/named";
};

zone "0.0.127.in-addr.arpa" {
	type master;
	file "db.127.0.0";
};

zone "fx.movie.edu" {
	type master;
	file "db.fx.movie.edu";
};

zone "254.253.192.in-addr.arpa" {
	type master;
	file "db.192.253.254";
};

zone "movie.edu" {
	type slave;
	masters { 192.249.249.3; };
	file "bak.movie.edu";
};

zone "." {
	type hint;
	file "db.cache";
};