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. As you read further into the chapter, you'll see situations in which a longer, more extended domain name would be appropriate.
Zone information is stored in zone files that, 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 hold 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 (as an application partition), 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.
DNS handles forward lookups, which convert names to IP addresses, and the data is stored within a forward lookup zone. But DNS also handles reverse lookups, which convert IP addresses to names. There's also something called a reverse lookup zone, which does the opposite of a forward lookup zone—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 ( |
Only the first quad is set, so only one quad needs to be in the reverse zone. |
Class B ( |
Because only two dotted quads are included, only two need to be noted in the reverse zone. |
Class C ( |
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. So, when you've just installed Active Directory and you run nslookup to check things out, and you get no results, this is most likely because you haven't yet configured a reverse lookup zone.
Get Windows Server 2008: The Definitive Guide now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
