4.3 Setting Up DNS Data | DNS on Windows 2000


Team-Fly

	DNS on Windows 2000, 2nd Edition By Matt Larson, Cricket Liu
	Table of Contents

	Chapter 4. Setting Up the Microsoft DNS Server

4.3 Setting Up DNS Data

Let's configure the first of Movie U.'s name servers. We'll use the DNS console for most of this process, so start it up if you haven't already done so. You don't have to run the DNS console on the machine running the name server, but for now it's easier if you do. You'll also need to have Administrator privileges to use the DNS console; otherwise , you'll only be able to start the application, not manage any name servers with it.

4.3.1 Adding a New Server to the DNS Console

The first step is configuring the DNS console to manage the primary master name server for your zone. The primary master for a zonealso called just the primary stores information about the zone on its disk. You make all changes to your zone on the primary master.

Select Action Connect To Computer... and specify where the name server you want managethe primary masteris running, either on the local machine or somewhere else. If the name server isn't local, enter its name or IP address. The DNS console adds an icon in the left pane for that name server, as in Figure 4-5.

Figure 4-5. The DNS console with a new server

It's important to understand what we just did here. We told the DNS console about a name server for it to manage and it added that name server to its configuration. The DNS console did not start the name server on the target machine. If the name server isn't already installed and running, the DNS console can't manage it and will complain with the message, "The server is unavailable. Would you like to add it anyway?"

Selecting Connect To Computer adds that name server to the list of servers the DNS console knows about. As you might expect, selecting the server and choosing Action Delete (or just pressing the Delete key) removes the server from the DNS console's configuration but doesn't change anything on the name server itself. The server will still be runningyou can use Connect To Computer... to add it, and you'll be right back where you started.

4.3.2 Creating a New Zone

Now it's time to create the movie.edu zone. Select the name server on the left where you want to create the zone. (There's only one server now, terminator , but the DNS console could know about multiple servers.) Choose Action New Zone . You'll see the New Zone Wizard, as in Figure 4-6.

Figure 4-6. New Zone Wizard, first window

To continue, click Next . In the next window (Figure 4-7), you have three choices for the type of zone: Active Directory integrated , Standard primary and Standard secondary . For now, choose Standard primary and click Next . We'll talk more about Active Directory integration of zones in Chapter 11.

Figure 4-7. New Zone Wizard, second window

Now you need to choose the whether this is a forward- or reverse-mapping zone, as shown in Figure 4-8. movie.edu is, of course, a forward-mapping zone, so make that selection and click Next .

Figure 4-8. New Zone Wizard, third window

Getting tired of all these windows yet? In the next one, shown in Figure 4-9, type the domain name of the zone, which is movie.edu . Click Next .

Figure 4-9. New Zone Wizard, fourth window

Now you need to specify the file that will hold all the zone information, as shown in Figure 4-10.

Figure 4-10. New Zone Wizard, fifth window

The zone file, also called a zone data file , is the zone's permanent storage location. It's the file on the name server's disk where all the information about the zone is stored: it contains all the zone's resource records. Other name servers require you to edit the zone data file to make changes to the zone, but the DNS console allows you to avoid any hand-editing. As a result, you probably won't see the zone data files very much. We'll talk about their format later in this chapter.

Even if you won't be looking at it often, you need to specify a zone data filename when you create a zone. The server expects these files to be in %SystemRoot%\System32\DNS . Microsoft's suggested naming convention uses the domain name of the zone followed by the .dns extension. (Notice that the DNS console has filled in the filename based on the zone name.) You can name the zone file whatever you want, but as long as the DNS console fills in the field for you, we recommend sticking with its suggestion. You may be familiar with other naming conventions, such as db. followed by the zone's domain name (e.g., db.movie.edu ). In fact, that's the recommendation in our sister book, DNS and BIND .

When you've entered a filename (or left the automatically chosen name alone), click Next , and you'll see the confirmation window shown in Figure 4-11.

Figure 4-11. New Zone Wizard confirmation window

Click Finish to create the zone. If we double-click on terminator in the left pane, then double-click on Forward Lookup Zones and select the movie.edu zone, we see a window like the one pictured in Figure 4-12. The DNS console has created the zone and a few resource records. Let's talk about them one by one.

