Полезная информация

DNS & BIND

DNS & BINDSearch this book
Previous: 9.3 What to Name Your ChildrenChapter 9
Parenting
Next: 9.5 Subdomains of in-addr.arpa Domains
 

9.4 How to Become a Parent: Creating Subdomains

Once you've decided on names, creating child domains is easy. But first, you've got to decide how much autonomy you're going to give your subdomains. Odd that you have to decide that before you actually create them....

Thus far, we've assumed that if you create a subdomain, you'll want to delegate it to another organization, thereby making it a separate zone from the parent. Is this always true, though? Not necessarily.

Think carefully about how the computers and networks within a subdomain are managed when choosing whether or not to delegate it. It doesn't make sense to delegate a subdomain to an entity that doesn't manage its own hosts or nets. For example, in a large corporation, the personnel department probably doesn't run its own computers: the MIS (Management Information Systems) or IT (Information Technology - same animal as MIS) department manages them. So while you may want to create a subdomain for personnel, delegating management for that subdomain to them is probably wasted effort.

9.4.1 Creating a Subdomain in the Parent's Zone

You can create a subdomain without delegating it, however. How? By creating resource records that refer to the subdomain within the parent's zone. For example, movie.edu has a host that stores its complete database of employee and student records, brazil. To put brazil in the personnel.movie.edu domain, we could add records to db.movie.

Partial contents of file db.movie:

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.

Now users can log into db.personnel.movie.edu to get to the employee database. We could make this setup especially convenient for personnel department employees by adding personnel.movie.edu to their PCs' or workstations' search lists; they'd only need to type telnet db to get to the right host.

We can make this more convenient for ourselves by using the $ORIGIN directive to change the origin to personnel.movie.edu so that we can use shorter names.

Partial contents of file db.movie:

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

If we had a few more records, we could create a separate file for them and use $INCLUDE to include it into db.movie and change the origin at the same time.

Notice there's no SOA record for personnel.movie.edu? There's no need for one, since the movie.edu SOA 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

If you decide to delegate your subdomains, to send your children out into the world, as it were, you'll need to do things a little differently. We're in the process of doing it now, so you can follow along with us.

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 domain for redundancy - a single fx.movie.edu name 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 subnet.

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

First, we create a data file that includes records for all the hosts that will live in fx.movie.edu.

Contents of file db.fx:

@  IN  SOA  bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. (
            1       ; serial
            10800   ; refresh every 3 hours
            3600    ; retry every hour
            604800  ; expire after a week
            86400 ) ; minimum TTL of 1 day

    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.

Then we create the db.192.253.254 file:

@  IN  SOA  bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. (
            1       ; serial
            10800   ; refresh every 3 hours
            3600    ; retry every hour
            604800  ; expire after a week
            86400 ) ; minimum TTL of 1 day

       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.

Notice that the PTR record for 1.254.253.192.in-addr.arpa points to movie-gw.movie.edu. That's intentional. The router connects to the other movie.edu networks, so it really doesn't belong in the fx.movie.edu domain, and there's no requirement that all the PTR records in 254.253.192.in-addr.arpa map into a single domain - though they should correspond to the canonical names for those hosts.

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

options {
                directory "/usr/local/named";
};

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

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

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

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

Here are the contents of the corresponding named.boot file for BIND 4:

directory     /usr/local/named

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

cache         .                         db.cache

Of course, if we'd used h2n, we could have just run:

% 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

and saved ourselves some typing. h2n would have created essentially the same db.fx, db.192.253.254, and named.boot files.

Now we need to configure bladerunner's resolver. Actually, this may not require creating resolv.conf. If we set bladerunner's hostname to its new domain name, bladerunner.fx.movie.edu, the resolver can derive the local domain from the fully qualified domain name.

Next we start up the named process on bladerunner and check for syslog errors. If named starts okay, and there are no syslog errors that need tending to, we'll use nslookup to look up a few hosts in fx.movie.edu and in 254.253.192.in-addr.arpa:

Default Server:  bladerunner.fx.movie.edu
Address:  192.253.254.2

> jedi
Server:  bladerunner.fx.movie.edu
Address:  192.253.254.2
Name:    jedi.fx.movie.edu
Address:  192.253.253.6

> set type=mx
> empire
Server:  bladerunner.fx.movie.edu
Address:  192.253.254.2

empire.fx.movie.edu     preference = 10,
                        mail exchanger = starwars.fx.movie.edu
empire.fx.movie.edu     preference = 100,
                        mail exchanger = wormhole.movie.edu
starwars.fx.movie.edu   internet address = 192.253.254.4
 > ls fx.movie.edu
[bladerunner.fx.movie.edu]
            1D IN SOA    bladerunner.fx.movie.edu.
hostmaster.fx.movie.edu. (
                    1               ; serial
                    3H              ; refresh
                    1H              ; retry
                    1w1h            ; expire
                    1D )            ; minimum

            1D IN NS     bladerunner.fx.movie.edu.
            1D IN NS     outland.fx.movie.edu.
            1D IN MX     10 starwars.fx.movie.edu.
            1D IN MX     100 wormhole.movie.edu.
