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 . 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. 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. 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