Figure 4-12. The DNS console with a new zone

4.3.2.1 The SOA record

The first record displayed is the start of authority, or SOA, ^[1] resource record for the movie.edu zone. It's a little tricky to see that the name of this record is really movie.edu , since the DNS console displays (same as parent folder) in the Name column. You need to look at the domain name selected in the left pane to know the domain name of this resource record.

^[1] Here's where a difference between normal (i.e., nonadvanced) and advanced mode comes in. Figure 4-12 shows the record type as Start of Authority because the DNS console is in basic mode. In advanced mode, the record type would show up as simply SOA .

The SOA record indicates that this name server is the best source of information for the data within this zone. Our name server is authoritative for the movie.edu zone because of the SOA record. An SOA record is required in each zone, and there can be one, and only one, SOA record in a zone.

Double-click the SOA record to view its details. You'll see a window like the one in Figure 4-13.

Figure 4-13. The movie.edu SOA record

Let's skip that first field, Serial number , for nowdon't worry, we'll cover it later in the chapterand go on to the next field. The second field is the name of the primary master name server for this zone. (You may hear it called the MNAME field, which is its official name.) The third field contains the email address of the person in charge of the zone (if you replace the first dot with an at sign, @). The DNS console defaults to a username of administrator , but in other zones you'll often see root , postmaster , or hostmaster as the email address. Name servers won't use these names they are meant for human consumption. If you notice a problem in someone's zone, you can send an email message to the listed email address.

Most of the remaining fields are for use by slave name servers and are discussed when we introduce slave name servers later in this chapter. For now, assume these are reasonable values.

4.3.2.2 The NS record

The next record is an NS (name server) resource record. There should be one NS record for each name server authoritative for the zone. Like the SOA record, NS records are attached to the zone's domain name. In our example, the NS records are attached to movie.edu . Right now there's only one name server (the primary master), but as we configure slave name servers, we'll add NS records. The DNS console created an NS record for terminator because it's a name serverthe primary master name serverfor movie.edu .

4.3.2.3 The missing A record

Unfortunately, we're missing a required record: the address (A) record for terminator.movie.edu , the host running the name server. Address records fulfill the main purpose of DNS: they provide name-to-address mapping. Each A record maps a domain name, like terminator.movie.edu , to an IP address, like 192.249.249.3.

Every NS record needs a corresponding A record in some zone. Think about it: an NS record says, "To find out information about this zone, go to this name server." To use the NS record, you need the IP address of the name server it specifies. In this case, the name of the name server, terminator.movie.edu , is contained in the movie.edu zone we just created, so we need an A record for terminator.movie.edu in our zone that will specify its IP address. We're bringing this up now because those of you familiar with Windows NT 4.0 might remember that DNS Manager (the former incarnation of the DNS console) would have automatically created an A record for terminator.movie.edu when the movie.edu zone was created.We will have to manually add this A record, but not just yet: it's best to create the reverse-mapping ( in-addr.arpa ) zones first.

4.3.3 Creating a New Reverse-Mapping Zone

Zones like movie.edu handle mapping names to addresses using A records. But mapping addresses back to namesreverse mappingis just as important. As you may recall from Chapter 2, a special portion of the namespace, the in-addr.arpa domain, is designated for reverse mapping. There's one domain name in in-addr.arpa for every possible IP address, and PTR (pointer) records attached to a domain name provide the actual reverse mapping. Just think of a PTR record as the opposite of an A record.

So after we create movie.edu , we're not done. Movie U. has two /24 networks, 192.249.249/24 and 192.253.253/24. We need to create the corresponding in-addr.arpa zones for reverse mapping with the DNS console: 249.249.192.in-addr.arpa and 253.253.192.in-addr.arpa .

The process for creating an in-addr.arpa zone is the same as that for creating any other zone. Select terminator in the left pane and choose Action New Zone... . Follow the prompts in the New Zone Wizard as we did earlier, except this time choose Reverse lookup zone in the third window. Figure 4-14 shows the fourth window of the New Zone Wizard when creating a reverse-mapping zone.