br.fx.movie.edu.       1D IN CNAME bladerunner.fx.movie.edu.
jedi.fx.movie.edu.     1D IN A     192.253.254.6
            1D IN MX     10 starwars.fx.movie.edu.
            1D IN MX     100 wormhole.movie.edu.
outland.fx.movie.edu.  1D IN A     192.253.254.3
            1D IN MX     10 starwars.fx.movie.edu.
            1D IN MX     100 wormhole.movie.edu.
starwars.fx.movie.edu. 1D IN A     192.253.254.4
            1D IN MX     10 starwars.fx.movie.edu.
            1D IN MX     100 wormhole.movie.edu.
bladerunner.fx.movie.edu.  1D IN A  192.253.254.2
            1D IN MX     10 starwars.fx.movie.edu.
            1D IN MX     100 wormhole.movie.edu.
empire.fx.movie.edu.     1D IN A     192.253.254.5
            1D IN MX     10 starwars.fx.movie.edu.
            1D IN MX     100 wormhole.movie.edu.
fx.movie.edu.       1D IN SOA    bladerunner.fx.movie.edu.
hostmaster.fx.movie.edu. (
                    1               ; serial
                    3H              ; refresh
                    1H              ; retry
                    1w1h            ; expire
                    1D )            ; minimum

 > set type=ptr
 > 192.253.254.3
Server:  bladerunner.fx.movie.edu
Address:  192.253.254.2

3.254.253.192.in-addr.arpa      name = outland.fx.movie.edu

> ls 254.253.192.in-addr.arpa.
[bladerunner.fx.movie.edu]
            1D IN SOA   bladerunner.fx.movie.edu.
hostmaster.fx.movie.edu. (
                    1               ; serial
                    3H              ; refresh
                    1H              ; retry
                    1w1h            ; expire
                    1D )            ; minimum

            1D IN NS    bladerunner.fx.movie.edu.
            1D IN NS    outland.fx.movie.edu.
6.254.253.192.in-addr.arpa.  1D IN PTR  jedi.fx.movie.edu.
1.254.253.192.in-addr.arpa.  1D IN PTR  movie-gw.movie.edu.
2.254.253.192.in-addr.arpa.  1D IN PTR  bladerunner.fx.movie.edu.
3.254.253.192.in-addr.arpa.  1D IN PTR  outland.fx.movie.edu.
4.254.253.192.in-addr.arpa.  1D IN PTR  starwars.fx.movie.edu.
5.254.253.192.in-addr.arpa.  1D IN PTR  empire.fx.movie.edu.
254.253.192.in-addr.arpa.  1D IN SOA  bladerunner.fx.movie.edu.
hostmaster.fx.movie.edu. (
                    1               ; serial
                    3H              ; refresh
                    1H              ; retry
                    1w1h            ; expire
                    1D )            ; minimum

 > ^D

The output looks reasonable, so it's safe to set up a slave name server for fx.movie.edu and to delegate fx.movie.edu from movie.edu.

9.4.3 An fx.movie.edu Slave

Setting up the slave name server for fx.movie.edu is simple: copy named.conf, db.127.0.0, and db.cache over from bladerunner, and edit named.conf and db.127.0.0 according to the instructions in Chapter 4, Setting Up BIND.

Contents of file named.conf:

options {
                directory "/usr/local/named";
};

zone "0.0.127.in-addr.arpa" {
                type slave;
                file "db.127.0.0";
                masters { 192.253.254.2; };
};

zone "fx.movie.edu" {
                type slave;
                file "db.fx";
                masters { 192.253.254.2; };
};

zone "254.253.192.in-addr.arpa" {
                type slave;
                file "db.192.253.254";
                masters { 192.253.254.2; };
};

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

Or, the equivalent named.boot file:

directory  /usr/local/named

primary    0.0.127.in-addr.arpa      db.127.0.0
secondary  fx.movie.edu              192.253.254.2  db.fx
secondary  254.253.192.in-addr.arpa  192.253.254.2  db.192.253.254

cache      .                         db.cache

Like bladerunner, outland really doesn't need a resolv.conf file, as long as its hostname is set to outland.fx.movie.edu.

Again, we start named and check for errors in the syslog output. If the syslog output is clean, we'll look up a few records in fx.movie.edu.

9.4.4 On the movie.edu Primary Master

All that's left now is to delegate the fx.movie.edu domain to the new fx.movie.edu name servers on bladerunner and outland. We add the appropriate NS records to db.movie.

Partial contents of file db.movie:

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

According to RFC 1034, the domain names in the resource record-specific portion of these two lines (bladerunner.fx.movie.edu and outland.fx.movie.edu) must be the canonical domain names for the name servers. A remote name server following delegation expects to find one or more address records attached to that domain name, not an alias (CNAME) record. Actually, the RFC extends this restriction to any type of resource record that includes a domain name as its value - all must specify the canonical domain name.

