9.4 How to Become a Parent: Creating Subdomains
9.4 How to Become a Parent: Creating Subdomains Once 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: the MIS (Management Information Systems) or IT (Information Technologysame 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 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 there's an easier way: just 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 the window shown in Figure 9-1. Figure 9-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 9-2. Figure 9-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. 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. 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. 9.4.2 Creating and Delegating a SubdomainIf you decide to delegate your subdomainsto send your children out into the world, as it wereyou'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 redundancya 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 Section 4.3.2 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 data file we end up with, called fx.movie.edu.dns , looks like this: ; ; Data file fx.movie.edu.dns for fx.movie.edu zone. ; Zone version: 27 ; @ IN SOA bladerunner.fx.movie.edu. administrator.fx.movie.edu. ( 27 ; serial number 900 ; refresh 600 ; retry 86400 ; expire 3600 ) ; minimum TTL ; ; Zone NS records ; @ NS bladerunner.fx.movie.edu. @ NS outland.fx.movie.edu. ; ; Zone records ; @ MX 10 starwars. @ MX 100 wormhole.movie.edu. bladerunner A 192.253.254.2 MX 10 starwars. MX 100 wormhole.movie.edu. br CNAME bladerunner.fx.movie.edu. empire A 192.253.254.5 MX 10 starwars. MX 100 wormhole.movie.edu. jedi A 192.253.254.6 MX 10 starwars. MX 100 wormhole.movie.edu. outland A 192.253.254.3 MX 10 starwars. MX 100 wormhole.movie.edu. starwars A 192.253.254.4 MX 10 starwars. MX 100 wormhole.movie.edu. The 254.253.192.in-addr.arpa.dns file ends up looking like this: ; ; Data file 254.253.192.in-addr.arpa.dns for 254.253.192.in-addr.arpa zone. ; Zone version: 11 ; @ IN SOA terminator.movie.edu. administrator.movie.edu. ( 11 ; serial number 900 ; refresh 600 ; retry 86400 ; expire 3600 ) ; minimum TTL ; ; Zone NS records ; @ NS terminator.movie.edu. ; ; 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 ownIP 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 empire.fx.movie.edu MX preference = 100, mail exchanger = wormhole.movie.edu > 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 = terminator.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 slave name server for fx.movie.edu and then delegate fx.movie.edu from movie.edu . 9.4.2.1 An fx.movie.edu slaveSetting up the slave name server for fx.movie.edu is simple: use the DNS console to add outland as a new server, then add two slave (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 domainto be fx.movie.edu. 9.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 . The whole delegation process is much improved in Windows 2000's DNS console. 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 9-3. The first step is entering the name of the delegated subdomain, which we've done. Figure 9-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 9-4. Figure 9-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 9-5. Figure 9-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 valueall 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.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 . While 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 addressescalled 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, thoughthe 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 9-5, double-click on an NS record in the right pane to produce a window like the one shown in Figure 9-6. Figure 9-6. Name server modification window If fx.movie.edu 's delegation changesi.e., a name server gets added or deleted or a name server's IP address changesuse 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 data file, 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 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 . 9.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 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 in-addr.arpa to delegate 253.192.in-addr.arpa or 192.in-addr.arpa to a separate authority because, unless 192/8 or 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. You might remember (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 use the web-based "ARIN Modify Tool" at http://www.arin.net/cgi-bin/amt.pl to request registration of our reverse-mapping zone. 9.4.2.4 Adding a movie.edu slaveIf the special-effects lab gets big enough, it may make sense to put a movie.edu slave 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 slave, toothat 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 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 slave. [1]
The configuration change is simple: we use the DNS console to add a slave (secondary) zone to bladerunner and tell bladerunner to get the movie.edu zone data from terminator 'sIP address, per the instructions in Chapter 4 .  |
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 154