The Domain Name System (DNS) is a staple of the public Internet and is the name resolution system of choice for both large and small networks. DNS is a directory of IP addresses and their corresponding hostnames, much like a phonebook in functionality. However, DNS is more complex than a phonebook and it stores many types of mappings as well as information on services provided by servers on your network.
Whereas Windows NT relied on the Windows Internet Naming Service (WINS) and NetBIOS for name resolution, Windows Server 2008 depends on DNS. In fact, DNS is required for anyone that wants to use Active Directory—DNS lies at the heart of Active Directory, and they’re inseparable. WINS is obsolesced, at least in terms of pure Windows infrastructure if you have an Active Directory network with all machines running Windows 2000 or later and DNS-aware applications.
In this chapter, I’ll discuss the fundamentals of DNS, its structure, and the various types of data it supports and requires, and then I’ll proceed through installing and configuring a Windows DNS server and describe how you can integrate it with Active Directory.
Let’s go through the basic building blocks of DNS first before we break into more advanced concepts. I’m going to provide you with a very fundamental, introductory look at DNS, and then in the following sections I’ll break down each part with more detailed explanations and examples. Think of this as an abstract or executive summary, just so we’re all on the same page before I move on to more technical topics.
The main premise of DNS is to provide name resolution services—that is, to resolve friendly textual hostnames to their associated IP addresses. DNS is the de facto standard for name resolution on the Internet and in modern networks that use TCP/IP as the transmission protocol. DNS is based on domains, which are simply textual names that refer to logical groupings of computers There are top-level domains (TLDs), including some that are probably familiar to you: .COM, .NET, .ORG, and the like. There are also second-level domains, which are less inclusive and usually take the form of
tld. For example, my domain is jonathanhassell.com. O’Reilly has a domain name of oreilly.com. CNN’s domain is cnn.com.
Politically, there is an organization called ICANN, short for the Internet Consortium of Assigned Names and Numbers, which tracks the top-level domains. This keeps utter confusion from breaking out when thousands upon thousands of top-level domains might be issued. Individuals and businesses are allowed to register second-level domain names beneath top-level domains—hasselltech.net, for example.
DNS resolves names based on zones. Zones contain information on computers, services, and IP addresses for a collection of computers. Zones typically correspond to DNS domains, but they certainly do not have to. The DNS server or servers in a zone that contain a readable and writable copy of the zone file (which contains all that information on computers, services, and addresses) is considered to be authoritative. You must have at least one authoritative server per zone for DNS to function. Any other DNS servers within this zone are considered to be secondary servers, meaning they hold a read-only copy of the DNS zone file.
Finally, there are two types of zones: forward lookup zones, which resolve hostnames to IP addresses, and reverse lookup zones, which do the opposite and resolve IP addresses to hostnames. Reverse lookup zones fall under a special top-level domain named in-addr.arpa, which ordinary users and clients never see in the course of their day-to-day work.
Now, let’s take a closer look at these elements of DNS.
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 126.96.36.199, 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.
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.
A DNS zone contains various types of entries, called resource records. Resource records are the meat of a DNS zone, providing information about hostnames, IP addresses, and in some cases the services offered by a particular machine. There are several different classes of record types, the most common of which I’ll define now.
A sample A record looks like this in a zone file:
colossus A 192.168.0.10
Using host records, you can implement a load-balancing technique known as round-robin DNS. Round-robin DNS involves entering multiple A records, all configured with the same hostname, but with different IP addresses that correspond to different machines. This way, when computers contact a nameserver for a certain hostname, they have an equal chance of receiving any one of the number of machines with A records. For example, if I have a web site at www.hasselltech.net and I have three web servers at 192.168.0.50, 192.168.0.51, and 192.168.0.52, I can configure three A records, all named “www,” but with the three IP addresses mentioned earlier. Now, when client computers come to the nameserver and ask for the IP address of www.hasselltech.net, they have a 33% chance of receiving 192.168.0.50 as the web server of choice, a 33% chance of receiving 192.168.0.51, and a 33% chance of receiving 192.168.0.52. It’s a poor man’s load-balancing system.
Let’s get a bit more technical: in this scenario, Windows 2000 and Windows XP clients will continue to attempt a connection to the first web server that was originally resolved. A DNS cache timeout value on the client is set to 86,400 seconds (one day) by default. If you change this value on the client to one second, you have better odds of reaching your server. You can change this value in the Registry with the following key:
MaxCacheEntryTtlLimit to the number of seconds desired.
If the group of machines that serve web sites are on different subnets, the DNS system can return the “proper” address from a round-robin record set—that is, the one that is closest to the client requesting it. This functionality is enabled by default. For example, if you have one A record set up for www.hasselltech.net on IP address 192.168.0.51, and another A record set up for the same hostname on IP address 10.0.0.25, a client computer located on the 10.0.0.0 subnet will receive the 10.0.0.25 A record from his request, and a client computer located on the 192.168.0.0 subnet will receive the 192.168.0.51 A record from his request.
The price is right—it’s free with any nameserver.
It’s less complex than other, proprietary balancing systems.
It’s easy to maintain. You can simply add and delete A records in the zone file for each host as they come and go to and from production service.
The disadvantages include the following:
It’s less complex than other, proprietary balancing systems. Yes, this is an advantage and a disadvantage because a less complex system is less flexible than a proprietary solution.
If a web server goes down, DNS isn’t aware of it. It simply will continue to dole out IP addresses regardless of whether the server is available.
It doesn’t take into account the various capabilities and capacities of each system—it distributes the load fairly equally, whether your group of machines includes a Pentium 2 or a dual Pentium IV Xeon machine.
CNAME, or canonical name, records allow you to give multiple hostnames to one IP address. Using CNAMEs, you can have a machine answering on one IP address but listening to several different hostnames—www.hasselltech.net, ftp.hasselltech.net, and mail.hasselltech.net all might be on one IP address, 192.168.1.2. CNAMEs effectively work as aliases.
However, there’s a caveat to these records: you can’t have multiple identical CNAMEs. For example, if you have a record for www-secure.hasselltech.net on 192.168.1.2, you can’t have another CNAME record named www-secure.hasselltech.net for a different IP address. CNAMEs are only for multiple names to one IP address, not for multiple IP addresses to one name. Note that these names are zone-dependent, not server-dependent.
A sample CNAME record in zone file format looks like this:
ftp CNAME colossus.hasselltech.net
Mail exchanger, or MX, records identify the mail server or mail servers for a specific zone or domain. Very simply, they instruct connecting computers to send all mail destined for a domain to a specific machine configured to receive Internet email.
In practice, a specific DNS zone can have multiple MX records. Each MX record is also assigned a preference number, which simply indicates what steps the respective machines listed should take when receiving Internet email. Lower preference numbers have higher priority. For example, let’s say I have the following MX records:
This instructs connecting computers to send Internet email destined to hasselltech.net to the machine mail.hasselltech.net. However, if that machine isn’t answering requests, connecting computers are instructed to try the machine queue.perigee.net and deliver mail there because the preference number is higher (100) than that of the first machine, which is 10. MX preference numbers provide a bit of failover protection if your organization’s mail server is on a flaky or nonpermanent connection.
Entering two MX records with the same preference number distributes the load between the two hosts roughly equally, much like round-robin DNS balancing using multiple A records.
Here is a sample MX record in zone file format:
@ MX 10 mail.hasselltech.net @ MX 100 queue.perigee.net
Nameserver (NS) records define the nameservers that can answer queries for a specific domain. They also delegate the resolution duties for various subdomains to other zones. For example, you might configure an NS record for the “sales” subdomain to delegate name resolution duties to the salesns.hasselltech.net machine, which handles that zone, or an NS record for the “billing” subdomain to delegate duties to the billing-dns.hasselltech.net computer.
A sample NS record in zone file format looks like this:
@ NS colossus.hasselltech.net. @ NS ns2.hasselltech.net.
The start of authority, or SOA, record for a zone names the primary nameservers that are authoritative for a particular zone and provides contact information for the primary administrator of the zone. It also controls how long a nonauthoritative nameserver can keep the information it retrieved in its own cache before needing to verify the data with the authoritative server again.
The retry interval indicates how long the secondary nameserver must wait before attempting to contact the primary nameserver again after a failed attempt to refresh its zones after the refresh interval has lapsed.
This value indicates to other nameservers how long they can use information they’ve previously retrieved from this authoritative nameserver before being required to consult the authoritative server again for updated or refreshed information. This is, by default, 60 minutes. You also can set TTL values for individual records that override this minimum default setting for a zone.
A sample SOA record in zone file format looks like this:
@ IN SOA colossus.hasselltech.net. admin.hasselltech.net. ( 200509171203; serial number 100; refresh 50; retry 86400 ; expire 3600 ) ; default TTL
A sample PTR record in zone file format looks like this:
188.8.131.52.in-addr.arpa. IN PTR alpha.enablehosting.com
Service (SRV) records indicate the range and availability of services in a particular zone or domain. They catalog the protocols and services running on specific ports in a zone, creating a “Yellow Pages” of sorts for connecting computers to find machines in the zone that will handle their specific types of requests. Like MX records, SRV records have a preference number, so you can perform a kind of poor man’s load balancing and fault tolerance with these as well.
SRV records require a bit more explanation because they are so important to Active Directory. Here is an example SRV record in zone file format:
_kerberos._tcp._sites.dc._msdcs 600 SRV 100 88 colossus.hasselltech.net.
The service—in this case, Kerberos—is the leftmost part of the record, and the
_tcp refers to whether the service operates on the TCP or UDP transmission protocols. The rightmost part of the record—in this case, colossus.hasseltech.net—identifies the machine that is listening for requests for the service named in the record. The first number in the middle,
600, indicates the time to live (TTL) for that record, recorded in seconds. The rightmost number,
88, refers to the port number on which the service is listening. Finally,
100 refers to the preference number for the record—these work exactly like MX record preference numbers as described in the previous section.
Why are SRV records crucial to Active Directory? Because they indicate which domain machines are running what Active Directory services. Active Directory really looks for only four services to be advertised within SRV records:
To provide a mechanism for changing Kerberos passwords securely
For the Lightweight Directory Access Protocol, the way external programs communicate and exchange data with Active Directory
For the Global Catalog, which contains a subset of attributes for all the objects in an Active Directory forest
A warning that applies from this point forward: even though Microsoft has set up these entries with a leading underscore, you do not want to use either “-” or “_” as the first character in a DNS name, as it is not RFC-compliant. This will cause problems if you ever need to integrate or operate in conjunction with Unix-based BIND DNS servers.
DNS has built-in redundancy by allowing for multiple primary and secondary nameservers for a particular domain or zone. Each server, whether identified as primary or secondary, holds a copy of the zone file and acts on its contents. Secondary nameservers can answer queries without any sort of architectural limitation, just as primary nameservers can. However, the secondary nameservers must retrieve updates to zones from the primary nameserver on a regular basis to ensure their records are up-to-date.
Each zone can have only one primary nameserver, but can have as many secondary nameservers as is practical. All changes, deletions, and other modifications to a zone are made on the primary nameserver. However, nameservers designated as secondary nameservers hold read-only copies of the zone contents from their associated primary nameservers—zones can’t be directly modified on secondary nameservers. The secondary nameserver will automatically determine the primary nameserver for a zone by examining the SOA records for that zone, and will contact that machine on a regular basis to force a zone file refresh.
Several mechanisms exist to force a zone transfer. For one, all of the secondary nameservers will query the primary nameserver for updates: these refreshes are generally “pull"-style updates, whereby machines fetch zones from a particular computer, rather than “push"-style updates. In addition, when a nameserver identified as secondary for any zone is rebooted or its DNS service is restarted, it will automatically query the primary server on record for an update. You also can force a zone transfer by simply right-clicking the zone inside the DNS Management snap-in on the secondary server and selecting “Transfer from Master” or “Reload from Master,” to either refresh changes or refresh the entire zone file, respectively.
Transfers also are triggered by the expiration date and refresh interval, and, indirectly, by the retry interval for a particular zone. The secondary nameserver will query the primary at the time indicated by the refresh interval—this is generally 15 minutes by default, but you might find a compelling reason to change this depending on your network traffic and needs. If the serial number on the SOA record for a zone is higher on the primary nameserver than on the secondary nameserver’s zone record, the transfer will take place. However, if the secondary nameserver can’t contact the primary nameserver at the time the refresh interval has elapsed, the secondary nameserver will wait for the amount of time specified in the retry interval and then try again. If further attempts fail, at the time listed in the expiration date section of the record, the secondary nameserver will simply stop answering DNS requests, lest it give inaccurate and obsolete information to clients.
A relatively new DNS RFC, 1995, now allows for incremental zone transfers (known in shorthand as IXFRs), which remove one of the largest stumbling blocks of DNS administration. It used to be that when a zone refresh was needed, DNS couldn’t discriminate the changes made on the primary server: even if only one line of a 6,000-line zone file had changed, the entire zone needed to be transferred to the secondary machines in a process commonly referred to as a full zone transfer (or AXFR). Although that process wasn’t a big deal if you had only one secondary nameserver, it became a large headache for organizations with tens or hundreds of secondary nameservers spread across the country or world. With the advent of RFC 1995, nameservers now have the ability to detect the differences between two zone files and transfer only the changed information—saving bandwidth, transfer time, and CPU power.
In this section, I’ll guide you through the process of actually creating a nameserver, and then in the remainder of the chapter I’ll add to the functionality of the nameserver to prepare it for use with Active Directory.
Nameservers need a constant connection to the Internet and a non-changing IP, either set statically on the server itself or delivered consistently through a DHCP reservation. The machine you’re building out as a nameserver doesn’t need to be that powerful; a fast Pentium III machine with 512 MB or so of RAM will be more than sufficient.
In the following examples, I will use the fictitious domain name hasselltech.net, with the also fictitious machine name “colossus” and IP address 192.168.0.5. You can, of course, replace these as appropriate when following along with your own computer.
Open Server Manager.
In the left pane, click Roles, and then in the right pane, click Add.
Click Next in the Add Roles Wizard.
Find DNS Server in the list, check its box, and click Next.
Click Next on the “Introduction to DNS Server” screen.
Click Install, wait for the process to complete, and then close the Add Server Roles box.
If you have your computer set up to receive an IP address via DHCP, the DNS Server role installation will complain loudly that DNS isn’t intended to work on dynamically assigned IP addresses. For this example, we can acknowledge the warnings and continue. As mentioned previously, make sure nameservers that are actually in production—not a test environment—have a consistent, unchanging IP address.
Next, point your new nameserver to itself for name resolution so that when you run tests, you’re not querying your ISP’s nameservers. In fact, most nameservers point to themselves, rather than to other nameservers, for name resolution. I recommend setting this through the command line using the
netsh command, like so:
netsh int ip set dns "Local Area Connection" static 192.168.0.5 primary
You can replace
Local Area Connection with the name, as it appears in your network connection properties, of your network connection. Also, replace
192.168.0.5 with the local nameserver’s IP.
Of course, you also can change the nameservers to use for name resolution through the Windows interface by following these steps:
Inside the Control Panel, double-click the Network Connections applet.
Inside the Network Connections dialog box, right-click the name of your network connection and choose Properties from the context menu.
Navigate to the General tab, and then select Internet Protocol (TCP/IP).
Click the Properties button.
Click the “Use the following DNS server address” radio button, and then enter the nameserver’s IP address into the box.
Now that the DNS server software is installed, you need to start the DNS service. Select Start, then click Administrative Tools and select DNS. The DNS Management snap-in will appear, as shown in Figure 4-1 (although it will not have all of the Forest Lookup Zones shown in the figure).
We’ll manually set up DNS later in this chapter, so ignore the message to use the Configure Your DNS Server Wizard. At this point, you have a functional nameserver, which performs “caching-only” functions—that is, it doesn’t hold any DNS information unique to itself, but it does know how to contact the 13 root servers as held by ICANN, the master of DNS on the Internet, and it can resolve Internet addresses by contacting them. Windows Server 2008’s DNS software knows how to do this by default, without any configuration on your part.
Windows Server 2008’s DNS component is compliant with RFC 1995 and can do incremental transfers (as mentioned earlier, known as IXFRs in DNS parlance) with other Windows Server 2003 or Windows Server 2008 servers supporting the feature. It can also still do the old-style full zone transfers, referred to as AXFRs, with noncompliant nameservers and with non-Windows Server 2003 or Windows Server 2008 machines. There is no way to instruct Windows Server 2008 to always send full zone files to all servers, regardless of whether they are compliant. You can, however, tell Windows to send incremental zone transfers to all supporting servers, regardless of whether they run Windows Server 2003 or Windows Server 2008. Here’s how:
Open the DNS Management snap-in.
Right-click your server and select Properties from the context menu.
Navigate to the Advanced tab, and uncheck the box labeled BIND Secondaries.
Click OK to finish.
Now the server will use incremental zone transfers to all supporting servers, not just to those running Windows Server 2003 or Windows Server 2008.
Choose Primary Zone, and then click Next.
Enter the zone name. In this example, I’ll use hasselltech.net. Click Next to continue.
Enter a name for the new zone file, which is stored in ASCII format. The default name is your domain with .DNS appended to the end—hasselltech.net.dns, for example. The zone files are stored in %SystemRoot%\system32\dns. Click Next.
On the Dynamic Update screen, choose to allow both insecure and secure dynamic updates. I’ll discuss dynamic DNS updating in a later section. Click Next.
Click Finish to complete the zone creation process.
The hasselltech.net zone has now been created.
Enter the hostname of the machine for which you’re entering the record, and then enter the IP address of the machine. As you enter the hostname, the fully qualified domain name (FQDN) will adjust to show the full hostname, including the domain, to check your work. You also can check the “Create associated pointer (PTR)” record checkbox, which enters a PTR record into the reverse lookup zone, if one is currently configured. (If none is set up, the process will throw an error.) Click OK.
You can enable or disable round-robin DNS balancing using the nameserver’s Advanced Properties screen, which you’ll find by right-clicking the nameserver name in the DNS Management Snap-in’s lefthand pane and selecting Properties from the context menu. Figure 4-3 shows this screen, on the Advanced tab of the Properties sheet.
Check “Enable round robin” in the “Server options” box to enable round robin, and uncheck it to disable it.
DNS round-robin functionality is enabled on a per-server level, not on a per-zone level.
Also, if you want to turn off the subnet mask ordering feature, uncheck “Enable netmask ordering” in the “Server options” box, which is on the Advanced Properties screen, as shown in Figure 4-3.
A default SOA record is created when you create a new zone in Windows Server 2008. To modify an SOA record, double-click it in the DNS Management snap-in. The screen will look something like Figure 4-4.
Here are descriptions of the various fields on this tab:
The serial number indicates whether the SOA record has changed since the last update on the part of a nonauthoritative nameserver. If you want to change this number, click the Increment button; you can’t simply edit the field.
This field indicates the administrator responsible for configuring and editing this zone. This is the administrator’s email address, but with a period in place of the normal at sign (@) and a period appended to the end of the string. For example, if your administrator is firstname.lastname@example.org, in this field you would enter hostmaster.hasselltech.net.
The retry interval indicates how long the secondary nameserver must wait before attempting to contact the authoritative nameserver again after a failed attempt to refresh its zone after the refresh interval has lapsed.
This value essentially indicates how long a zone file is valid for use in production environments. It dictates how long a secondary nameserver will continue attempting a zone transfer from its primary nameserver. When this expiration date is reached, the zone on the secondary nameserver expires, and that server stops responding to queries.
This value indicates to other nameservers how long they can use information they’ve previously retrieved from this nameserver before being required to consult the authoritative server again for updated or refreshed information. This is, by default, 60 minutes. You also can set TTL values for individual records that override this minimum default setting for a zone.
This value overrides the minimum (default) TTL as described earlier and is limited to only this SOA record.
NS records, as you learned earlier in this chapter, link the hostnames of nameservers to their IP addresses. To create these records, inside the DNS Management snap-in right-click the zone file in question and select Properties. Then select the Name Servers tab. You’ll be greeted with the screen shown in Figure 4-5.
The primary NS record is displayed, as it was created by default when you first constructed the zone. Click the Add button to insert a new NS record—for example, for a secondary nameserver. In the box that appears, type in the new machine’s fully qualified domain name and click the Resolve button. Windows Server 2008 uses a reverse lookup to determine the IP address of the hostname you entered. If you agree with its finding, click the Add button beside the IP address and the NS record will be entered. Click OK twice to close.
Recall that CNAME records map different hostnames to pre-existing A records, allowing multiple DNS names for a host. To create these records, right-click the hasselltech.net node in the lefthand pane of the DNS Management snap-in and choose New Alias (CNAME) from the context menu. The New Resource Record dialog box appears, as shown in Figure 4-6.
Enter the aliased name of the machine for which you’re entering the record (this is the canonical name), and then enter the fully qualified domain name of the host you’re aliasing. As you enter the CNAME, the fully qualified domain name field just below will adjust to show the full hostname, including the domain, to check your work.
Click OK to finish.
As you’ll remember from earlier in this chapter, MX records dictate how mail is delivered to a specific DNS zone. To create these records, inside the DNS snap-in right-click the hasselltech.net node in the lefthand pane and choose New Mail Exchanger (MX) from the context menu. The New Resource Record dialog box appears, as shown in Figure 4-7.
Enter the name of the domain or zone for which you’re entering the record, and then enter the fully qualified domain name of the host to which mail for that domain or zone should be delivered. As you enter the CNAME, the fully qualified domain name field just below will adjust to show the full hostname, including the domain, to check your work. Finally, in the Mail server priority box, type the MX preference number that should apply to this record.
Click OK to close.
You learned earlier in this chapter that reverse lookup zones map IP addresses to their corresponding hostnames. To create these records, inside the DNS Management snap-in right-click the Reverse Lookup Zones folder and choose New Zone from the context menu. You’ll be presented with the New Zone Wizard. Click Next to bypass the introductory screen, and you’ll see Figure 4-8.
Then follow these steps:
Choose “Primary zone,” and click Next.
Enter the network numbers for your network in the Network ID field—for example, 192.168.0.0—and then click Next.
The Dynamic Updates page appears. Select to allow both insecure and secure updates, and then click Next.
Click Finish to complete the wizard.
Your reverse lookup zone has been created.
Remember that PTR records map IP addresses to their hostnames and are vital within a reverse lookup zone. To create these records, right-click the appropriate reverse lookup zone within the DNS Management snap-in and select New Pointer (PTR) from the context menu. The New Resource Record dialog will appear, as shown in Figure 4-9.
On this screen, all you need to do is enter the last dotted quad of a specific IP address, and then enter the hostname to which that address should refer. The FQDN for the reverse lookup record will fill in automatically.
Click OK to finish.
In this section, I’ll cover creating a secondary nameserver to serve a zone. Some preliminary steps are necessary, though: first, the machine should be running Windows Server 2008, and it should have the DNS service installed, as mentioned before. The machine’s network connection should be configured so that its preferred nameserver is itself. (Also, for the purposes of this section, the secondary nameserver will be called ns2.hasselltech.net at IP address 192.168.0.6.)
Open the DNS Management MMC snap-in.
Choose Secondary to create a secondary lookup zone, which will indicate to Windows that this should be a secondary nameserver. Click Next.
Enter the name of an existing zone on the Zone Name screen, and click Next.
Specify the nameservers from which Windows can fetch the existing zone files. Simply enter the primary nameserver in the box, click Add, and then click Next, as shown in Figure 4-10.
Click Finish to create the zone.
Perhaps you decide, upon acquiring a new business into your organization, that you need more horsepower in responding to DNS queries. Or, perhaps eventually you’d like to cluster your DNS servers. In these cases, you would want to promote some secondary nameservers to primary status. It’s an easy process to promote an existing secondary nameserver to a primary nameserver.
Open the DNS Management snap-in.
Right-click the zone folder that you want to convert, and select Properties from the context menu.
Navigate to the General tab, as shown in Figure 4-11.
To the right of the Type entry—it should now say either Primary or Secondary—click the Change button. The Change Zone Type screen will appear, as shown in Figure 4-12.
Click the “Primary zone” radio button to perform the promotion.
The server will now be a primary server for that zone.
All zone files are stored in %SystemRoot%\system32\dns. The files are stored in the format <
domain>.dns (e.g., hasselltech.net.dns). You can edit them with your favorite text editor or with a script that you can write to perform large-scale and/or automated machine rollouts.
When you directly edit zone files, make sure you manually increment the serial number value in the zone’s SOA record. You can increment by any value. Otherwise, the changes are likely to be missed by any secondary nameservers during a zone transfer.
For obvious reasons, you’ll find it necessary to control which machines can perform a zone transfer from nameservers—after all, users at large on the Internet have no legitimate need to retrieve a full copy of your zones, and having a full record of your connected machines is a rather significant security breach. In Longhorn Server, this process is locked down by default. To verify this, open the DNS Management snap-in and expand the nameserver’s name. Find a zone under Forward Lookup Zones, right-click it, and choose Properties. Click over to the Zone Transfers tab. You’ll see the screen depicted in Figure 4-13.
You see that you can disallow zone transfers wholesale by unchecking the box labeled “Allow zone transfers.” However, if you choose to enable them to have secondary nameservers, you can lock down the access to those zone files a bit more granularly. The first option, “To any server,” leaves the transfer process wide open. The second option, “Only to servers listed on the Name Servers tab,” seems to be the most reasonable option by restricting transfer to the servers identified as authoritative for the domain on that tab. The third option, “Only to the following servers,” can lock down that list even further. Simply select the option, enter an IP address into the box, and click Add when you’re done. Make the list as long or short as it needs to be, and then finish the process by clicking OK.
Windows Server 2008 also supports a feature listed in RFC 1996 known as zone modification notification, which nearly contradicts what I wrote earlier about the zone transfer process being primarily a pull, rather than a push, process. Click the Notify button on the Zone Transfer tab to explore this feature; you’ll be greeted with the screen in Figure 4-14.
The notification feature will contact the servers listed on this Notify screen when changes are made to the zone file on the primary nameserver. You can have the server contact the authoritative nameservers for a zone or domain as listed on the Name Servers tab, or contact only the servers in the list that you create on this screen. (To create this list, simply enter an IP address and click Add. Repeat as necessary to build the list.) Click OK when you’ve configured or disabled this feature as you wish.
It’s rare to find an organization running its own DNS that is small enough to not take advantage of subdomains and delegation. By delegation, I mean letting one group, whether logical or physical, administer a section of an organization’s network. Let’s take a look at an example.
Perhaps my company has two offices: one in Boston and the other in Charlotte, North Carolina. Although I have an overarching domain name, mycompany.com, I might want to delineate these two locations within my network—I can call all machines in Boston with the north.mycompany.com domain suffix and all machines in Charlotte with the south.mycompany.com domain suffix. Because the respective IT groups at each location have a better sense of which machines are going in and out of the network at their own offices than a central group of administrators at the headquarters site, the decision was made to let each office’s group administer DNS within each subdomain. To make this happen, there are three steps to follow: first, the overarching domain’s DNS zone needs to be told there will be a subdomain that will be administered elsewhere. Second, the overarching (in technical terms, the “root” but not the ultimate TLD-root) nameserver needs the address of the subdomain’s nameserver for its records. And finally, the subdomain’s nameserver needs to be installed and configured.
Inside the DNS Management snap-in, right-click the zone that is the parent of the subdomain you want to create (e.g., mycompany.com), and select New Delegation from the pop-up menu. The New Delegation Wizard appears; click past the introductory screen to the Delegated Domain Name Screen. Here, simply enter the subdomain you want to create and delegate in the top box. The bottom box will expand to show the full domain name of what you entered. Click Next to move on. On the next screen, enter the name of the subdomain you’d like to delegate, and click Next.
The Name Servers screen appears, as shown in Figure 4-15.
On this page, insert the fully qualified domain name and IP address of the nameservers that will be responsible for the new domain. Just click Add to enter these on the New Resource Record screen that will appear. When you’re finished, click OK, and then click Next. Click Finish to complete the wizard. The newly delegated domain will appear in the DNS Management snap-in, but it will be grayed out to indicate its delegated status.
How does this process modify the actual zone files within the DNS service? For one, it adds new NS records to the parent domain to indicate the server responsible for a particular subdomain. For example, if I were delegating the fully qualified subdomain north.mycompany.com with a nameserver at dns1.north.mycompany.com, the resulting record would look like this:
north NS dns1.north.mycompany.com
Next, the delegation wizard adds an A record to the parent zone so that it can find the new nameserver via its IP address, like this:
dns1.north A 192.168.1.105
This A record is known as a glue record because it is the only way DNS and requesting clients would know the IP address of the delegated nameserver—after all, the primary zone no longer holds information on and controls that zone. The A record eliminates that problem and provides a direct way to get in touch with that delegated nameserver.
Logically, creating the subdomain you’ve just delegated is very simple. From the delegated server, inside the DNS Management snap-in, you can right-click the Forward Lookup Zones folder and choose New Zone. From there, just follow the instructions in the “Creating a Forward Lookup Zone” section, earlier in this chapter.
Dynamic DNS is Windows Server 2008’s way of bringing together the one good feature of WINS—automatic machine registration and record updating—with the resiliency and open standards advantage of DNS, a staple of the Internet. With dynamic DNS, machines running Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2008 can register their presence automatically with the nameserver that controls the zone associated with their connection’s DNS suffix. In the case of the examples so far in this chapter, if I have a machine named sales1.north.mycompany.com, this computer would automatically register an A record for that hostname and IP address with the nameserver that controls north.mycompany.com—a handy feature, indeed.
Figure 4-16 shows the actual flow of dynamic DNS registration when a workstation needs to register itself.
The process works a bit different when IP addresses are assigned by a Windows DHCP server. The client, when it receives its IP address from the DHCP server, only registers an A record in the nameserver’s forward lookup zone. The DHCP server by default is responsible for registering the PTR records in the nameserver’s reverse lookup zone, if one exists.
If you want to alter this behavior, you can configure the DHCP server to take care of both parts of the registration by looking on the properties sheet for the DHCP scope in question within the DHCP snap-in.
Open the DHCP snap-in, expand your machine in the left pane, and then click Scopes. In the right pane, select the scope you want to alter and then right-click it and select Properties. Now, navigate to the DNS tab and select Always Update DNS. The DHCP server will register A records in the forward lookup zone and PTR records in the reverse lookup zone for all clients leasing an address.
When does this registration take place? Five possible actions will trigger a DNS registration on the part of the client:
The computer has been restarted.
The computer’s DHCP lease, if the machine uses a dynamic IP address, has just been renewed.
The computer’s statically assigned IP address has been changed.
A full 24 hours have passed since the last DNS registration on record.
An administrator issues the
ipconfig /registerdns command from the command line.
Although the default period for reregistering DNS dynamically is 24 hours, you can change this value inside the Registry on the client. On the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters key, add a new REG_DWORD entry called
DefaultRegistrationRefreshInterval, and give it a value in seconds. (For reference, there are 86,400 seconds in a day.)
Obviously, with multiple machines registering DNS information periodically throughout the day, you need to clean up that information when it expires. The Windows Server 2008 DNS scavenging process finds the dynamically registered records that haven’t been updated for some time, and then simply deletes them to ensure that after a delay for propagation between servers, the zone information contains the most up-to-date data on the machines and addresses therein.
Let’s take a look at how scavenging is presented in the user interface and how you can best control it. To control scavenging for all zones on a particular nameserver, right-click the server’s name from the DNS Management snap-in and select Set Aging/Scavenging for All Zones. The Server Aging/Scavenging Properties screen appears, as shown in Figure 4-17.
At the top of the screen, you see the master switch to enable or disable scavenging. Additionally, you see two options. One of them is for the no-refresh interval, which is simply the time a dynamically registered record should be allowed to stay registered in a “read-only” fashion before the scavenger can take a look at it. This means client computers cannot reregister themselves during this period. The other option is for the refresh interval, which is the amount of time a record should remain and be allowed to be refreshed after the no-refresh interval has passed before the scavenger should remove it. In essence, the scavenger process is not allowed to touch a record unless both the no-refresh and the refresh intervals have passed in full.
To enable scavenging, check the top checkbox and click OK. If you have Active Directory-integrated zones, you’ll be asked to confirm your choice for those as well. Click OK once again, and scavenging will be enabled. Another step remains—you need to enable scavenging on the nameserver, which you can do by right-clicking the server name inside DNS Management, selecting Properties, and clicking the Advanced tab. This is shown in Figure 4-18.
At the bottom of the screen, check the checkbox labeled “Enable automatic scavenging of stale records,” and then enter a period of time after which the scavenger can automatically engage.
If you want to control scavenging and its associated intervals for an individual zone, right-click the zone inside DNS Management and select Properties. Then, navigate to the General tab and click the Aging button. The screen is identical to the server-wide scavenging control screen shown in Figure 4-17.
For the scavenging service to do the mathematics required to calculate these intervals, the DNS service adds a nonstandard bit of information to a resource record’s zone information. For instance, an A record on a server or zone with scavenging enabled might look like this:
colossus [AGE:47363030] 36400 192.168.0.5
The AGE portion is the inception point of the record, measured in some small interval since a certain date. How that number is determined is unimportant; what matters is that with scavenging enabled, the AGE information is added to a DNS record so that the no-refresh and refresh intervals can be honored correctly. You can see that timestamp in a human-readable format by right-clicking any record in the DNS Management snap-in and selecting Properties. The Record timestamp field will show the date and time the record was created in DNS, as shown in Figure 4-19.
To view the record timestamp, select Advanced from the View menu of the console.
If your organization hasn’t deployed Active Directory yet, the dynamic DNS registration default settings that modern Windows client operating systems have can be aggravating to IT groups—your nameservers will be pelted, sometimes forcefully, with registration attempts from Windows systems that believe that for an Active Directory in your organization, they need to register themselves. Of course, that’s not necessarily true, but it’s the default behavior.
Fortunately, you can turn this off, either through a Registry change (to make the modification on a larger scale) or through the GUI. To do so through the GUI, follow these steps:
Open the connection’s properties.
On the Network tab, select TCP/IP, and then click the Properties button.
Navigate to the DNS tab.
Uncheck “Register this connection’s addresses in DNS.”
To do so through the Registry, open the Registry Editor, and then take the following steps:
Navigate through HKEY_LOCAL_MACHINE\CurrentControlSet\Services\TcpIp.
Click the Parameters key.
Add a new value, of type
Set the value of the new entry to 1.
Alternatively, you can type the following at the command line:
reg add hklm\system\currentcontrolset\services\tcpip\parameters /v DisableDynamicUpdate /t REG_DWORD /d 1 /f
You also can use Group Policy (GP) to deploy a policy that disables this to all machines in a domain, or to a subset of those machines, but GP in this case necessitates Active Directory. In any case, the proper object is under Computer Configuration/Administrative Templates/Network/DNS client. The object is called Dynamic Update, and to turn it off, change the state to Disabled. Chapter 6 covers GP in more detail.
Up to this point, I’ve treated the Windows Server 2008 DNS service as a traditional nameserver, mostly compliant with the relevant RFCs, which can act in both primary and secondary “modes” for a zone. However, Windows Server 2008 offers a third mode specific to Windows that, although not listed in an RFC, offers some distinct advantages if you’ve made an infrastructure investment in Active Directory and Windows.
The third mode, Active Directory-integrated DNS, offers two pluses over traditional zones. For one, the fault tolerance built into Active Directory eliminates the need for primary and secondary nameservers. Effectively, all nameservers using Active Directory-integrated zones are primary nameservers. This has a huge advantage for the use of dynamic DNS as well: namely, the wide availability of nameservers that can accept registrations. Recall that domain controllers and workstations register their locations and availability to the DNS zone using dynamic DNS. In a traditional DNS setup, only one type of nameserver can accept these registrations—the primary server, because it has the only read/write copy of a zone. By creating an Active Directory-integrated zone, all Windows Server 2008 nameservers that store their zone data in Active Directory can accept a dynamic registration, and the change will be propagated using Active Directory multimaster replication, something you’ll learn about in Chapter 5. All you need to do to set up this scenario is install Windows Server 2008 on a machine, configure it as a domain controller, install the DNS service, and set up the zone. It’s all automatic after that. Contrast this with the standard primary-secondary nameserver setup, where the primary server is likely to be very busy handling requests and zone transfers without worrying about the added load of dynamic DNS registrations. Active Directory-integrated zones relieve this load considerably. And to add to the benefits, Active Directory-integrated zones support compression of replication traffic between sites, which also makes it unnecessary to use the old-style “uncompressed” zone transfers.
As you read in the previous section, part of the dynamic DNS functionality provided in Windows Server 2008 is the scavenger process. Recall the no-refresh interval function, which was created to eliminate exorbitant amounts of traffic being passed between domain controllers for each DNS re-registration.
Active Directory-integrated zones also afford a big security advantage, in that they provide the capability to lock down dynamic DNS functionality by restricting the ability of users and computers to register records into the system—only computers that are members of the Active Directory domain that hosts the DNS records can add and update records dynamically to these zones. However, to have an Active Directory-integrated zone, your nameservers must be domain controllers for an Active Directory domain. If other nameservers are used that are not domain controllers, they can act only as traditional secondary nameservers, holding a read-only copy of the zone and replicating via the traditional zone transfer process.
If you’re already running a nameserver that is a domain controller with an active zone in service, it’s easy to convert that to an Active Directory-integrated zone. (And for that matter, it’s easy to revert to a primary or secondary zone—this isn’t a be-all and end-all.) Here’s how to go forward:
Open the DNS Management snap-in.
Right-click the zone folder you want to convert, and select Properties from the context menu.
Navigate to the General tab, as shown in Figure 4-20.
To the right of the Type entry—it should now say either Primary or Secondary—click the Change button. The Change Zone Type screen will appear, as shown in Figure 4-21.
Check the “Store the zone in Active Directory” checkbox.
You’ll note that your options expand once you’ve converted to Active Directory-integrated zones. Go back to the zone’s properties, and on the General tab, note a couple of things:
The Dynamic Updates field now allows Secure Only updates.
You have options for replicating zone changes throughout all domain controllers in Active Directory.
Let’s focus on the latter for a moment.
Windows Server 2008 allows you to tune how Active Directory replicates DNS information to other domain controllers. (While I’ll present AD in all of its glory in Chapter 5, I’ll cover this briefly here.) Click the Change button beside the Replication field on the zone properties, and you’ll be presented with the Change Zone Replication Scope screen, as shown in Figure 4-22.
The default setting is “To all domain controllers in the Active Directory domain,” which instructs Windows to behave exactly as it did in Windows 2000 Server: replicate DNS information to all domain controllers in Active Directory, regardless of whether they’re actually running the DNS service. Obviously, if you have 20 domain controllers in your domain, but only 3 domain controllers that run DNS, this is a lot of replication traffic that is just wasted. On this screen, you can select to replicate the DNS information only to domain controllers running DNS in either the forest or the domain. This is very helpful, and for large organizations, it should cut down on WAN traffic.
Forwarding, in the simplest terms, is the process by which a nameserver passes on requests it cannot answer locally to another server. You can make forwarding work to your advantage so that you effectively combine the resolver caches for many nameservers into one. By doing this, you allow clients to resolve previously retrieved sites from that “mega-cache” before requiring a true refresh lookup of the information from authoritative nameservers on the public Internet.
Here’s how it works. DNS behavior by default is to consult the preferred nameserver first to see whether it has the necessary zone information for which the client is searching. It doesn’t matter to the client if the preferred nameserver has the zone information but isn’t authoritative; having the information is enough for the client, and it takes the returned results and makes the connection. But if the server doesn’t have the zone recorded in its files, it must go upstream, to the public Internet, to ask other nameservers for the zone information that’s needed. This takes time because it adds a delay to the initial resolution while the preferred nameserver is searching the Internet for the answer. However, after the nameserver looks up the information once, it stores it in its cache of resolved names so that the next user looking for the same resolver information doesn’t incur that delay: the preferred nameserver can simply answer out of its cache and return the data nearly instantaneously.
Forwarding takes this cache and expands it to multiple nameservers. Consider an organization with four or five nameservers. Clients likely will have different preferred nameservers, set to one of each of those four or five. So, when one client wants information that’s not in her nameserver’s cache, her preferred nameserver will search it out and return it, and all future users of that particular preferred nameserver will get information for that zone returned out of its cache. But the other users in the organization won’t be able to take advantage of that cached entry because they’re likely using other machines as their preferred nameservers.
A forwarder comes in and adds an extra step to this process: if the preferred nameserver doesn’t have zone information in its cache, it will ask a separate server, known as the forwarder, if it has information on the requested zone. The forwarder is simply another nameserver that looks up zone information on the Internet and stores it in its own cache for easy reference. So, if all nameservers in an organization are configured to ask the same forwarder for cached information if it has some, all of those nameservers are taking advantage of the forwarder’s cache and the near-instantaneous response the forwarder can give to resolution requests. Again, the forwarder acts like a regular nameserver in all respects; it’s just that other nameservers in an organization are configured so that they can use the forwarder’s cache. If, however, the forwarder machine takes too long to respond to a request, the original preferred nameserver can take over and make a request to the Internet itself, so you don’t lose the ability to resolve DNS requests—you’re only making it more efficient. You also can have more than one forwarder for your organization if you’re worried about a single point of failure, but you lose a bit of the advantage because you’re again using more than one cache database.
Now, to set up forwarding:
Open the DNS Management snap-in on the machine you want to set up to forward requests elsewhere.
Right-click the server name and choose Properties from the context menu.
Navigate to the Forwarders tab, and then in the “Selected domain’s forwarder IP address list” field, enter the IP address to which requests should be forwarded. This is shown in Figure 4-23.
Also as shown in Figure 4-23, enter “5” in the “Number of seconds before forward queries time out” field. Five seconds is a standard number that ensures efficient name resolution if the forwarders somehow fail at their task.
Click Apply to complete the process.
Slaving is a logical extension to the forwarding process. Servers slaved to a specific nameserver forward requests to that server and rely entirely on that server for resolution; in plain forwarding, on the other hand, the original nameserver can resolve the request itself after a timeout period by querying the root nameservers. With slaving, the upstream nameserver becomes the proxy through which all slaved nameservers make their requests.
This is useful mainly in situations where you need multiple nameservers within your organization to handle Active Directory- and internal-related tasks, but you want outside requests to stay outside the firewall. You can set up one very secure nameserver and place it outside your firewall and internal network, allowing it to service requests from the inside to the outside and from the outside to certain machines within the network. Then, you can slave the internal machines to the one machine outside the firewall, making them depend entirely on the machine in the hostile environment but keeping that environment out of your internal network and away from the many nameservers you administer locally. Because most firewalls are stateful inspection machines that only allow packets inside the firewall that are in response to communications initiated internally, and because your internal nameservers query only the external nameserver and not the Internet itself, the public has no reason to know that your internal nameservers exist, and no ability to get to them, either.
Open the DNS Management snap-in on the machine you want to set up to slave to another server.
Right-click the server name and choose Properties from the context menu.
Set up forwarding first. Navigate to the Forwarders tab, and then in the “Selected domain’s forwarder IP address list” field, enter the IP address to which requests should be forwarded. This is shown in Figure 4-24.
Also as shown in Figure 4-24, enter “5” in the “Number of seconds before forward queries time out” field. Five seconds is a standard number that ensures efficient name resolution if the forwarders somehow fail at their task.
Now, check the “Do not use recursion for this domain box” at the bottom of the screen. This slaves the server to the forwarders listed in the box above.
Click Apply, and then OK, to complete the process.
There might be occasions, especially when using the split DNS architecture technique that I’ll cover in the next section, where you want to assign certain nameservers to answer queries for specific domains that your users ask for. Conditional forwarding can be useful for many reasons, including increasing the speed of name resolution for clients to effect a structural DNS change in a case of company acquisitions or divestitures.
Conditional forwarding is supported only in Windows Server 2003 and Windows Server 2008.
The Forwarders tab inside the DNS Management snap-in holds multiple lists of domains and their associated forwarders specifically to accommodate the conditional forwarding feature. To set up conditional forwarding, follow these steps:
Open the DNS Management snap-in on the machine you want to set up for conditional forwarding.
Right-click the server name and choose Properties from the context menu.
Navigate to the Forwarders tab, and then click the New button to the right of the DNS domain box.
In the New Forwarder box, enter the name of the DNS domain to configure forwarding for, and then press OK.
Click the new domain within the DNS domain list, and then in the “Selected domain’s forwarder IP address list” field, enter the IP address to which requests should be forwarded. This is shown in Figure 4-25.
In the “Number of seconds before forward queries time out” field, enter “5”.
Leave the “Do not use recursion for this domain box” at the bottom of the screen unchecked because you don’t want to slave your nameserver permanently to a forwarder for only certain domains.
Click Apply, and then OK, to complete the process.
Now that you have a good background on the special DNS techniques you can use, let’s discuss a very common and fairly secure way to deploy DNS within your organization: using the split DNS architecture.
As I’ve briefly mentioned previously in this chapter, the split DNS architecture scenario consists of a set of internal nameservers that are used within the corporate computing environment in daily operations. There are also one or more nameservers facing externally to the Internet that outsiders use to connect to your corporation’s electronic services, but that are separated from the internal nameservers for security purposes. Outsiders who query for information from your external nameservers won’t be able to obtain information on your internal network structure and composition because the external nameserver is completely separate from the internal nameservers that hold this data. The external nameservers hold records only for externally facing servers and not for your entire internal domain. This technique is called the split DNS architecture because DNS information is split between the inside and the outside of an organization.
Split DNS is a great way to deploy Active Directory-compatible DNS services within your organization, but it isn’t the only way to deploy DNS.
Now is the time to introduce a new type of zone, introduced in Windows Server 2003, called the stub zone. Stub zones contain only a subset of the information contained in a regular forward or reverse lookup zone. Specifically, a stub zone contains the SOA record, any pertinent NS records, and the A records for the nameservers that are authoritative for that zone, and nothing more. Stub zones are useful for creating split DNS infrastructures, where internal machines service internal DNS requests and external DNS requests are serviced elsewhere, perhaps at a datacenter or Internet service provider.
Now, how do stub zones and conditional forwarding play into the split DNS architecture? In a couple of ways: for one, you might do business with an organization that occasionally needs to access systems that reside within your corporate firewall, not outside of it. Because the external nameservers have no information on your internal systems, there’s no default way to use split DNS to allow outsiders to resolve canonical names within your firewall. To resolve this, you use stub zones, placed on the internal nameserver of the corporation with whom you’re doing business, which again contain only NS and SOA records of your internal nameservers. That way, when people query for resources that you host, they go to their local nameservers, and their local nameservers see the stub zones placed there about your organization with the proper name and IP address for your nameservers. In essence, any organization that hosts a stub zone for your domain always will know the names and addresses of your nameservers. Best of all, regular zone transfers will make sure the information inside these stub zones is kept up-to-date, but of course you must have permission to conduct these zone transfers.
Conditional forwarding operates very similarly to stub zones, except that where stub zones simply contain information about a foreign domain’s nameservers, conditional forwarding is used on the local nameserver to directly forward requests for information to the foreign nameserver. Unlike stub zones, conditional forwarders don’t automatically update when information changes, so manual intervention is required if you need to change the addresses or names of the foreign nameserver; however, you don’t need any special permissions on the foreign nameserver to use conditional forwarding because no zone transfers are involved. Some overhead is involved with conditional forwarding, however, if you have a large list of names to forward; the server has to check each and every request against this list, and if you have a large load on the server, this can slow down response time considerably for everyone hitting that particular server. For just a few zones, however, conditional forwarding can be the best solution, and it can be done without the foreign DNS hostmaster or administrator knowing or approving.
Both of these techniques are a major part of the split DNS architecture strategy. Let’s take an example corporation—one that intends to use Active Directory and is deploying DNS with that in mind—with a primary and secondary nameserver for the external side of the infrastructure and a second set of primary and secondary nameservers for the internal side. A basic diagram of this infrastructure is shown in Figure 4-26.
Note that the first set of primary and secondary nameservers is outside the corporate firewall, and they take care of any external requests that come for the domain. In fact, the registrar that has the corporation’s domain registration lists these two nameservers as authoritative for that domain. However, the zone files on these servers are static—they list only a few, rarely changing items, which could be web, FTP, and mail servers. This is really all the public needs to know.
There are two points to note about this portion of the scenario:
If your ISP has been providing hosting for your nameservers, there’s no reason it can’t continue doing so. In fact, this is simpler to administer than hosting both sets of nameservers on your own premises.
Now let’s focus on the internal nameservers for this corporation. The primary nameserver on the internal side is configured as the primary nameserver for the internal zone and is instructed to accept dynamic DNS updates from internal workstations and servers. However, these internal servers are blind (at this point) to the fact that outside the firewall, another set of nameservers is holding the same zone name with different records. In addition, the workstations within the business are configured to think of the authoritative nameservers for the domain as the internal servers; this is where they will register themselves via dynamic DNS, and also where they will first look to resolve Internet names.
So, how do internal users resolve names on the Internet if they can’t see the external set of nameservers? It’s easy—the internal primary and secondary nameservers are configured to forward Internet requests to the external primary nameserver. So, if the address being requested by the client isn’t in the internal nameserver’s cache (meaning it hasn’t been requested recently by another client), it will ask the external nameserver for the answer. No zone transfers are involved—it’s just straight forwarding, as I covered earlier in this chapter. But how might external users resolve internal DNS names? The short answer is: they won’t. That’s a security feature. Because the external users know only about the external nameservers, and the external nameservers know only about themselves and not the internal nameservers, there’s no way for the external nameservers to report any information about internal DNS records inside the firewall.
The only problem you might run into is when internal users attempt to access the company’s own resources on the external side of the firewall; to allow this, simply add a static record to the internal nameservers that points to the correct external resource. You don’t introduce any security problems that way because there’s still no “window” for external users to see into your internal structure.
So, in essence, you have a DNS architecture “split” between internal and external nameservers. If you’re looking to reproduce this architecture, the following summarizes the correct procedure:
Create two sets of servers—one for in front of the firewall, and one for behind it. Install the DNS service on both.
Make every nameserver point to itself for its own DNS information; you do this within the network card properties where you indicate the IP address. There’s no need to configure a secondary nameserver for each of these.
Copy any external records your internal users might need to the internal zone. This includes web, mail, and FTP servers. Remember, if you don’t do this, your users won’t be able to resolve the names of anything outside the firewall.
Configure external forwarders—these are the machines to which your internal nameservers will forward requests so that your internal users can resolve Internet names.
Slave the internal set of nameservers to these external forwarders you created in the previous step. This shields them from the Internet’s blinding eye.
Configure all machines on the internal network to use only the internal nameservers. This allows them to register with Active Directory if appropriate and to find internal resources, which they couldn’t find if directed to the external nameservers outside the firewall.
Split DNS architecture is implemented with security in mind, but you can always take more steps to harden those DNS systems. You’ve already taken two steps in this process: for one, slaving the internal nameservers to the external forwarders eliminates the possibility that if the firewall of some other transmission problem prevents the external forwarder from responding, the internal nameserver will conduct its own search of the Internet. You obviously don’t want your internal nameservers touching anything on the outside of the firewall except those external forwarders.
The other step is the use of the firewall to separate the two sets of nameservers from each other. You need to ensure that the firewall that protects the perimeter of your corporate network from the Internet is configured correctly and locked down as tightly as possible. I recommend Building Internet Firewalls, Second Edition (O’Reilly), by Zwicky et al., for detailed and thorough guidance on this topic. You’ll especially want to ensure that only a few ports—such as the DNS port, 53—are open.
Other than that, this architecture is fairly secure right after implementation.
If you thought configuring DNS in the first place was difficult, you’ll find the backup and recovery procedures refreshingly simple. There are two locations in the Registry to back up the DNS service and one directory on the physical filesystem.
To back up a server that’s hosting one or more primary or secondary DNS zones, follow these steps:
On the nameserver, stop the DNS service using the Services applet in the Control Panel or through the command line.
Open the Registry Editor (select Start/Run, type
regedit, and press Enter).
Navigate to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS key.
Right-click the DNS folder, and from the context menu, choose Export.
When prompted for a filename, enter
DNS-CCS, and choose an appropriate location that is off the server.
Now, navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS server key.
Right-click the DNS Server folder, and from the context menu, choose Export.
Name this file
DNS-CV, and again choose a location that is not on the current server. These two files will be DNS-CCS.REG and DNS-CV.REG.
Now, using Windows Explorer, navigate to the %SystemRoot%\System32\dns directory on the boot drive.
Find all files with the .DNS extension, select them, and then copy them to the same location that you exported DNS-CCS.REG and DNS-CV.REG.
Your DNS service is now completely backed up. Restart the DNS service to continue using it.
To restore a set of DNS configuration files, install a Windows Server 2008 machine and use the same computer name, DNS suffix, and IP address. Be sure to install the DNS service. Then copy all of the .DNS files from your backup to the %SystemRoot%\System32\dns directory, and stop the DNS service. Double-click DNS-CCS.REG and confirm that you want its contents imported into the Registry; do the same for DNS-CV.REG. Finally, restart the DNS service, and your replacement server should function normally.
The Windows Server 2008 Support Tools collection, described earlier in the book, contains the DNSCmd utility, which is a great way to access some command DNS configuration-related functions through the power and speed of the command prompt. To get to DNSCmd, look in the Support\Tools directory on the Windows Server 2008 distribution CD for the file support.cab. Inside, copy and paste DNSCmd to a convenient location.
DNSCmd displays and changes the properties of DNS servers, zones, and resource records. Some operations of this tool work at the DNS server level while others work at the zone level. You can use DNSCmd on any Windows 2000 or XP computer, as long as the user that is running the application is a member in the Administrators or Server Operators group on the target computer. Both the user account and the server computer must be members of the same domain or reside within trusted domains.
DNSCmd can be used in any of the following situations, in which you want to:
Retrieve information about a DNS server
Begin the scavenging process
View information and contents of a DNS zone
Create, remove, or “pause” zones
Change the properties of a zone
Add, delete, and enumerate records in a zone
You use DNSCmd simply by specifying attributes and their values as part of a command. For example, to create a new standard primary zone called corp.hasselltech.local on a server named dc1.corp.hasselltech.local and stored in corp.hasselltech.local.dns files, use the following syntax:
dnscmd dc1.corp.hasselltech.local /ZoneAdd corp.hasselltech.local /Primary /file corp.hasselltech.local.dns
I could have also chosen to make corp.hasselltech.local a secondary zone by replacing the
/Primary switch with
To create a new A record, I could issue the following command, which adds a record for a machine named www to the zone with an IP address of 192.168.1.23 to the same DNS server as in the previous example:
Dnscmd dc1.corp.hasselltech.local /RecordAdd corp.hasselltech.local www A 192.168.1.23
You can see all of the zones on a target server by entering the following command:
dnscmd dc1.corp.hasselltech.local /enumzones
If you’re experiencing some problems with replication and want to trigger the process manually, you can start it with the following command (assuming you want to use the same server to begin the process as in the previous examples):
Dnscmd dc1.corp.hasselltech.local /ZoneRefresh corp.hasselltech.local
Likewise, you might find yourself needing to manually age all of the records on a particular machine. You can easily do so through DNSCmd using the following:
dnscmd corp.hasselltech.local /ageallrecords dc1.corp.hasselltech.local
You’ll need to confirm your choice, and then the current time will be applied to all records on that machine.
You might also need to clear the DNS cache on a target server, which can be done using this command:
Dnscmd dc1.corp.hasselltech.local /clearcache
To quickly stop and start the DNS process on the target computer, use the following command:
Dnscmd dc1.corp.hasselltech.local /restart
If you want to export a particular zone to a file, you can issue the following command:
dnscmd /zoneexport corp.hasselltech.local corp.hasselltech.local.dns
And finally, to delete a zone from a target server, use the following command:
dnscmd dc1.corp.hasselltech.local /zonedelete corp.hasselltech.local
DNSLint is also on the distribution CD in support tools. DNSLint is a utility born out of the desire to automate the process of troubleshooting lame delegation issues and problems with AD replication because of faulty DNS records. DNSLint is a great tool to make sure that every DNS server that has records on your services has correct records and that there are no issues with those DNS servers’ data. (And in case you’re wondering, the name DNSLint comes from the idea that lint is something you find in your blue jeans after they come out of the dryer. When you find lint, it is useless and perhaps even embarrassing, meaning you probably quickly discard it. You should do the same with outdated or inaccurate DNS records for critical machines on your network.)
The best thing to do from the start is to create a standard report on any given DNS domain, using the following:
dnslint /d hasselltech.local /v
DNSLint produces an HTML-based report and then starts Internet Explorer to display the result. The results are color-coded with warnings in amber and errors in red for easy scanning. (You can elect to get a text-based report, if you prefer.) The report generated by the previous command will show a detailed listing of each DNS server for the corp.hasselltech.local domain and indicate whether the server responds to a query on port 53, which is the standard DNS port. It will tell you how it found each server, and it will also list each server that reports authoritatively. You will also see Mail Exchanger records in the zone, which is useful for troubleshooting SMTP routing problems.
If you are specifically having email difficulties, you can use DNSLint to determine whether a designated email server listens on the correct port. Use the following command:
dnslint /d domainname.tld /c
The report generated by that command lists whether a server indicated in an MX record is listening for SMTP, POP3, and IMAP4 requests, and will also show the SMTP header returned by the server to help in diagnostics.
To assist in troubleshooting, the following functions are available in DNSLint:
dnslint /d domainname
This diagnoses potential causes of “lame delegation,” covered earlier in this chapter, and other related DNS problems. You’ll receive an HTML-based report once the checking diagnosis is complete. Add
/v for more information about how the DNS servers listed in the report were found. If you get errors saying that the domain specified is not listed with InterNIC, simply add the
dnslint /ql mylist.txt
This verifies a user-defined set of DNS records on multiple DNS servers. You can specify in a simple text file the sets of records you’d like to test. For example, the following tests A, PTR, CNAME, and MX records for the domain name and IP address of a fairly well-known company:
microsoft.com,a,r ;A record 184.108.40.206,ptr,r ;PTR record microsoft.com,cname,r ;CNAME record microsoft.com,mx,r ;MX record
dnslint /ad localhost
This verifies the DNS records on a specific host (in this case, the current machine) specifically used for Active Directory replication. If you get errors saying that the domain specified is not listed with InterNIC, simply add the
In this chapter, you saw how DNS is crucial to network communications among machines, and particularly to those who participate in Windows domains. DNS is such a core component of Active Directory that it was important to learn about it in depth before introducing Active Directory itself. In the next chapter, I’ll look at how Active Directory works and how it relies on DNS as its foundation.