Learning Windows Server 2003

Zones Versus Domains

As you learned in the previous section, a DNS domain in its simplest form is a second-level name coupled with an ICANN-sponsored top-level domain—hasselltech.net, for example. In DNS parlance, a zone is the range of machines and addresses that a specific nameserver needs to be concerned about. Zones don’t necessarily need to correspond to DNS domains, meaning that I can have multiple DNS zones for the single hasselltech.net domain. For example, I can have one zone for sales.hasselltech.net, another zone for billing.hasselltech.net, and yet another for hosting.hasselltech.net, all with separate nameservers but all within the control of the hasselltech.net domain.

Why would you want multiple DNS zones for a single DNS domain? To delegate administration is a common reason. If your organization is spread all over the country and you have an administrator for each office around the country, that administrator is likely best equipped and skilled to handle DNS configuration for his office—after all, he works with the individual computers more than a higher-level administrator at the home office does. So, the home office nameserver is configured to hold a few names and addresses for servers and machines there, and the branch office nameservers hold zones for their respective computers. In this configuration, when a computer comes to their servers and requests a name for an IP address associated with a branch office, the nameservers at the home office will refer the requesting computer to the nameserver at that branch office that holds the names and addresses for that zone, a process known as delegating name resolution to other servers. Additionally, the branch office server is authoritative for its zone, meaning that it holds the definitive name-to-address correspondence for computers in its zone.

Of course, domains aren’t limited to just a second-level name plus an ICANN-approved extension. You also can have multiple levels of names: for example, customers.extranet.microsoft.com is a valid name, as is payjon.corp.hasselltech.net. You’ll see as you read further into the chapter where situations in which a longer, more extended domain name would be appropriate.

Zone Files

Zone information is stored in zone files which, by default, are stored as ASCII test files in %SystemRoot%\system32\dns. The files are stored in the format <domain>.dns (e.g., hasselltech.net.dns). These ASCII files contain the different types of information contained within forward and reverse lookup zones, which we’ll look at in just a bit.

DNS also can store zone information within Active Directory, an option I’ll discuss in more detail later in this chapter. For now, we’ll proceed on the assumption that zone files are stored in this location in ASCII format.

Forward and Reverse Lookup Zones

DNS handles forward lookups, which convert names to IP addresses, but it also handles reverse lookups, which convert IP addresses to names. There’s also something called a reverse lookup zone, which does the opposite—it catalogs all machines within a certain network range. You construct the name of a reverse lookup zone in a rather odd way. The easiest way to construct a reverse lookup zone name is to look at the range of IP addresses you’ve been assigned, drop the last dotted quad that contains the numbers you control, reverse the order of the remaining dotted quads, and then add .in-addr.arpa. For example, if your IP address is 64.246.42.130, the name of the associated reverse lookup zone is 42.246.64.in-addr.arpa.

Reverse lookup zones are constructed a bit differently, depending on whether you have a class A, B, or C IP address. Table 4-1 shows the respective ways to generate a reverse lookup zone name.

Table 4-1. Generating a reverse lookup zone name

Address class	Resulting zone name and method
Class A (12.0.0.0/8)	12.in-addr.arpa Only the first quad is set, so only one quad needs to be in the reverse zone.
Class B (152.100.0.0/16)	100.152.in-addr.arpa Because only two dotted quads are included, only two need to be noted in the reverse zone.
Class C (209.197.152.0/24)	152.197.209.in-addr.arpa All dotted quads set in the IP address range need to be included in the reverse lookup zone name.

In practice, it’s very likely that you don’t need a reverse lookup zone for public-facing DNS servers, and it’s equally likely that you would be prevented, on a technical basis, from creating one. (Internal DNS servers are another matter, which you’ll see in a bit.) Although forward lookup zones concern hostnames and DNS domain names, which are under your control and management because you buy them from an accredited registrar, reverse lookup zones deal mainly with IP addresses and their owners, which probably are not under your control. Unless you have contacted the Internet Assigned Names Authority (IANA) and obtained a block of IP addresses specifically from them, it’s probable that your ISP actually owns the addresses and therefore is the one tasked with maintaining reverse lookup zones.

There are really only a few reasons why it’s advantageous to control your own reverse lookup zone. First and foremost, some mail servers will refuse to exchange Internet mail with your servers if their reverse lookups reveal that you’re using a dynamically assigned IP address block of typical ISPs. This can be a real problem, but your ISP usually can help you out with this. Second, the Nslookup command can return a nasty but harmless error message about being unable to find a server name for your current IP address, depending on how you are connected to the Internet. Although this is annoying, it’s simply saying no appropriate reverse zone is configured for the current computer.