The Best Damn Windows Server 2003 Book Period- P75 pdf

DNS console, DNS debug logging, DNS event logging, and DNS Performance Monitor counters,
as well as command-line tools such as NSLookup.exe, Dnscmd.exe, and DNSLint.exe. In this sec-
tion, we will briefly cover the use of these tools to monitor a DNS server environment.
Testing DNS Server Configuration
with the DNS Console Monitoring Tab
The DNS console provides a simple but effective tool for ensuring that the DNS service is working
properly.To use this tool, click the Monitoring tab of the properties for the DNS server, as shown
in Figure 20.17.
The Monitoring tab allows you to perform a simple and a recursive query test to ensure proper
operation. A simple query test uses the DNS client installed on the DNS server to send a local
query to the DNS server. A recursive query test uses the local DNS client as well. However, in this
case, the DNS client requests that the DNS service use recursion to resolve an NS-type query for
the root zone. Failure of this test usually indicates a problem with network connectivity or incor-
rectly configured root hints. (In the example in Figure 20.17, the recursive query test failed because
the network adapter was unplugged before the test was run, and the DNS server could not connect
to the servers listed in the root hints file.) When a DNS server fails one of these tests, a warning
symbol is displayed on the DNS server in the DNS console. Note that you can set up automatic
simple and recursive query testing in the Monitoring tab.
It is a good practice to use these tests after you have set up a DNS server or have made a con-
figuration change on a current DNS server.
706 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
Figure 20.17 Performing Simple and Recursive Queries Using the Monitoring Tab of the
DNS Server Properties
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 706
Debug Logging
If you need to analyze and monitor the DNS server performance in greater detail, you can use the
optional debug tool that you can enable in the Debug Logging tab of the DNS server property
pages. Because debug logging consumes significant resources, it is not enabled by default and should
be enabled only on a temporary basis, such as when you’re trying to troubleshoot a problem with
DNS. Figure 20.18 shows the configurable properties for DNS debug logging.
As you can see in Figure 20.18, you have a lot of flexibility and control with regard to the fil-

tering of DNS traffic you wish to include in the debug logs.You can choose to log packets based on
the following:
■
Their direction, either outbound or inbound
■
The transport protocol, either TCP or UDP
■
Their contents: queries/transfers, updates, or notifications
■
Their type, either requests or responses
■
Their IP address
Finally, you can choose to include detailed information.
Let’s assume you were trying to troubleshoot a problem with dynamic updates.You could con-
figure the debug utility to log any update packets, but exclude queries/transfers and notifications.
This configuration would exclude information that isn’t relevant to the problem.You could further
refine the information contained in the logs by monitoring for either requests or responses or for
incoming or outgoing packets.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 707
Figure 20.18 Debug Logging Properties
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 707
Depending on the amount of DNS traffic the server processes and the logging options you
select, the log files can grow quite large.You should, therefore, configure logging to occur on a sepa-
rate hard drive. When the log file reaches the maximum size or the hard drive runs out of room,
newer events will overwrite older events.
Event Logging
By default, the DNS service will log all DNS events to the DNS Event log. In Windows Server 2003,
DNS events are kept in a separate system event log that can be accessed from either the DNS console
or Event Viewer.The Event Logging tab on the properties of the DNS server allows you to con-
figure the events you would like to log in the DNS Event log.There are four options on the Event

Logging tab: No events, Errors only, Errors and warnings, and All events.The default is to log
All events, which include informational messages that indicate service startup, a new version number
for a zone file, and so on. On a busy DNS server, the default size of the event log might not be large
enough.You should consider increasing the size of the DNS Event log in this case.
Monitoring DNS Server Using the Performance Console
The Windows Server 2003 Performance console provides a means of monitoring DNS perfor-
mance, either in real time through the System Monitor or as events logged over a period time by
Performance Logs. When the DNS service is installed on Windows Server 2003, more than 60 per-
formance counters are installed for measuring performance of the DNS service. Figure 20.19 shows
some of the DNS performance counters that you can select in System Monitor.
Because the DNS is a critical service, you should log its performance over a period of time
using Performance Logs to establish a baseline for normal operating conditions. Once you’ve estab-
lished a baseline, you can then use this information to predict effects of planned changes to the
infrastructure, such as adding or removing other DNS servers or adding more DNS clients.
708 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
Figure 20.19 DNS Performance Counters
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 708
Performance baselines also help you to optimize services on your network by providing real-world
data about the performance of your servers and your network.
Having a baseline also allows you to detect and troubleshoot problems with your DNS and net-
work infrastructure. For example, if the number of Secure Update Failures suddenly increased,
you might be prompted to investigate further to determine the cause of the problem.
In choosing DNS counters to monitor, you should consider the role(s) of the DNS server:
■
If the DNS server is installed on a domain controller and configured for secure only
updates in Active Directory-integrated zones, you should monitor counters that are rele-
vant to dynamic updater performance and security, such as Secure Update Failure,
Dynamic Update Written to Database/sec, Dynamic Update Received/sec, and
so on.
■

