4.4 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.4.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 zone—also 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 DNS Server and specify where the name server you want to manage—the primary master—is running. As you can see in Figure 4-9, you can choose either the local machine or specify a name server running somewhere else. If the name server isn't local, enter its name or IP address. Leave the box checked, which causes the DNS console to immediately contact the server to obtain its status and a list of any zones it might already be authoritative for.

Figure 4-9. Specifying the location of a name server to manage

The DNS console adds an icon in the left pane for that name server, as in Figure 4-10.

Figure 4-10. 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 DNS Server 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 running—you can use Connect to DNS Server to add it, and you'll be right back where you started.

4.4.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-11.

Figure 4-11. New Zone Wizard, first window

To continue, click Next. In the next window (see Figure 4-12), you have three choices for the type of zone: Primary zone, Secondary zone, and Stub zone. For now, choose Primary zone and click Next. Notice that the option to store this zone's data in Active Directory is greyed out. Microsoft calls this feature Active Directory integration and we'll talk about it more in Chapter 8.

Figure 4-12. New Zone Wizard, second window

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

Figure 4-13. New Zone Wizard, third window

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

Figure 4-14. New Zone Wizard, fourth window

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

Figure 4-15. New Zone Wizard, fifth window

The zone file, also called a zone datafile, 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 datafile to make changes to the zone, but the DNS console allows you to avoid editing the file by hand. As a result, you probably won't see the zone datafiles 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 datafile name 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. In the case of the DNS console, however, it's best to go along with Microsoft's default .dns extension.

When you've entered a filename (or left the automatically chosen name alone), click Next to display the window shown in Figure 4-16, which asks you to choose this zone's policy for dynamic updates. Dynamic updates are a relatively recent extension to the DNS protocol that we describe in detail in Chapter 11. Briefly, they allow another entity—such as a domain controller or a DHCP server—to update the contents of a zone by sending a message to the name server over the network. The alternative (and traditional) way to make changes to the zone involves using the DNS console as we're about to describe. As you might guess, allowing just anyone to send messages to your name server to change your zone is a significant security risk! That's why the DNS console asks you up front, when creating the zone, how you want to handle dynamic updates. Some Windows components, such as domain controllers and DHCP servers, use dynamic updates to keep DNS information up to date, so it's possible you'll want to enable this feature eventually. But for now, check the third option, Do not allow dynamic updates, to leave dynamic update disabled while we set things up.

Figure 4-16. New Zone Wizard, sixth window

Click Next and you'll see the confirmation window shown in Figure 4-17.

Figure 4-17. 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-18. The DNS console has created the zone and a few resource records. Let's talk about them one by one.

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

4.4.2.1 The SOA record

The first record displayed is the start of authority, or SOA, 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.

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-19.

Figure 4-19. The movie.edu SOA record

Let's skip that first field, Serial number, for now—don't worry, we'll cover it later in the chapter—and 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 (to turn this field into an email address, you replace the first dot with an at sign, @). The DNS console defaults to a username of hostmaster, but in other zones you might see root, postmaster, or administrator 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 secondary name servers (also known as slave name servers) and are discussed when we introduce secondary name servers later in this chapter. For now, assume these are reasonable values.

4.4.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 secondary name servers, we'll add NS records. The DNS console created an NS record for terminator because it's a name server—the primary master name server—for movie.edu.

4.4.2.3 The A record

The final automatically created record is an address record or A record. 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 the DNS console automatically created the A record for terminator.movie.edu to specify its IP address. When you create a new zone, the DNS console creates an address record for the primary name server. It uses the hostname configured in the primary master's DNS configuration.

Note that some abbreviating is going on in the DNS console's display. The DNS console displays only terminator, but the fully qualified domain name of this host is terminator.movie.edu. The DNS console normally displays a relative (that is, abbreviated) domain name on the right, so you have to look at what zone or domain is selected on the left to construct the fully qualified domain name. And recall that when records are attached to the name of the zone (which is the case for the SOA and NS records here), the DNS console displays the somewhat cryptic phrase (same as parent folder) in the Name column.