Figure 4-14. Specifying the network number or name of a reverse-mapping zone

We specified the network number (see the selected field), and the DNS console automatically calculated the zone name (see the grayed-out field). Click Next and the wizard concludes as shown earlier.

Select the newly created zone in the left pane to see its contents in the right pane. Note that, just as it did with the movie.edu zone, the DNS console automatically creates the SOA record and an NS record.

For Movie U., we'll repeat this process to create the 253.253.192.in-addr.arpa zone. You will create in-addr.arpa zones according to the networks you have. Usually there's one in-addr.arpa zone per /24 (or smaller) network. Larger networks are often broken into several in-addr.arpa zones to make management easier. The zones usually correspond to subnets. This topic is covered in more detail in Chapter 9.

4.3.4 Adding Resource Records

Now that we've created Movie U.'s zones, we can add information about all its machines. Each machine requires two resource records: an A record in the movie.edu zone to provide name-to-address mapping and a PTR record in the appropriate in-addr.arpa zone to provide address-to-name mapping. Adding the A record is intuitive, but it's easy to forget about the PTR record. The DNS console makes the job easier with the New Host command, which creates an A record and a PTR record in one pass.

Select a forward-mapping zone (like movie.edu ) and choose Action New Host... . Enter the name of the host and its IP address. To create the PTR record as well, you also need to check the Create associated pointer (PTR) record box. The window looks like the one in Figure 4-15.

Figure 4-15. The New Host window

You'll notice that we typed a relative domain name ( terminator ) and not a fully qualified domain name ( terminator.movie.edu .) The DNS console requires a relative domain name in this field. (It won't even let you type a period!) It appends the domain name of the zone selected in the DNS console's left pane (and shown in the Location field in the window) to create a fully qualified domain name.

4.3.4.1 Aliases

Looking back at Movie U.'s host table in the beginning of the chapter, you'll see that some hosts have aliases. (The aliases are any additional names after the first one listed.) For example, terminator is also known as bigt . A special resource record called the CNAME record is used to make an alias. The name of this record is confusing because CNAME is short for canonical name, which means the "real" name of the host. But a CNAME record doesn't make a canonical name; it makes an alias. All other types of records make a canonical name. We recommend thinking of it this way: CNAME records point to canonical names while other record types make canonical names.

To create an alias, select the zone to which you want to add the record on the left, and choose Action New Alias... . You'll see a window that looks like the one in Figure 4-16.

Figure 4-16. Creating a CNAME record

The input in Figure 4-16 will generate an alias from bigt.movie.edu to terminator.movie.edu . The Parent domain field is just a reminder of the current domain. As was the case with the New Host command, you must enter a single-label (that is, no periods) name in the Alias name field: the Alias name field is always relative to the current domain. There is no such restriction for the canonical name field (labeled Fully qualified name for target host )you can point this alias anywhere . We could alias bigt.movie.edu to www.whitehouse.gov if we wanted to. An important note, however: if you leave off the domain in the canonical name field, the zone's domain name is not appended automatically (as was the case with DNS Manager in Windows NT 4.0). You should always enter a fully qualified domain name in the last field.

It's important to know that the name server handles CNAME records in a different manner than aliases are handled in the host table. When a name server looks up a name and finds a CNAME record, it replaces the alias name with the canonical name and looks up the new name. For example, when the name server looks up bigt.movie.edu , it finds a CNAME record pointing to terminator.movie.edu . Then it looks up terminator.movie.edu , and its address is returned.

One thing you must remember about aliases like bigt is that they should never appear in the data portion (that is, on the right side) of a resource record. Stated differently, always use the canonical name ( terminator ) in the data portion of the resource record. Notice that the NS records use the canonical name.

Sometimes you can use an A record to get the effect of an alias. Suppose you have a router, like wormhole , and you want to check one of the interfaces. One common troubleshooting technique is to ping the interface to verify that it is responding. If you ping the name wormhole , the name server returns the addresses of both interfaces. ping uses the first address in the list. But which address is first?