If the DNS server is used to perform recursion on behalf of clients, you should monitor
counters that are relevant to the performance of recursive queries, such as Recursive
Queries/sec or Recursive Query Failures/sec. If you have disabled recursion on your
server, a spike in the number of recursive queries the DNS server receives could warrant
further investigation.
■
If the DNS server replicates zone data with other servers, either as a primary or secondary
server, you should monitor counters relevant to zone transfers, such as AFXR Requests
Received, which would indicate that a number of secondary DNS servers are requesting a
full, rather than incremental, zone transfer. A sudden increase in the number of zone
transfer requests could indicate the presence of an attacker trying to footprint your DNS
records.
Command-line Tools for
Maintaining and Monitoring DNS Servers
Windows Server 2003 provides three command-line utilities for maintaining and monitoring DNS
servers:
■
NSLookup This is a standard tool used for monitoring and troubleshooting DNS
servers. It provides a means to obtain detailed results for queries performed against a DNS
server. NSLookup has two modes: interactive and noninteractive. Interactive mode allows
you enter more than one command at an NSLookup prompt. Noninteractive mode is
invoked as a single command with options from a command prompt. For NSLookup to
work properly, the DNS server that NSLookup is pointing to must have a PTR record for
it in a reverse lookup zone.
■
Dnscmd This utility is found in the \Support\Tools folder on the Windows Server 2003
installation CD.The Dnscmd tool can be used as an alternative to the DNS MMC. With
DNScmd, you can create and delete zones, view records, update zone records, and perform
other administrative tasks that you would normally perform using the DNS console.
Dnscmd can be used to script batch operations and perform remote administration, pro-

viding an efficient way to manage multiple, remote DNS servers.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 709
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 709
■
DNSLint This utility is found in the \Support\Tools folder on the Windows Server
2003 installation CD. DNSLint is new to Windows Server 2003. Its primary purpose is to
assist in troubleshooting problems arising from lame (incorrect) delegations and common
AD DNS problems, such as verifying records for AD replication. A key advantage of the
tool is that it can examine multiple servers in a single operation and display the output as
an HTML file. For example, if you were trying to troubleshoot a problem with delegation,
you would need to traverse the DNS namespace in multiple steps. With DNSLint, you can
diagnose the problem in a single operation.You can also use DNSLint with the /c switch
to test well-known e-mail ports on all e-mail servers that it finds in the zone records of
the DNS servers it checks in the domain.
These tools can be used for a variety of purposes, such as verifying the presence of RRs,
checking for lame delegations, checking for missing AD replication records, configuring DNS server
settings on multiple servers, and so on.
Planning for NetBIOS Name Resolution
In a Windows 2000 or Windows Server 2003 environment, DNS is the primary method for name
resolution. However, even in these environments, NetBIOS name resolution might still be exten-
sively used. For example, if the network consists of older clients, such as Windows NT 4 and
Windows 9x clients, you must still support NetBIOS name resolution.Also, certain applications,
such as Microsoft Exchange Server, still rely on NetBIOS for their functionality. So, even if the
domain is upgraded to AD and all of the clients on the network are upgraded to Windows 2000 or
Windows XP, it might still be necessary to support NetBIOS name resolution.
The primary means for ensuring fault-tolerant and timely NetBIOS name resolution is through
the implementation of WINS.Through its ability to replicate information with other WINS servers,
WINS provides a distributed database that allows NetBIOS clients to register their NetBIOS names
to ensure uniqueness and to resolve NetBIOS-to-IP address mappings consistently throughout the
network infrastructure. Because WINS servers are capable of replicating database information to one