You're probably anxious to add resource records for the rest of your zone, but it's best to create the reverse-mapping (in-addr.arpa) zones first.

4.4.3 Creating a New Reverse-Mapping Zone

Zones like movie.edu handle mapping names to addresses using A records. But mapping addresses back to names—reverse mapping—is 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-20 shows the fourth window of the New Zone Wizard when creating a reverse-mapping zone.

Figure 4-20. 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 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 10.

4.4.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 (A). 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-21.

Figure 4-21. The New Host window

You'll notice that we typed a relative domain name (robocop) and not a fully qualified domain name (robocop.movie.edu). The DNS console is being helpful here and saving you some typing: it appends the domain name of the zone selected in the left pane (i.e., the zone that you're adding the new host to) to create a fully qualified domain name as shown.

4.4.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 (CNAME). You'll see a window that looks like the one in Figure 4-22.

Figure 4-22. Creating a CNAME record

The input shown in Figure 4-22 will generate an alias from bigt.movie.edu to terminator.movie.edu. The Fully qualified domain name (FQDN) field shows the full name of the alias, which resides in the current zone. But the name that the alias points to (labeled Fully qualified name (FQDN) for target host) can point anywhere, to any domain name. 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. 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 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 earlier in this chapter, but we'll show you another way. The Other New Records command lets you choose from 22 different resource records to create. Choose Action Other New Records and you'll see a window like Figure 4-23. Select a record type to see its description. We've selected Host (A), 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-23. 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.

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.4.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 option. 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 records—it's perfectly legal—but 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.4.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 transient—when the name server process stops, its memory is lost. Obviously it needs a permanent storage location, too.

This is where the zone datafiles specified when we created the zones come in. The zone datafiles 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 datafile. The name server updates the zone datafile when it exits, unless you tell it to update the file sooner. Choosing Action Update Server Data Files (available when a name server is selected in the left pane) causes the name server to update the zone datafiles 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). There's also a per-zone version of this command: with a primary zone selected in the left pane, selecting Action Update Server Data File causes the server to update only that zone's file. To avoid losing data, we recommend using Action Update Server Data File(s) after a batch of changes—use 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 File(s) after a batch of changes, but it doesn't hurt anything and you'll sleep better.

As you've probably guessed, when the name server starts up, it reads the zone datafiles 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 datafiles, the name server's memory, and the DNS console's window. The diagram in Figure 4-24 helps explain how the information flows.

Figure 4-24. Where everything is stored

4.4.6 The Zone Datafiles

Let's take a look at the zone datafiles for Movie U. After inputting the remaining host table entries, we end up with the display shown 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. We include them here.

4.4.6.1 Contents of movie.edu.dns

;
;  Database file movie.edu.dns for movie.edu zone.
;      Zone version:  17
;

@                       IN  SOA terminator.movie.edu.  hostmaster.movie.edu. (
                         17           ; serial number
                         900          ; refresh
                         600          ; retry
                         86400        ; expire
                         3600       ) ; default TTL

;
;  Zone NS records
;

@                       NS     terminator.movie.edu.

;
;  Zone records
;

bigt                    CNAME  terminator.movie.edu.
carrie                  A 192.253.253.4
dh                      CNAME  diehard.movie.edu.
diehard                 A 192.249.249.4
misery                  A 192.253.253.2
robocop                 A 192.249.249.2
shining                 A 192.253.253.3
terminator              A 192.249.249.3
wh                      CNAME  wormhole.movie.edu.
wh249                   A 192.249.249.1
wh253                   A 192.253.253.1
wormhole                A 192.253.253.1
                        A 192.249.249.1

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

;
;  Database file 249.249.192.in-addr.arpa.dns for 249.249.192.in-addr.arpa zone.
;      Zone version:  7
;

@                       IN  SOA terminator.movie.edu.  hostmaster.movie.edu. (
                         7            ; serial number
                         900          ; refresh
                         600          ; retry
                         86400        ; expire
                         3600       ) ; default TTL

;
;  Zone NS records
;

@                       NS     terminator.movie.edu.

;
;  Zone records
;

