| [ Team LiB ] |
|
10.4 How to Become a Parent: Creating SubdomainsOnce you've decided on names, creating the 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 networks. For example, in a large corporation, the personnel department probably doesn't run its own computers: IT (Information Technology) 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. 10.4.1 Creating a Subdomain in the Parent's ZoneYou can create a subdomain without delegating it, however. How? By creating resource records that refer to the subdomain within the parent's zone. Say one day a group of students approaches us, asking for a DNS entry for a web server for student home pages. The name they'd like is www.students.movie.edu. You might think that we'd need to create a new zone, students.movie.edu, and delegate to it from the movie.edu zone. Well, that's one way to do it, but it's easier to create an A record for www.students.movie.edu in the movie.edu zone. We find that few people realize this is perfectly legal. You don't need a new zone for each new level in the namespace. A new zone would make sense if the students were going to run students.movie.edu by themselves and wanted to administer their own name servers. But they just want one A record, so creating a whole new zone is more work than necessary. It's easy to add this record with the DNS console. First create a students.movie.edu subdomain in the movie.edu zone, then add the www.students.movie.edu A record. To create the subdomain, right-click on the zone in the left pane and select New Domain. You'll see a window like the one shown in Figure 10-1. Figure 10-1. Creating a subdomain in a zone Enter the name of the new subdomain. You don't need to append movie.edu—the DNS console knows what you mean. You'll then see a folder icon for the new domain in the DNS console, as shown in Figure 10-2. Figure 10-2. The students.movie.edu subdomain in the movie.edu zone To enter the www.students.movie.edu A record, just select the students folder and follow the procedures described previously to add a new host. In fact, you can even skip the Add Domain step and use the Add Host (A) function to add the host's address record and implicitly create the students.movie.edu subdomain (if it hasn't already been created). Just specify www.students in the Name field and voila! You've created an address for www.students.movie.edu. Now users can access www.students.movie.edu to get to the students' home pages. We could make this setup especially convenient for students by adding students.movie.edu to their PCs' or workstations' search lists; they'd need to type only www as the URL to get to the right host. Did you notice there's no SOA record for students.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 students.movie.edu, it's part of the movie.edu zone. 10.4.2 Creating and Delegating a SubdomainIf 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 zone 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, two name servers should be enough. The special-effects lab is on movie.edu's new 192.253.254/24 network. Here are the partial contents of 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 make sure the Microsoft DNS Server is installed on the new server, bladerunner. Then we create the new zone fx.movie.edu on bladerunner using the process described in the section "Creating a New Zone" in Chapter 4. We also create the corresponding in-addr.arpa zone, 254.253.192.in-addr.arpa. Next, we populate the zone with all the hosts from our snippet of HOSTS, making sure the DNS console automatically adds the PTR records that correspond to our A records. We then add MX records for all of our hosts, pointing to starwars.fx.movie.edu and wormhole.movie.edu, at preferences 10 and 100, respectively. The zone datafile we end up with, called fx.movie.edu.dns, looks like this: ;
; Database file fx.movie.edu.dns for fx.movie.edu zone.
; Zone version: 22
;
@ IN SOA bladerunner.fx.movie.edu.
administrator.fx.movie.edu. (
22 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; default TTL
;
; Zone NS records
;
@ NS bladerunner.fx.movie.edu.
@ NS outland.fx.movie.edu.
;
; Zone records
;
@ MX 100 wormhole.movie.edu.
@ MX 10 starwars.fx.movie.edu.
bladerunner A 192.253.254.2
MX 100 wormhole.movie.edu.
MX 10 starwars.fx.movie.edu.
empire A 192.253.254.5
MX 100 wormhole.movie.edu.
MX 10 starwars.fx.movie.edu.
jedi A 192.253.254.6
MX 10 starwars.fx.movie.edu.
MX 100 wormhole.movie.edu.
outland A 192.253.254.3
MX 100 starwars.fx.movie.edu.
MX 10 starwars.fx.movie.edu.
starwars A 192.253.254.4
MX 100 wormhole.movie.edu.
MX 10 starwars.fx.movie.edu.
Note that we added an NS record for outland.fx.movie.edu even though we didn't strictly need to: the DNS console would have added it for us when we added outland as a secondary. But adding the NS record lets us restrict zone transfers to name servers listed in NS records and still set up the secondary on outland. We'll do this for the reverse-mapping zone, too. The 254.253.192.in-addr.arpa.dns file ends up looking like this: ;
; Database file 254.253.192.in-addr.arpa.dns for 254.253.192.in-addr.arpa zone.
; Zone version: 14
;
@ IN SOA bladerunner.fx.movie.edu.
administrator.fx.movie.edu. (
14 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; default TTL
;
; Zone NS records
;
@ NS bladerunner.fx.movie.edu.
bladerunner.fx.movie.edu. A 192.253.254.2
@ NS outland.fx.movie.edu.
outland.fx.movie.edu. A 192.253.254.3
;
; Zone records
;
1 PTR movie-gw.movie.edu.
2 PTR bladerunner.fx.movie.edu.
3 PTR outland.fx.movie.edu.
4 PTR starwars.fx.movie.edu.
5 PTR empire.fx.movie.edu.
6 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 fx.movie.edu. There's no requirement that all the PTR records in 254.253.192.in-addr.arpa map into a single zone, although they should correspond to the canonical names for those hosts. Now we need to configure bladerunner's resolver. Following the directions in Chapter 6, we configure bladerunner to send queries to its own IP address. Then we set bladerunner's domain to fx.movie.edu. Now we'll use nslookup to look up a few hosts in fx.movie.edu and in 254.253.192.in-addr.arpa: C:\> nslookup 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.254.6 > set type=mx > empire Server: bladerunner.fx.movie.edu Address: 192.253.254.2 empire.fx.movie.edu MX preference = 10, mail exchanger = starwars.fx.movie.edu empire.fx.movie.edu MX 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] fx.movie.edu. NS server = bladerunner.fx.movie.edu fx.movie.edu. NS server = outland.fx.movie.edu bladerunner A 192.253.254.2 empire A 192.253.254.5 jedi A 192.253.254.6 outland A 192.253.254.3 starwars A 192.253.254.4 > 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] 254.253.192.in-addr.arpa. NS server = bladerunner.fx.movie.edu 254.253.192.in-addr.arpa. NS server = outland.fx.movie.edu 1 PTR host = movie-gw.movie.edu 2 PTR host = bladerunner.fx.movie.edu 3 PTR host = outland.fx.movie.edu 4 PTR host = starwars.fx.movie.edu 5 PTR host = empire.fx.movie.edu 6 PTR host = jedi.fx.movie.edu > exit The output looks reasonable, so it's safe to set up a secondary name server for fx.movie.edu and then delegate fx.movie.edu from movie.edu. 10.4.2.1 An fx.movie.edu secondarySetting up the secondary name server for fx.movie.edu is simple: use the DNS console to add outland as a new server, then add two secondary zones, according to the instructions in Chapter 4. Like bladerunner, outland's resolver will point to the local name server, and we'll configure the local domain to be fx.movie.edu. 10.4.2.2 On the movie.edu primary master name serverAll that's left now is to delegate the fx.movie.edu subdomain to the new fx.movie.edu name servers on bladerunner and outland. Right-click on the parent domain, movie.edu, in the left pane and choose New Delegation, which starts the New Delegation Wizard. Click Next in the welcome screen to display a screen like the one shown in Figure 10-3. The first step is entering the name of the delegated subdomain, which we've done. Figure 10-3. Entering the name of the delegated subdomain Click Next and you'll be presented with a window to choose the name servers to host (i.e., be authoritative for) the delegated zone. Our two servers are bladerunner.fx.movie.edu and outland.fx.movie.edu, so we enter the appropriate information by clicking Add (we have to run through the add process twice, once for each name server), resulting in a window like Figure 10-4. Figure 10-4. Choosing name servers for the delegated zone The final window of the wizard is just for confirmation, so we won't bother to show it. Click Finish and you've delegated a zone. The DNS console adds a special gray icon for delegated zones; if you select this icon, you'll see the NS records added by the wizard. These records perform the actual delegation. A sample DNS console view showing the fx.movie.edu delegation appears in Figure 10-5. Figure 10-5. The DNS console showing a delegated zone According to RFC 1034, the domain names in the resource record-specific portion (the "right side") of the bladerunner.fx.movie.edu and outland.fx.movie.edu NS records 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 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! The solution is to include the addresses of the fx.movie.edu name servers in movie.edu. Although these aren't strictly part of the movie.edu zone, delegation to fx.movie.edu won't work without them. 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. We don't have to worry about adding these records, though—the New Delegation Wizard takes care of it for us. Also, remember to keep the glue up-to-date. If bladerunner gets a new network interface, and hence another IP address, you'll need to update the glue data. The DNS console doesn't let you edit the glue records directly, though. You have use the name server modification window. With the DNS console showing a view like Figure 10-5, double-click on an NS record in the right pane to produce a window like the one shown in Figure 10-6. Figure 10-6. Name server modification window If fx.movie.edu's delegation changes—i.e., a name server gets added or deleted or a name server's IP address changes—use the Add, Edit, or Remove buttons to make the appropriate changes. We might also want to include aliases for any hosts moving into fx.movie.edu from movie.edu. For example, if we 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 domain name to the new one. In the zone datafile, the record would look like this: 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. Don't get confused about the zone in which this alias belongs. The plan9 alias record is actually in the movie.edu zone, so it belongs in the file movie.edu.dns. 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 fx.movie.edu.dns. 10.4.2.3 Delegating an in-addr.arpa zoneWe 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. Figuring this out may take some sleuthing; we covered how to do this in Chapter 3. As it turns out, the 192.in-addr.arpa zone is 254.253.192.in-addr.arpa's parent. And, if you think about it, that makes sense. There's no reason for the administrators of 192.in-addr.arpa to delegate 253.192.in-addr.arpa to a separate authority because, unless 192.253/16 is all one big CIDR block, networks like 192.253.253/24 and 192.253.254/24 don't have anything in common with each other. They may be managed by totally unrelated organizations. To find out who runs 192.in-addr.arpa, we can use nslookup or whois, as we demonstrated in Chapter 3. Here's how we'd use nslookup to find the administrator: C:\> nslookup
Default Server: bladerunner.fx.movie.edu
Address: 192.253.254.2
> set type=soa
> set norecurse
> 253.192.in-addr.arpa.
Server: bladerunner.fx.movie.edu
Address: 192.253.254.2
192.in-addr.arpa
primary name server = arrowroot.arin.net
responsible mail addr = bind.arin.net
serial = 2003070219
refresh = 1800 (30 mins)
retry = 900 (15 mins)
expire = 691200 (8 days)
default TTL = 10800 (3 hours)
>
So ARIN is responsible for 192.in-addr.arpa. (Remember them from Chapter 3?) All that's left is for us to submit the form at http://www.arin.net/library/templates/net-end-user.txt to request registration of our reverse-mapping zone. 10.4.2.4 Adding a movie.edu secondaryIf the special-effects lab gets big enough, it may make sense to put a movie.edu secondary somewhere on the 192.253.254/24 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 secondary, 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 secondary for movie.edu. This won't interfere with bladerunner's primary mission as the primary master name server for fx.movie.edu. 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 secondary.[1]
The configuration change is simple: we use the DNS console to add a secondary zone to bladerunner and tell bladerunner to get the movie.edu zone data from terminator's IP address, per the instructions in Chapter 4.  |
| [ Team LiB ] |
|