The solution is to create two A records for wormhole . We could use the New Host command to create them as we did above, but we'll show you another way. The Other New Records command lets you choose from 19 different resource records to create. Choose Action Other New Records... and you'll see a window like Figure 4-17. Select a record type to see its description. We've selected Host (which is the nonadvanced-mode way of specifying an A record), and after we select Create Record... we'll see the same New Host window that we showed earlier, which we'll use to add an A record for wh249.movie.edu .

Figure 4-17. Other new records window

With the host table, we chose the address we wanted by using either wh249 or wh253 each name referred to one of the host's addresses. To provide equivalent capability with DNS, we didn't make wh249 and wh253 into aliases (CNAME records). That would result in both addresses for wormhole being returned when we looked up the alias. Instead, we used address records. Now, to check the operation of the 192.253.253.1 interface on wormhole , we ping wh253 since it refers to only one address. The same applies to wh249 .

To state this as a general rule: if a host is multihomed (i.e., has more than one network interface), create an address (A) record for each alias unique to one address. Create a CNAME record for each alias common to all the addresses.

4.3.4.2 One more note about PTR records

We now have two A records, wormhole.movie.edu and wh249.movie.edu , pointing to the same address, 192.249.249.1. We also have a PTR record pointing from 1.249.249.192.in-addr.arpa to wormhole.movie.edu . (This record was added automatically to the 249.249.192.in-addr.arpa zone by the New Host command. Remember that addresses are looked up as names: the IP address is reversed , and in-addr.arpa is appended.) Thus, 192.249.249.1 maps to wormhole.movie.edu and not to wh249.movie.edu . Should you create another PTR record that maps 192.249.249.1 to wh249.movie.edu ? You can create two PTR recordsit's perfectly legalbut most systems are not prepared to see more than one name for an address. We recommend that you don't bother with multiple PTR records since so few systems can use them.

4.3.5 Where Is All This Information Stored?

You may be wondering what's happened to all the resource records we've been entering. Where are they being stored? The answer is: in the memory of the DNS server process. We mentioned earlier that the DNS console communicates with the DNS server using an RPC mechanism. As you add records to a zone with the DNS console, they are added "on the fly" to the name server's memory. Of course, the name server's memory is transientwhen the name server process stops, its memory is lost. Obviously it needs a permanent storage location, too.

This is where the zone data files we specified when we created the zones come in. The zone data files are the zones' permanent storage location, holding all the zones' resource records. If you use the DNS console to make a change to a zone, the copy of the zone in the name server's memory is changed, and a flag is set to update that zone's data file. The name server updates the zone data file when it exits, unless you tell it to update the file sooner. The command Action Update Server Data Files causes the name server to update the zone data files of all the zones for which it's a primary (if the version of a zone in the server's memory is more recent than the version on disk). To avoid losing data, we recommend using Action Update Server Data Files after any changesuse it like you use the Save command in other applications. Of course, the difference here is that the server will save your data if it exits gracefully. You don't have to use Action Update Server Data Files after a batch of changes, but it doesn't hurt anything and you'll be able to sleep better.

As you've probably guessed, when the name server starts up, it reads the zone data files into memory. When you select Action Refresh or press F5 , the DNS console queries the name server and updates the console's display.

If you've been keeping track, you'll realize that DNS information exists in three places: zone data files, the name server's memory, and the DNS console's window. The diagram in Figure 4-18 helps explain how the information flows.

Figure 4-18. Where everything is stored

4.3.6 The Zone Data Files

Let's take a look at the zone data files for Movie U. After inputting the remaining host table entries, we end up with the display shown previously in Figure 4-2. (Of course, this view shows only the contents of movie.edu . The 249.249.192.in-addr.arpa and 253.253.192.in-addr.arpa zones are populated with PTR records.)

Next we select Action Update Server Data Files , and the server generates three files in %SystemRoot%\System32\DNS : movie.edu.dns , 249.249.192.in-addr.arpa.dns , and 253.253.192.in-addr.arpa.dns . They look like the following.