These two records alone aren't enough, though. Do you see the problem? How can a name server outside of 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 only give 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!

The solution is to include the addresses of the fx.movie.edu name servers in the db.movie file. While these aren't strictly part of the movie.edu zone, they're necessary for delegation to fx.movie.edu to work. Of course, if the name servers for fx.movie.edu weren't within fx.movie.edu, these addresses - called glue records - wouldn't be necessary. A foreign name server would be able to find the address it needed by querying other name servers.

So, with the glue records, the records added look like the following partial contents of file db.movie:

fx    86400    IN    NS    bladerunner.fx.movie.edu.
      86400    IN    NS    outland.fx.movie.edu.
bladerunner.fx.movie.edu.  86400  IN  A  192.253.254.2
outland.fx.movie.edu.      86400  IN  A  192.253.254.3

Be sure you don't include unnecessary glue records in the file. Older BIND name servers (pre-4.9) load these records into their cache and give them out in referrals to other name servers. If the name server listed in the address record changes IP addresses and you forget to update the glue, your name server will continue giving out the outdated address information, resulting in poor resolution performance for name servers looking for data in the delegated zone, or even rendering them unable to resolve names in the delegated zone.

BIND 4.9 and BIND 8 will automatically ignore any glue you include that isn't strictly necessary, and will log the fact that it's ignored the record(s) to the slave's backup copy of the zone data. For example, if we had an NS record for movie.edu pointing to an off-site name server, ns-1.isp.net, and we made the mistake of including its address in db.movie on the movie.edu primary, we'd see:

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

in db.movie on a movie.edu slave. Note that the extraneous A record has been commented out.

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 under movie.edu pointing the old name to the new one:

plan9           IN      CNAME   plan9.fx.movie.edu.

This will allow people outside of movie.edu to reach plan9 even though they're using its old domain name, plan9.movie.edu.

You shouldn't put any information about domain names in fx.movie.edu into the db.movie file. The plan9 alias is actually in the movie.edu zone, so it belongs in db.movie. 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. If you were to put a record in the db file that was outside of the zone the file described, a BIND 4.9 name server would ignore it. Older name servers might load it into the 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

We almost forgot to delegate the 254.253.192.in-addr.arpa zone! This is a little trickier than delegating fx.movie.edu, because we don't manage the parent zone.

First, we need to figure out what 254.253.192.in-addr.arpa's parent zone is, and who runs it. To figure this out may take some sleuthing; we covered how to do this in Chapter 3, Where Do I Start?.

As it turns out, the in-addr.arpa zone is 254.253.192.in-addr.arpa's parent. And, if you think about it, that makes some sense. There's no reason for the administrators of in-addr.arpa to delegate 253.192.in-addr.arpa or 192.in-addr.arpa to a separate authority, because unless 192.0.0.0 or 192.253.0.0 is all one big CIDR block, networks like 192.253.253 and 192.253.254 don't have anything in common with each other. They may be managed by totally unrelated organizations.

You might have remembered (from Chapter 3) that the in-addr.arpa zone is managed by ARIN, the American Registry of Internet Numbers. (Of course, if you didn't remember, you could always use nslookup to find the contact address in in-addr.arpa's SOA record, like we showed you in Chapter 3.) All that's left is for us to fill out inaddrtemplate.txt (there's a copy in Appendix E, in-addr.arpa Registration Form, or you can find it online at http://www.arin.net/templates/inaddrtemplate.txt), and send it to the email address .

9.4.6 Adding a movie.edu Slave

If the special effects lab gets big enough, it may make sense to put a movie.edu slave somewhere on the 192.253.254 network. That way, a larger proportion of DNS queries from fx.movie.edu hosts can be answered locally. It seems logical to make one of the existing fx.movie.edu name servers into a movie.edu slave, too - that way, we can make better use of an existing name server, instead of setting up a brand-new name server.

We've decided to make bladerunner a slave for movie.edu. This won't interfere with bladerunner's primary mission: the primary master for fx.movie.edu, that is. A single name server, given enough memory, can be authoritative for literally thousands of zones. One name server can load some zones as a primary master and others as a slave.[2]

[2] Clearly, though, a name server can't be both the primary master and a slave for a single zone. Either the name server gets the data for a given zone from a local file (and is a primary master for the zone) or from another name server (and is a slave for the zone).

The configuration change is simple: we add one line to bladerunner's named.conf file to tell named to load the movie.edu zone from the IP address of the movie.edu primary master name server, terminator.movie.edu.

Contents of file named.conf:

options {
                directory "/usr/local/named";
};

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

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

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

zone "movie.edu" {
                type slave;
                file "db.movie";
};

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

Or, if you're using a BIND 4 name server, here are the contents of the named.boot file:

directory     /usr/local/named

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

cache         .                         db.cache


Previous: 9.3 What to Name Your ChildrenDNS & BINDNext: 9.5 Subdomains of in-addr.arpa Domains
9.3 What to Name Your ChildrenBook Index9.5 Subdomains of in-addr.arpa Domains