another, this means that multiple WINS servers can provide both fault tolerance and availability of
records for NetBIOS resolution to even very large networks that involve many different sites.
Understanding NETBIOS Naming
NetBIOS names have been used in all past versions of Windows and you are no doubt quite
familiar with NetBIOS names. Recall that a NetBIOS name is a 16-character string that is used to
identify computers, groups, or services on the network.The first 15 characters of the name are con-
figured on the computer by the user or the administrator.The sixteenth and last character of a
NetBIOS name identifies a resource type associated with the NetBIOS-related services that are run-
ning on the computer.
There are two kinds of NetBIOS names:
■
Unique names These names are used to uniquely identify computers and the NetBIOS-
related services running on them.
710 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 710
■
Group names These names are used primarily to support browsing and browser elections.
Collectively, NetBIOS names comprise a flat namespace.This differs from a DNS namespace,
which provides a hierarchical namespace. And, while it is possible to group NetBIOS names
according to a workgroup or domain name for display by the browser service, NetBIOS names must
be unique within the NetBIOS namespace.
NetBIOS Name Resolution Process
In a NetBIOS environment that does not employ LMHOSTS files or WINS servers, NetBIOS is
completely dependent on broadcasts to register names and to resolve NetBIOS names to addresses.
Without the presence of WINS or LMHOSTS files to assist in name resolution, NetBIOS name
resolution would generate considerable broadcast traffic for name resolution, adding to the traffic
generated to support NetBIOS registration and the browser service. Furthermore, since NetBIOS
broadcast traffic normally does not cross routers, it would not be possible to resolve computer names
on remote subnets.
To support NetBIOS name resolution on a segmented network, you can use two methods.The

first relies on the deployment of LMHOSTS.The second relies on the deployment of WINS
servers. A third method, opening routers to forward NetBIOS broadcast traffic, is neither a sensible
nor a viable solution in most instances, with the exception of small networks that must use separate
networks because they are in different physical locations.That said, it is generally recommended that
routers not be configured to forward NetBIOS broadcast traffic and that LMHOSTS files or WINS
servers be used to support NetBIOS name resolution across subnets.
Understanding the LMHOSTS File
LMHOSTS files are a good solution in small environments that have a segmented network. In addi-
tion, they can be useful in situations where you want some computers to communicate with others
across a WAN link, but you do not want to combine the NetBIOS namespace of the offices on either
side of the link. However, in large environments, LMHOSTS files are difficult to maintain. An
LMHOSTS file must be present on each computer that needs it for name resolution.You can create
centralized LMHOSTS files, but the client computers must first have an LMHOSTS file to gain access
to the centralized LMHOSTS files. Also, you must manually enter NetBIOS name-to-IP address map-
pings, increasing the possibility for error. Finally, the use of LMHOSTS files is not possible in an envi-
ronment that uses DHCP to assigned TCP/IP address configurations to client computers.
To support NetBIOS name resolution in a segmented network or one that uses multiple broad-
cast domains, a better approach than LMHOSTS files is to use WINS. If a network has been using
LMHOSTS files extensively, it is relatively easy to migrate to WINS by importing LMHOSTS files
to the database to create static mappings. However, you need to exercise care to ensure that these
mappings can be overwritten by WINS clients that use dynamic mappings.
Understanding WINS
In segmented network environments that use DHCP, the best solution to allow for proper NetBIOS
name resolution is to use WINS servers. A WINS server provides a database that NetBIOS clients
can use to register their NetBIOS names and resolve NetBIOS-to-IP address mappings.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 711
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 711
Furthermore, WINS traffic is unicast-based.This means that, instead of relying on broadcasts to reg-
ister and resolve names, WINS clients will send unicast messages directly to the WINS server,
whether on the same or different subnet.The use of unicast helps to reduce the amount of broadcast

