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
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
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
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
■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 9xclients, 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