Contents of movie.edu.dns :

 ; ;  Data file movie.edu.dns for movie.edu zone. ;      Zone version:  4l ; @                IN      SOA terminator.movie.edu.  administrator.movie.edu.  (                         1           ; serial number                         3600        ; refresh                         600         ; retry                         86400       ; expire                         3600      ) ; minimum TTL ; ;  Zone NS records ; @                IN     NS terminator ; ;  Zone records ; bigt                    IN        CNAME    terminator carrie                  IN        A 192.253.253.4 dh                      IN        CNAME      diehard diehard                 IN        A 192.249.249.4 misery                  IN        A 192.253.253.2 robocop                 IN        A 192.249.249.2 shining                 IN        A 192.253.253.3 terminator              IN        A 192.249.249.3 wh                      IN        CNAME      wormhole wh249                   IN        A 192.249.249.1 wh253                   IN        A 192.253.253.1 wormhole                IN        A 192.249.249.1                         IN        A 192.253.253.1

Contents of 249.249.192.in-addr.arpa.dns :

 ; ;  Data file 249.249.192.in-addr.arpa.dns for 249.249.192.in-addr.arpa zone. ;      Zone version:  5l ; @               IN      SOA terminator.movie.edu.   administrator.movie.edu.   (                         5           ; serial number                         3600        ; refresh                         600         ; retry                         86400       ; expire                         3600      ) ; minimum TTL ; ;  Zone NS records ; @               IN      NS terminator.movie.edu. ; ;  Zone records ; 1                       IN        PTR wormhole.movie.edu. 2                       IN        PTR robocop.movie.edu. 3                       IN        PTR terminator.movie.edu. 4                       IN        PTR diehard.movie.edu.

Contents of 253.253.192.in-addr.arpa.dns:

 ; ;  Data file 253.253.192.in-addr.arpa.dns for 253.253.192.in-addr.arpa zone. ;      Zone version:  4l ; @                IN      SOA terminator.movie.edu.   administrator.movie.edu.   (                         4           ; serial number                         3600        ; refresh                         600         ; retry                         86400       ; expire                         3600      ) ; minimum TTL ; ;  Zone NS records ; @                IN      NS terminator.movie.edu. ; ;  Zone records ; 1                       IN        PTR wormhole.movie.edu. 2                       IN        PTR misery.movie.edu. 3                       IN        PTR shining.movie.edu. 4                       IN        PTR carrie.movie.edu.

4.3.7 Zone Data File Format

The format of zone data files is specified in the DNS standards. That means all name servers, whether Microsoft DNS Server or the BIND name server, can read each other's zone data files.

You've probably already guessed that the semicolon is the comment character. It can appear anywhere on a line, and anything to the right is considered a comment and is ignored by the name server. Blank lines are okay, too.