1                       PTR    wormhole.movie.edu.
2                       PTR    robocop.movie.edu.
3                       PTR    terminator.movie.edu.
4                       PTR    diehard.movie.edu.

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

;
;  Database file 253.253.192.in-addr.arpa.dns for 253.253.192.in-addr.arpa zone.
;      Zone version:  7
;

@                       IN  SOA terminator.movie.edu.  hostmaster.movie.edu. (
                         7            ; serial number
                         900          ; refresh
                         600          ; retry
                         86400        ; expire
                         3600       ) ; default TTL

;
;  Zone NS records
;

@                       NS      terminator.movie.edu.

;
;  Zone



 records
;

1                       PTR     wormhole.movie.edu.
2                       PTR     misery.movie.edu.
3                       PTR     shining.movie.edu.
4                       PTR     carrie.movie.edu.

4.4.7 Zone Datafile Format

The format of zone datafiles 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 datafiles.

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 file—no 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-insensitive—you 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 datafile 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.

The next field in our examples is the class, IN, which stands for Internet. Other classes exist, 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 field. 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 specify only one parameter, an IP address, but the SOA record specifies seven parameters (remember all those fields in Figure 4-19?).

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 datafiles 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.4.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 datafile. 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                  A     192.249.249.2

The server also used another shortcut and omitted the class, IN. If you omit the class on a record, the previous record's class is used. Since this file uses only the IN class, it makes sense to specify it once on the first record in the file and leave it off the subsequent records. In that case, the first record's class applies to all the other records.

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                             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     A     192.249.249.2

turns into an entry for robocop.movie.edu.movie.edu, not what you intended at all.

4.4.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 datafiles generated by hand, but the Microsoft DNS Server also uses the @ notation in 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.4.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 a name has multiple resource records. This example shows two address records for one name:

wormhole    A     192.253.253.1 
            A     192.249.249.1

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

4.4.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 datafile 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.arpa.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
;

@                       NS terminator.movie.edu.

;
;  Zone records
;

1                       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 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-25.

Figure 4-25. 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, the Microsoft DNS Server reverse-maps 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 Name Error (also known as NXDOMAIN, which is short for nonexistent domain) for those queries rather than asking a root name server.

4.4.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):

;
;   cache.dns -- DNS CACHE FILE
;
;   Initial cache data for root domain servers.
;
;   YOU SHOULD CHANGE:
;   ->  Nothing if connected to the Internet.  Edit this file only when
;       updated root name server list is released.
;           OR
;   ->  If NOT connected to the Internet, remove these records and replace
;       with NS and A records for the DNS server authoritative for the
;       root domain at your site.
;
;   Note, if you are a root domain server, for your own private intranet,
;   no cache is required, and you may edit your boot file to remove
;   it.
;

;       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 
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.INTERNIC.NET
;
;       last update:    Nov 5, 2002
;       related version of root zone:   2002110501
;
;
; 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
;
; operated by VeriSign, Inc. 
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
;
; housed in LINX, operated by RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129 
;
; operated by 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

The domain name "." refers to the root zone.

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. However, you probably won't ever need to update your server's cache.dns file. Because the ability to reach the root name servers is so important, the Microsoft DNS Server goes out of its way to make sure its list of root name servers is always up to date. It views the contents of cache.dns somewhat suspiciously and doesn't use that list of name servers directly. (That's why this file is called the root hints.) Rather, when the server starts up, it chooses a root name server from cache.dns at random and asks it for the current list of root name servers. After all, who would know the current list of root name servers better than one of the root name 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 drill down in the left pane of the DNS console. The DNS server also overwrites the contents of cache.dns with the updated list. As a result, if you've started the DNS server even just once, your cache.dns will look different than the one shown here because the server doesn't preserve the comments when it overwrites the file.

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

Figure 4-26. Root Hints window

Finally, you may be wondering what the 3600000s in the file are for. In older versions of this file, this number was 99999999. It dates back to the behavior of early versions of BIND. The BIND name server used to put the contents of the root hints file directly into its cache, and it had to know how long to keep these records active. The 99999999s meant 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 root hints 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 3600000s, and it makes for interesting DNS folklore when you pass responsibility to the next name server administrator.