altiris software key

Windows Server 2008: The Definitive Guide
by Jonathan Hassell
Copyright © 2008 Jonathan Hassell. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions
are also available for most titles (safari.oreilly.com). For more information, contact our
corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com.
Editor: John Osborn
Production Editor: Rachel Monaghan
Copyeditor: Colleen Gorman
Proofreader: Rachel Monaghan
Indexer: Lucie Haskins
Cover Designer: Karen Montgomery
Interior Designer: David Futato
Illustrator: Jessamyn Read
Printing History:
March 2008: First Edition.
Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of
O’Reilly Media, Inc. Windows Server 2008: The Definitive Guide, the image of an albatross, and related
trade dress are trademarks of O’Reilly Media, Inc.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as
trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a
trademark claim, the designations have been printed in caps or initial caps.
While every precaution has been taken in the preparation of this book, the publisher and author assume
no responsibility for errors or omissions, or for damages resulting from the use of the information
contained herein.
This book uses RepKover™, a durable and flexible lay-flat binding.
ISBN: 978-0-596-51411-2
[M]
This excerpt is protected by copyright law. It is your
responsibility to obtain permissions necessary for any
proposed use of this material. Please direct your
inquiries to permissions@oreilly.com.
97
Chapter 4 CHAPTER 4
Domain Name System4
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
IPaddresses 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.
Nuts and Bolts
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 IPaddresses. 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.
98 | Chapter 4: Domain Name System
There are also second-level domains, which are less inclusive and usually take the
form of name.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 secondlevel
domain names beneath top-level domains—hasselltech.net, for example.
DNS resolves names based on zones. Zones contain information on computers, services,
and IPaddresses 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 IPaddresses, 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.
Zones Versus Domains
As you learned in the previous section, a DNS domain in its simplest form is a secondlevel
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
Zones Versus Domains | 99
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 IPaddress 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 Files
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.
Forward and Reverse Lookup Zones
DNS handles forward lookups, which convert names to IPaddresses, and the data is
stored within a forward lookup zone. But DNS also handles reverse lookups, which
convert IPaddresses 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 IPaddresses 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 IPaddress 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 IPaddress. Table 4-1 shows the respective ways to generate a
reverse lookup zone name.
100 | Chapter 4: Domain Name System
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 IPaddresses 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 IPaddresses
specifically from them, it’s probable that your ISPactually 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 IPaddress block of typical ISPs. This can be a real problem,
but your ISPusually 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 IPaddress, 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.
Resource Records
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.
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.
Resource Records | 101
Host (A) Records
Host records, or A records, simply map a hostname to an IPaddress. You generally
create host records for each machine in your network.
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 roundrobin
DNS. Round-robin DNS involves entering multiple A records, all configured
with the same hostname, but with different IPaddresses 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 IPaddresses mentioned earlier.
Now, when client computers come to the nameserver and ask for the IPaddress 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 XPclients 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:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Dnscache\Parameters
Change the 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 IPaddress
192.168.0.51, and another A record set up for the same hostname on IPaddress
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.
102 | Chapter 4: Domain Name System
Some advantages to round-robin DNS balancing include the following:
• 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.
Canonical Name (CNAME) Records
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 IPaddress but
listening to several different hostnames—www.hasselltech.net, ftp.hasselltech.net,
and mail.hasselltech.net all might be on one IPaddress, 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 IPaddress, not for multiple
IPaddresses to one name. Note that these names are zone-dependent, not serverdependent.
Sometimes Windows will refer to CNAME records as aliases, in a confusing
mix of technical accuracy and common parlance.
A sample CNAME record in zone file format looks like this:
ftp CNAME colossus.hasselltech.net
Resource Records | 103
Mail Exchanger (MX) Records
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:
• Hasselltech.net, MX preference 10, to mail.hasselltech.net
• Hasselltech.net, MX preference 100, to queue.perigee.net
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 roundrobin
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
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.
104 | Chapter 4: Domain Name System
Start of Authority (SOA) Records
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.
There are three important intervals to discuss at this point when it comes to SOA
records:
Refresh interval
The refresh interval indicates to secondary nameservers how long they can keep
their copies of the primary nameserver’s zones before being required to request a
refresh of the zone.
Retry interval
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.
Minimum (default) TTL
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
Pointer (PTR) Records
Pointer (PTR) records work very similarly to A records, except they perform the
function in reverse—PTR records point IP addresses to hostnames and reside in
reverse lookup zones.
A sample PTR record in zone file format looks like this:
61.130.98.66.in-addr.arpa. IN PTR alpha.enablehosting.com
Resource Records | 105
Service (SRV) Records
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 TCPor UDPtransmission 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:
_kerberos
To provide user and computer authentications using Kerberos Key Distribution
Center (KDC) servers
_kpasswd
To provide a mechanism for changing Kerberos passwords securely
_ldap
For the Lightweight Directory Access Protocol, the way external programs communicate
and exchange data with Active Directory
_gc
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.
106 | Chapter 4: Domain Name System
Using Primary and Secondary Nameservers
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.
Secondary nameservers are not limited to zone transfers from only a
primary nameserver; they can accept transfers from other secondary
nameservers as well.
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.
Building a Nameserver | 107
Full and Incremental Zone Transfers
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.
Building a Nameserver
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 DHCPreservation.
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
IPaddress 192.168.0.5. You can, of course, replace these as appropriate
when following along with your own computer.
The first step is to install the nameserver software onto your Windows Server 2008
computer. To do so, follow these steps:
1. Open Server Manager.
2. In the left pane, click Roles, and then in the right pane, click Add.
3. Click Next in the Add Roles Wizard.
4. Find DNS Server in the list, check its box, and click Next.
5. Click Next on the “Introduction to DNS Server” screen.
6. Click Install, wait for the process to complete, and then close the Add Server
Roles box.
108 | Chapter 4: Domain Name System
If you have your computer set up to receive an IPaddress via DHCP,
the DNS Server role installation will complain loudly that DNS isn’t
intended to work on dynamically assigned IPaddresses. 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:
1. Inside the Control Panel, double-click the Network Connections applet.
2. Inside the Network Connections dialog box, right-click the name of your network
connection and choose Properties from the context menu.
3. Navigate to the General tab, and then select Internet Protocol (TCP/IP).
4. Click the Properties button.
5. Click the “Use the following DNS server address” radio button, and then enter
the nameserver’s IP address into the box.
6. Click OK.
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.
Building a Nameserver | 109
Enabling Incremental Transfers
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:
1. Open the DNS Management snap-in.
2. Right-click your server and select Properties from the context menu.
3. Navigate to the Advanced tab, and uncheck the box labeled BIND Secondaries.
4. 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.
Figure 4-1. The DNS Management snap-in
110 | Chapter 4: Domain Name System
Creating a Forward Lookup Zone
Now, to further configure your server, let’s create a forward lookup zone file. Inside the
DNS snap-in, expand the server name in the lefthand pane. Then do the following:
1. Right-click Forward Lookup Zones and select New Zone. The New Zone Wizard
appears.
2. Choose Primary Zone, and then click Next.
3. Enter the zone name. In this example, I’ll use hasselltech.net. Click Next to
continue.
4. 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.
5. 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.
6. Click Finish to complete the zone creation process.
The hasselltech.net zone has now been created.
Entering A Records into a Zone
Inside the DNS snap-in, right-click the hasselltech.net node in the lefthand pane and
choose New Host (A) from the context menu. The New Host dialog box appears, as
shown in Figure 4-2.
Enter the hostname of the machine for which you’re entering the record, and then
enter the IPaddress of the machine. As you enter the hostname, the fully qualified
Figure 4-2. Entering a new A record
Building a Nameserver | 111
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.
Controlling Round-Robin Balancing
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.
Figure 4-3. Advanced properties of a DNS server
112 | Chapter 4: Domain Name System
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.
Entering and Editing SOA Records
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:
Serial number
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.
Primary server
This field denotes the primary, authoritative nameserver for this zone.
Figure 4-4. SOA record properties for a zone
Building a Nameserver | 113
Responsible person
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 hostmaster@hasselltech.net, in this field you would
enter hostmaster.hasselltech.net.
Refresh interval
The refresh interval indicates to secondary nameservers how long they can keep
their copies of the zones before being required to request a refresh.
Retry interval
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.
Expires after
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.
Minimum (default) TTL
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.
TTL for this record
This value overrides the minimum (default) TTL as described earlier and is limited
to only this SOA record.
Creating and Editing NS Records
NS records, as you learned earlier in this chapter, link the hostnames of nameservers
to their IPaddresses. 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 IPaddress of the hostname you entered. If you agree
with its finding, click the Add button beside the IPaddress and the NS record will be
entered. Click OK twice to close.
114 | Chapter 4: Domain Name System
Creating and Editing CNAME Records
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.
Creating and Editing MX Records
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.
Figure 4-5. Editing NS records for a zone
Building a Nameserver | 115
Figure 4-6. Entering a new CNAME record
Figure 4-7. Entering a new MX record
116 | Chapter 4: Domain Name System
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.
Generating a Reverse Lookup Zone
You learned earlier in this chapter that reverse lookup zones map IPaddresses 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:
1. Choose “Primary zone,” and click Next.
2. Enter the network numbers for your network in the Network ID field—for
example, 192.168.0.0—and then click Next.
Figure 4-8. Creating a new reverse lookup zone
Building a Nameserver | 117
3. The Dynamic Updates page appears. Select to allow both insecure and secure
updates, and then click Next.
4. Click Finish to complete the wizard.
Your reverse lookup zone has been created.
Creating and Editing PTR Records
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.
Configuring a Secondary Nameserver
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.
Figure 4-9. Entering a new PTR record
118 | Chapter 4: Domain Name System
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.)
To proceed:
1. Open the DNS Management MMC snap-in.
2. Right-click Forward Lookup Zones and select New Zone from the context
menu. The New Zone Wizard will appear; click Next to skip the introductory
screen.
3. Choose Secondary to create a secondary lookup zone, which will indicate to
Windows that this should be a secondary nameserver. Click Next.
4. Enter the name of an existing zone on the Zone Name screen, and click Next.
5. 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.
6. Click Finish to create the zone.
Figure 4-10. Specifying a primary DNS server for a secondary DNS zone
Building a Nameserver | 119
Upgrading a Secondary Nameserver to Primary
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.
1. Open the DNS Management snap-in.
2. Right-click the zone folder that you want to convert, and select Properties from
the context menu.
3. Navigate to the General tab, as shown in Figure 4-11.
4. 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.
5. Click the “Primary zone” radio button to perform the promotion.
6. Click OK.
The server will now be a primary server for that zone.
Figure 4-11. Promoting a DNS server
120 | Chapter 4: Domain Name System
Manually Editing Zone Files
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.
Controlling the Zone Transfer Process
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 snapin
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.
Figure 4-12. Changing a server from primary to secondary
Building a Nameserver | 121
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 IPaddress
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 IPaddress and click Add. Repeat as necessary
to build the list.) Click OK when you’ve configured or disabled this feature as
you wish.
Figure 4-13. Controlling zone transfers
122 | Chapter 4: Domain Name System
Subdomains and Delegation
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.
Figure 4-14. Notify dialog screen
Subdomains and Delegation | 123
Delegating a Domain
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 IPaddress 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
Figure 4-15. Identifying delegated nameservers
124 | Chapter 4: Domain Name System
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 IPaddress 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.
Creating the Subdomain
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
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 IPaddress
with the nameserver that controls north.mycompany.com—a handy feature, indeed.
When Delegation Goes Lame
Lame delegation is the condition when an NS record points to an incorrect machine.
This can be caused when a zone is delegated to a server that has not been properly configured
as an authoritative nameserver for that zone, or an authoritative nameserver for
a zone has an NS record that points to another machine that is not authoritative for the
zone.
When lame delegation occurs, these nameservers direct queries to servers that will not
respond authoritatively, if at all. This causes unnecessary network traffic and extra
work for servers. According to the Domain Health Survey, 25% of all zones have lame
delegations.
I’ll talk about a utility later in this chapter, called DNSLint, that can help you detect
lame delegations and fix them.
Dynamic DNS | 125
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 IPaddresses are assigned by a Windows
DHCPserver. The client, when it receives its IPaddress from the DHCPserver, only
registers an A record in the nameserver’s forward lookup zone. The DHCPserver 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 DHCPserver
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 DHCPsnap-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 DHCPserver 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 DHCPlease, if the machine uses a dynamic IPaddress, 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.
Figure 4-16. The flow of dynamic DNS registration
Client
Find authoritative server
Result (zone name and authoritative server’s name and IP address)
Attempt dynamic update
Result (success or failure)
Local name
server
Server that is
authoritative
for name
126 | Chapter 4: Domain Name System
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.)
Scavenging
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.
Figure 4-17. Setting dynamic DNS scavenging
Dynamic DNS | 127
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.
Figure 4-18. Setting up scavenging on the server
128 | Chapter 4: Domain Name System
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.
Preventing Dynamic DNS Registration
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:
1. Open the connection’s properties.
2. On the Network tab, select TCP/IP, and then click the Properties button.
3. Navigate to the DNS tab.
4. Uncheck “Register this connection’s addresses in DNS.”
5. Click OK.
Dynamic DNS | 129
To do so through the Registry, open the Registry Editor, and then take the following
steps:
1. Navigate through HKEY_LOCAL_MACHINE\CurrentControlSet\Services\TcpIp.
2. Click the Parameters key.
3. Add a new value, of type REG_DWORD, called DisableDynamicUpdate.
4. 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 GPin 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.
Figure 4-19. Viewing a record’s timestamp in the GUI
130 | Chapter 4: Domain Name System
Active Directory-Integrated Zones
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 Directoryintegrated
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.
Active Directory-Integrated Zones | 131
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:
1. Open the DNS Management snap-in.
2. Right-click the zone folder you want to convert, and select Properties from the
context menu.
3. Navigate to the General tab, as shown in Figure 4-20.
4. 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.
5. Check the “Store the zone in Active Directory” checkbox.
6. Click OK.
Figure 4-20. Converting a zone to Active Directory-integrated mode
132 | Chapter 4: Domain Name System
You’ll note that your options expand once you’ve converted to Active Directoryintegrated
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.
Replication Among Domain Controllers
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.
Figure 4-21. Storing a zone in Active Directory
Forwarding | 133
Forwarding
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
Figure 4-22. Controlling DNS replication in Active Directory
134 | Chapter 4: Domain Name System
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:
1. Open the DNS Management snap-in on the machine you want to set up to forward
requests elsewhere.
2. Right-click the server name and choose Properties from the context menu.
3. Navigate to the Forwarders tab, and then in the “Selected domain’s forwarder IP
address list” field, enter the IPaddress to which requests should be forwarded.
This is shown in Figure 4-23.
4. 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.
5. Click Apply to complete the process.
Slaving
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.
Forwarding | 135
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.
Figure 4-23. Setting up a forwarding DNS system
136 | Chapter 4: Domain Name System
Setting up slaving, as opposed to forwarding, involves only one extra checkbox. To
enable slaving, follow these steps:
1. Open the DNS Management snap-in on the machine you want to set up to slave
to another server.
2. Right-click the server name and choose Properties from the context menu.
3. Set up forwarding first. Navigate to the Forwarders tab, and then in the
“Selected domain’s forwarder IPaddress list” field, enter the IPaddress to which
requests should be forwarded. This is shown in Figure 4-24.
4. 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.
5. 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.
6. Click Apply, and then OK, to complete the process.
Conditional Forwarding
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.
Figure 4-24. Setting up a slaved DNS system
The Split DNS Architecture | 137
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:
1. Open the DNS Management snap-in on the machine you want to set up for conditional
forwarding.
2. Right-click the server name and choose Properties from the context menu.
3. Navigate to the Forwarders tab, and then click the New button to the right of
the DNS domain box.
4. In the New Forwarder box, enter the name of the DNS domain to configure forwarding
for, and then press OK.
5. Click the new domain within the DNS domain list, and then in the “Selected
domain’s forwarder IPaddress list” field, enter the IPaddress to which requests
should be forwarded. This is shown in Figure 4-25.
6. In the “Number of seconds before forward queries time out” field, enter “5”.
7. 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.
8. Click Apply, and then OK, to complete the process.
The Split DNS Architecture
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.
138 | Chapter 4: Domain Name System
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.
Stub Zones
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.
Figure 4-25. Setting up a conditionally forwarded DNS system
The Split DNS Architecture | 139
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 IPaddress 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.
140 | Chapter 4: Domain Name System
There are two points to note about this portion of the scenario:
• The external nameservers are not authoritative for the internal, Active Directorybased
DNS structure. They are authoritative only for external, Internet-based
requests.
• If your ISPhas 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
Figure 4-26. How split DNS architecture is laid out
Internet
External
DNS Server
Internal
DNS Server
Firewall
Desktop
Users
Web site on DMZ
External requests from the
outside get forwarded to the
public web site on the DMZ.
External requests from the inside do not use the external DNS server.
The Split DNS Architecture | 141
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:
1. Create two sets of servers—one for in front of the firewall, and one for behind it.
Install the DNS service on both.
2. Make every nameserver point to itself for its own DNS information; you do this
within the network card properties where you indicate the IPaddress. There’s no
need to configure a secondary nameserver for each of these.
3. Copy any external records your internal users might need to the internal zone.
This includes web, mail, and FTPservers. Remember, if you don’t do this, your
users won’t be able to resolve the names of anything outside the firewall.
4. Configure external forwarders—these are the machines to which your internal
nameservers will forward requests so that your internal users can resolve Internet
names.
5. 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.
6. 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.
Security Considerations
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.
142 | Chapter 4: Domain Name System
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.
Backup and Recovery
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.
The following procedure won’t work with Active Directory-integrated
zones, as the zone files are within the directory service and are not
available on the filesystem.
To back up a server that’s hosting one or more primary or secondary DNS zones, follow
these steps:
1. On the nameserver, stop the DNS service using the Services applet in the Control
Panel or through the command line.
2. Open the Registry Editor (select Start/Run, type regedit, and press Enter).
3. Navigate to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
DNS key.
4. Right-click the DNS folder, and from the context menu, choose Export.
5. When prompted for a filename, enter DNS-CCS, and choose an appropriate location
that is off the server.
6. Now, navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\DNS server key.
7. Right-click the DNS Server folder, and from the context menu, choose Export.
8. 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.
9. Now, using Windows Explorer, navigate to the %SystemRoot%\System32\dns
directory on the boot drive.
10. 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.
Command-Line Utilities | 143
To restore a set of DNS configuration files, install a Windows Server 2008 machine
and use the same computer name, DNS suffix, and IPaddress. 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.
If you want to move only the primary role for a particular zone from
one nameserver to another, simply copy the .DNS file for that zone to
the target computer. Run the New Zone Wizard as described earlier in
this chapter, and then instruct it to use a pre-existing zone file.
Command-Line Utilities
In this section, I’ll describe some useful programs designed to run from a command
line that you can use to automate your DNS setup and configuration processes.
DNSCmd
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 XPcomputer, 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
144 | Chapter 4: Domain Name System
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 /Secondary.
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 IPaddress 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
Command-Line Utilities | 145
DNSLint
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 SMTProuting
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 /s option.
146 | Chapter 4: Domain Name System
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
207.46.197.100,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 /s
option.
The Last Word
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.