traffic on the network that is the result of NetBIOS name resolution.
The ability for different WINS servers to replicate database information with each other is
another significant advantage in that the replication of this information ensures that clients can
resolve NetBIOS names regardless of their location or the WINS server they contact.
When a NetBIOS registration is successful, the WINS server stores the name mapping with the
following information:
■
Record Name The NetBIOS name of the computer, group, or service registered in the
database.
■
Type The resource type associated with the name. Common resource types are [00h] for
the workstation service, [03h] for the messenger service, [020h] for the server service, and
[1Ch] for the domain name.
■
IP Address The IP address for the registered name.
■
State The state of the registration, such as Active, Released, or Tombstoned.
■
Static Indicates if record is a static mapping (column entry marked with an x).
■
Owner Indicates the owner (specific WINS server where the record was registered) of
the record.
■
Version Indicates the version ID of the record.
■
Expiration Indicates the date and time the record will expire, if it is not refreshed.
NetBIOS clients that do not use a WINS server must constantly register and defend their
NetBIOS names. However, the registration occurs by means of a broadcast and, thus, the registra-
tions are local to the subnet. Whenever a computer attempts to register a duplicate name, it will
receive a negative response from the computer that actively possesses the name. Whenever NetBIOS

name registration fails, the computer receives an error message, and NetBT won’t initialize on the
computer until the problem is resolved.
Whenever a WINS client is gracefully shut down, it sends a name release request to the WINS
server.The WINS server marks the entry as released and gives it a timestamp of the current time plus
the extinction interval.This interval indicates the time that must elapse before the record is marked as
extinct (or tombstoned) and can be scavenged from the database. However, if the WINS server that
receives the release request is not the original owner of the name registration, it will immediately
mark the record as extinct.The reason for this is to prevent inconsistencies between primary and sec-
ondary servers configured as replication partners.
What’s New for WINS in Windows Server 2003
The WINS service was significantly improved in Window 2000, which introduced a number of signif-
icant enhancements, such as enhanced filtering and searching for records display and burst handling of
WINS registrations.The WINS service in Windows Server 2003 maintains these improvements and
adds two more improvements:
712 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 712
■
Filtering records It is now possible to combine filters used to query the WINS
database.The available filters include record owner, record type, NetBIOS name, and IP
address with or without subnet mask.You can also cache the results of queries in the
RAM of the local computer from which the query is performed, improving performance
for subsequent queries and reducing network traffic.
■
Accepting replication partners For pull replication, you can configure the WINS
server to either accept or reject only the name records that are owned by a list of prede-
termined WINS servers. (Figure 20.20 later in this chapter shows the Advanced replication
property page where accepting replication partners are configured.) In Windows 2000, it
was possible to create only a list of replication partners to block.
Planning WINS Server Deployment
Clients can be configured to use multiple WINS servers (up to 12) to register and resolve computer

names in the event that the primary WINS server is unavailable. WINS servers can be configured to
replicate with one another to ensure both fault tolerance and the availability of records for name
resolution in a distributed environment where WINS clients are registering with different WINS
servers.The number of WINS servers that should be deployed depends on several complex factors,
such as the number of WINS clients that will be registering and resolving names and the network
topology (in particular, the presence, number, and capacity of WAN links). If you require WINS
replication to meet the goals of fault tolerance and availability, the WINS replication topology needs
to be designed to ensure optimal performance in the replication of WINS records and the currency
of those records, as well as to ensure optimal query response times, given the constraints of the net-
work topology.
Server Number and Placement
The number of WINS servers you deploy will be determined by the number of WINS clients and
the network topology. In general, you should try to design the WINS infrastructure to minimize the
number of WINS servers. Having too many WINS servers can complicate network problems, so
Microsoft recommends a conservative approach in determining the number of WINS servers and
further recommends one primary and one backup WINS server set up as replication partners to
each other for every 10,000 clients.
The WINS traffic between clients and servers is relatively small, about 40 bytes, which is the
average size of a WINS registration for a client. So, 10,000 WINS records would be approximately
400KB.Through a 56 Kbps WAN link, this amount of data would take a minute to transfer,
assuming you could transfer at this rate. It is more likely, though, that the effective bandwidth is
somewhat lower than 56 Kbps, and the transfer of 400KB of information would take longer.This
delay might or might not be acceptable. However, it is unlikely that 10,000 WINS registrations or
10,000 updated WINS records would need to be transferred simultaneously across the WAN.
To determine the actual number of WINS servers to deploy, you will need to take into account
server hardware, WAN links, the number of clients, and the need for redundancy and availability.You
should also take into account peak-load conditions that could occur, for example, if the power to
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 713
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 713
client computers were suddenly terminated and then resumed, resulting in a large number of simul-