Each resource record must start in the first column of the fileno preceding whitespace. (Don't be confused by the examples in this book, which are indented because of the way the book is formatted.) Resource records are case-insensitiveyou can use uppercase or lowercase. The name server doesn't preserve the case, though. It matches the case of the reply to the case of the query. For example, if a record is written as terminator in the zone data file but you query for Terminator , the server responds with Terminator .

Resource records are broken up into fields, with any amount of whitespace (tabs or spaces) separating the fields.

The first field, called the owner, is the domain name of the record. Put another way, it's the node in the namespace to which the resource record is attached. You've seen the domain name on the left side of the right pane of the DNS console. (Got that?)

The next field in our examples is the class, IN, which stands for Internet. There are other classes, but none of them are currently in widespread use. Our examples use only the IN class.

The field after that is the record type. We've already discussed the SOA, NS, A, PTR, and CNAME record types, and you've probably browsed through the list of other record types in the DNS console's Other New Records window. The type simply specifies what type of data is associated with the domain name on the right: A means IP address, NS means the name of an authoritative name server, and so on.

That's a good lead-in to the final field, the RDATA or resource record data. This field holds the kind of data specified by the record type. It can be divided into multiple subfields, depending on the type. For example, A records may specify only one parameter, an IP address, but the SOA record specifies seven parameters (remember all those fields in Figure 4-13?).

Speaking of the SOA record, you'll notice in the examples that it's the only record spanning multiple lines. If you ever have to edit zone data files by hand, you can use parentheses to allow a resource record to span multiple lines. This trick works for all record types, not just SOA.

Domain names appear a lot in resource records. The left side of every resource record is a domain name, and the right side (RDATA field) of many record types also contains domain names (for example, NS and SOA records). Using a fully qualified domain name in each case is perfectly legal, but it would be a lot of work: imagine having to type movie.edu at the end of every hostname if you were entering these files by hand. Fortunately, abbreviations are allowed. You need to understand the abbreviations because the Microsoft DNS Server uses them in records it generates.

4.3.7.1 Appending domains

Every zone has a domain name: it's just the name of the zone. (This probably strikes you as pretty obvious.) This domain name is the key to the most useful shortcut. This domain name is the origin of all the data in the data file. The origin is appended to all domain names in the file not ending in a dot. The origin is different for each file because each file is associated with a different zone, each of which has a different domain name.

Since the origin is appended to names, instead of entering robocop 's address in movie.edu.dns as this:

 robocop.movie.edu.    IN A     192.249.249.2

the server generated it like this:

 robocop    IN A     192.249.249.2

In 192.249.249.in-addr.arpa.dns , this is the long way to write this record:

 2.249.249.192.in-addr.arpa.  IN PTR robocop.movie.edu.

But since 249.249.192.in-addr.arpa is the origin, the server generated:

 2  IN PTR robocop.movie.edu.

Notice that all the fully qualified domain names in the file end in a dot. That tells the server that this domain name is complete and should be left alone. Suppose you forgot the trailing dot. An entry like this:

 robocop.movie.edu    IN A     192.249.249.2

turns into an entry for robocop.movie.edu.movie.edu , which you didn't intend at all.

4.3.7.2 @ notation

If the domain name is the same as the origin, the name can be specified with an at sign (@). This is most often seen in the SOA record in data files generated by hand, but the Microsoft DNS Server also uses the @ notation in the NS records. In the movie.edu.dns file in the previous example, the @ stands for movie.edu . Of course, in the 249.249.192.in-addr.arpa.dns file, the @ stands for 249.249.192.in-addr.arpa , and in the 253. 253.192.in-addr.arpa.dns file... well, you get the idea.

4.3.7.3 Repeat last name

If there is a space or a tab in column one, the name from the last resource record is used. This shortcut gets used when there are multiple resource records for a name. Here is an example where there are two address records for one name:

 wormhole   IN A     192.249.249.1             IN A     192.253.253.1

In the second address record, the name wormhole is implied . You can use this shortcut even if the resource records are of different typesfor example, if wormhole also had a TXT (arbitrary text) record.

4.3.8 The Loopback Address

Those of you familiar with the BIND name server may be wondering if we forgot about the loopback address. If we were setting up a BIND name server, it would need one additional zone data file to cover the loopback network: the special address that hosts use to direct traffic to themselves . This network is (almost) always 127.0.0.0, and the host number is (almost) always 127.0.0.1. Therefore, the name of this file would be 0.0.127.in-addr.arpa.dns , and it would look like the other in-addr.dns files.

The following would be the contents of the 0.0.127.in-addr.arpa.dns file:

 @                IN      SOA terminator.movie.edu.   administrator.movie.edu.   (                         1           ; serial number                         3600        ; refresh                         600         ; retry                         86400       ; expire                         3600      ) ; minimum TTL ; ;  Zone NS records ; @                IN     NS terminator.movie.edu. ; ;  Zone records ; 1                IN     PTR localhost.

Why do name servers need this file? Think about it for a second. No one was given responsibility for network 127.0.0.0, yet systems use it for a loopback address. Since no one has direct responsibility, everyone who uses it is responsible for it individually. If you omit this file on a BIND name server, it will still operate . However, a lookup of 127.0.0.1 might fail: the name server will send the query to a root name server that might not be configured to map 127.0.0.1 to a name.

With the Microsoft DNS Server, you don't have to worry about creating this file and making your name server authoritative for the in-addr.arpa zone corresponding to network 127.0.0.0. The server is authoritative for this zone by default. It's called an automatically created zone and is visible in the DNS console only in advanced mode. Select View Advanced and you can see the three automatically created zones shown in Figure 4-19.

Figure 4-19. The DNS console showing automatically created zones

We've drilled down into the 127.in-addr.arpa zone to show that there's a PTR record for 1.0.0.127.in-addr.arpa pointing to the domain name localhost . In other words, a Microsoft DNS Server will reverse-map the IP address 127.0.0.1 to the domain name localhost "out of the box" without any work on your part.

The 0.in-addr.arpa and 255.in-addr.arpa zones are empty, save for NS and A records. Some hosts attempt to reverse-map the IP addresses 0.0.0.0 and 255.255.255.255, and these zones cause the local server to return an immediate NXDOMAIN (name not found) error for those queries rather than asking a root name server.

4.3.9 The Root Hints Data

Besides your local information, the name server also needs to know where the name servers for the root zone are. (Remember that the resolution process starts at the root zone, so knowing which name servers are authoritative for the root zone is critical.) This information is stored in a file called the root name server hints file , which is named %SystemRoot%\System32\DNS\cache.dns on your name server. The Microsoft DNS Server ships with a version of this file that looks like this (or at least it did when this book was published):

 ;       This file holds the information on root name servers needed  ;       to initialize cache of Internet domain name servers ;       (e.g., reference this file in the "cache  .  <file>" ;       configuration file of BIND domain name servers). ; ;       This file is made available by InterNIC registration services ;       under anonymous FTP as ;           file                /domain/named.root ;           on server           FTP.RS.INTERNIC.NET ;       -OR- under Gopher at    RS.INTERNIC.NET ;           under menu          InterNIC Registration Services (NSI) ;              submenu          InterNIC Registration Archives ;           file                named.root ; ;       last update:    Aug 22, 1997 ;       related version of root zone:   1997082200 ; ; ; formerly NS.INTERNIC.NET ; .                        3600000  IN  NS    A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4 ; ; formerly NS1.ISI.EDU ; .                        3600000      NS    B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107 ; ; formerly C.PSI.NET ; .                        3600000      NS    C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12 ; ; formerly TERP.UMD.EDU ; .                        3600000      NS    D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90 ; ; formerly NS.NASA.GOV ; .                        3600000      NS    E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10 ; ; formerly NS.ISC.ORG ; .                        3600000      NS    F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; .                        3600000      NS    G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; .                        3600000      NS    H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53 ; ; formerly NIC.NORDU.NET ; .                        3600000      NS    I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17 ; ; temporarily housed at NSI (InterNIC) ; .                        3600000      NS    J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10 ; ; housed in LINX, operated by RIPE NCC ; .                        3600000      NS    K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129  ; ; temporarily housed at ISI (IANA) ; .                        3600000      NS    L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12 ; ; housed in Japan, operated by WIDE ; .                        3600000      NS    M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33 ; End of File

This information can also be retrieved from the Internet host ftp.rs.internic.net (198.41.0.7). Use anonymous FTP to retrieve the file named.root from the domain subdirectory. The domain name "." refers to the root zone. Since the root zone's name servers change over time, don't assume this list is current. Pull a new version of named.root .

You can also view this information from within the DNS console: select a name server in the left pane and choose Action Properties . Then select the Root Hints tab to see a window like the one shown in Figure 4-20.

Figure 4-20. Root hints window

It's worth noting that the root NS records are not put into the cache and used directly. Rather, upon startup the server queries one of the root servers in the cache file for the list of root servers. The list returned is the one used by the name server to start the resolution process and is the list you see when you double-click the Cache icon.

You may be wondering what the 3600000 s are for. In older versions of this file, this number was 99999999 . It dates back to the behavior of early versions of BIND, the reference implementation of the name server. The BIND name server used to put the contents of the cache file directly into its cache, and it had to know how long to keep these records active. The 99999999 smeant a very long time . The root name server data was to be kept active for as long as the server ran. Since both BIND and the Microsoft DNS Server now store the cache file data in a special place and don't discard it if it times out, the TTL is unnecessary. But it's not harmful to have the 3600000 s,and it makes for interesting DNS folklore when you pass responsibility to the next name server administrator.


Team-Fly

Top