taneous registration requests.
Planning for WINS Replication
Even in simple environments, it is a good idea to have two WINS servers configured as replication
partners to provide greater fault tolerance and availability.This kind of replication is relatively easy to
set up, for example by specifying automatic partner configuration, and requires little planning.
In larger and more complex networks, however, the replication topology will need to be care-
fully designed to ensure an optimal convergence time for the replication of WINS records, given the
size, topology, and available bandwidth of the network. Convergence time refers to the maximum
amount of time it takes for an updated record to be replicated to all WINS servers in the infrastruc-
ture. Generally, convergence time is a function of replication pull schedules and the number of hops
in a given replication path that a changed object must travel.
In reality, the amount of time it will take for a record to be synchronized depends on a number
of factors. For example, a WINS server configured to send push notifications immediately upon
receiving an update will replicate the record faster than the time determined by the replication
schedule of the WINS servers that have configured it as a pull partner. Factors that can affect con-
vergence time include the following:
■
The kind of replication partnership that is configured.A push/pull replication partnership
is more efficient for replicating records than a limited partnership (push or pull only).
■
The settings for pull and push partnerships that determine the frequency of replication
between servers.
■
The ability to use persistent connections for push and pull replication partners (this setting
is the default and found in the Replication properties pages of the WINS server console.)
The ability to use this setting depends on the presence of stable, high-speed links.
■
The particular replication model.The longer the replication path that a replicated object
must travel, the longer the convergence time. In a complex replication environment
involving multiple WINS servers, a hub-and-spoke replication topology provides the

shortest replication paths.
■
The particular kind of update that occurs in the WINS database. For example, a name release
update will not propagate as quickly as a name registration update, because it is more
common for a name-to-IP address mapping to be reused by the same computer, even in an
environment that uses DHCP. Since this kind of update is not as urgent as a new name reg-
istration, the WINS server provides it with a greater latency period for replication.
Along with these factors, you will need to take into account the network topology in planning
for WINS replication.Your WINS replication design should, if possible, mirror your network
topology. For example, if the organization has a centrally located head office that is connected by
high-speed, persistent WAN links to satellite branch offices, you should consider a hub-and-spoke
replication model with full push/pull partnerships. In this model, the WINS server in the head
office receives replicated records through the push/pull partnership, and then propagates updates it
714 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 714
receives from its own WINS clients and those changes it receives from the individual branch offices
to the other branch offices.
To plan for WINS replication, it is important to first understand partnership agreements and the
settings that can be configured on them.
Replication Partnership Configuration
In order for WINS servers to replicate WINS records with each other, a replication partnership
must be configured between them.There are three possible kinds of replication partnerships that can
be configured between WINS servers: push/pull (also known as full), push-only, and pull-only (also
known as limited).You can set up a replication partnership manually or implement it automatically.
Automatic Partner Configuration
Automatic partner configuration is an option that can be implemented on small networks to elimi-
nate the administrative effort for configuring replication partnerships between WINS servers. When
the automatic partner configuration is enabled, the WINS server will send announcements using the
multicast Internet Group Messaging Protocol (IGMP) address at 224.0.1.24, which is the well-
known multicast address for WINS servers. When the WINS server discovers other WINS servers

that are announcing themselves, the WINS server will automatically configure a partnership agree-
ment between itself and the discovered WINS server. (Both must be enabled for automatic partner
configuration.) When the WINS server discovers another WINS server, it will add the server to its
list of replication partners, configure push/pull replication between the servers, and set the pull
replication interval for every two hours.
Figure 20.20 shows the Advanced tab of the Replication Partners Properties dialog box,
which contains the Enable automatic partner configuration option.To view this page, you
need to view the properties of the Replication Partners node in the WINS console.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 715
Figure 20.20 Enabling Automatic Partner Configuration
301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 715