Summary of Exam Objectives

In this chapter, we discussed planning and configuring a Windows Server 2003 network to support host name and NetBIOS name resolution. Name resolution is the process of resolving names to IP addresses to enable communication between computers. Because names are easier to remember than numbered IP addresses, name resolution makes it easier for users to connect to resources on the intranet or Internet.

Host name resolution occurs whenever name resolution occurs through the WinSock interface. This will occur whenever a WinSock application, such as Internet Explorer, FTP, and Telnet, requires name resolution or when a name that needs to be resolved to an IP address is longer than 15 characters or includes dots.

NetBIOS name resolution occurs whenever the NetBT interface is used. This will occur, for example, when a user connects to a file share using a UNC-formatted name such as \\computer\sharename, or when the user issues a net command, such as net view. Some applications are written specifically for the NetBIOS interface and will use NetBIOS name resolution.

DNS is a requirement for AD and is responsible for ensuring that resources, such as domain controllers, can be located by other computers. The DNS namespace is based on the domain tree of AD, and the hierarchical DNS domain namespace mirrors the hierarchical AD domain tree. To support AD, the DNS server must be able to use SRV records, which are a special kind of RR that allows computers to locate services running on the network. Ideally, the DNS server should also support dynamic updates and incremental zone transfers.

On the Internet, the domain name space starts at the root, usually represented by a dot (.). Below the root are the top-level domains, such as .com, .net, .org, .ca, .de, .biz, and so on. Below these domains are the second-level domains, such as syngress.com or tacteam.net. These second-level domains can have additional subdomains, such as corp.tacteam.net. The FQDN for a host in a particular domain, such as www.corp.tacteam.net., represents the complete and contiguous path from the root to the host when read from left to right.

Authority for portions of the domain namespace is distributed among multiple DNS servers. A DNS server that is authoritative for a portion of the domain name space stores DNS RRs in a special file called a zone file. A zone file contains the RRs for hosts in the portion of the domain namespace for which it is authoritative. A zone begins with a special RR called an SOA record. The SOA record identifies the names and IP addresses of DNS servers that contain the authoritative RRs for their portion of the domain namespace. For example, two DNS servers could be authoritative for the entire tacteam.net namespace, including its subdomains.

It is important to understand the difference between a domain and a zone. A zone file can be authoritative for a single domain, or it can be authoritative for a parent domain and multiple child domains. In the latter case, the zone file contains all the records for the parent and child domain. If there is a delegation of authority from a parent domain to a child domain, the DNS server that is authoritative for the parent domain will have (in addition to the RRs for the parent domain) only the name server and A records that serve to delegate authority to DNS servers authoritative for the child domain.

On large, complex networks, the DNS infrastructure can be optimized by delegating authority to multiple DNS servers that are authoritative for their respective child domains. However, incorrect delegation of authority, (sometimes referred to as lame delegation) is a common source of DNS-related problems. Also, delegation of authority of a portion of the domain namespace may involve a security trade-off in that administration of those zones may be handled by different administrators.

Regardless of whether the domain namespace is used for name resolution on the Internet or exclusively on your intranet, the domain name should be unique to your organization. Even if you intend the domain namespace to be used exclusively on your intranet, it should be based on a name that is registered for use on the Internet. By definition, names that are registered for use on the Internet through the agency of ICANN-approved registrar are unique. Choosing a unique name will mitigate any rare, but possible, problems that might arise if two organizations that use the same domain name merge.

The choice of a domain namespace for the internal network will have an effect on security of the network, as well as on the administrative effort required to maintain the DNS infrastructure. Regardless of the choice you make, the DNS infrastructure needs to be designed so that RRs that point to hosts on your internal network are never accessible to public DNS servers on the Internet. Your security needs may also include a requirement that DNS queries to the Internet are not allowed. Furthermore, firewalls and routers should be configured to restrict Internet access of internal DNS servers. The choice of a domain namespace can be used to enforce this requirement. In general, the choices are as follows: same domain name for intranet and Internet, subdomain of Internet domain name for intranet, or disjointed namespace for intranet.

To properly plan and implement a DNS infrastructure, it is important to understand the various DNS zone and server types that can be deployed on your network. Zone types include primary, secondary, stub, and Active Directory-integrated zones. Server types include caching-only, forwarding, and nonrecursive.

A carefully designed DNS infrastructure will ensure the fault-tolerant availability of DNS data, while at the same time, limit the bandwidth consumed by zone transfers and other DNS-related traffic, as appropriate. To ensure fault tolerance and eliminate single points of failure, it is recommended that at least two DNS servers (a primary and a secondary or two Active Directory-integrated zones) be configured for each zone of authority. Ideally, these servers should be on separate subnets that are served by different routers.

Standard zone transfers from primary to secondary zones can take either of two forms: the older, full zone transfer (AXFR) or the newer and more efficient incremental zone transfer (IXFR). During a full zone transfer, the entire zone file is copied from the primary to the secondary. During an incremental zone transfer, only the incremental changes since the last update are copied. Zone transfers are triggered either by a notify message sent from the primary to the secondary when changes have occurred to the zone or according to the refresh interval in the SOA.

Active Directory-integrated zones do not use standard zone transfer mechanisms, unless a secondary server is configured to transfer zone information from an Active Directory-integrated zone. Active Directory-integrated zone transfers use multiple-master AD replication and as such provide a more efficient and secure mechanism for transferring zone information.

With Windows Server 2003, it is now possible to fine-tune the scope of replication for Active Directory-integrated zones through the use of the application directory partition. You can, for example, replicate Active Directory-integrated zones to only those domain controllers that have the DNS service installed. This kind of configuration, however, is only possible if all the domain controllers are running Windows Server 2003. Windows 2000 domain controllers store Active Directory-integrated zones in the domain partition and, consequently replicate this information to all domain controllers.

Security is an important consideration when planning for zone replication. Internal DNS data should be confidential. Active Directory-integrated zones provide the highest level of security because AD replication traffic is encrypted. To mitigate the risk of footprinting or data dumping, security is enhanced on DNS zones by specifying the IP addresses of computers that are authorized to initiate a zone transfer with the primary DNS server. VPN tunnels or IPSec should be used if zone transfers of internal DNS data take place over the Internet.

To increase fault tolerance of the forwarding servers, multiple forwarders can be specified in an ordered list of servers that the forwarding server will contact to resolve names. Recursion can be enabled or disabled on a per-domain basis if the queries to the forwarders fail. When recursion is disabled, the forwarding server will send a negative response to the client if none of the forwarders can resolve the query. Otherwise, the forwarding server will use recursion to attempt to resolve the name in the event of failure.

The Windows Server 2003 DNS is a standards-based implementation of DNS and will interoperate with other standards-based versions of DNS, depending on their respective capabilities. For example, BIND 9 and BIND 8, as well as Windows NT 4.0 with Service Pack 4 installed, can support SRV records and can be used for zones containing AD records.

Windows XP, Windows 2000, and Windows Server 2003 clients support dynamic updates of zone RRs, allowing them to create forward and reverse lookup records in zones configured to allow dynamic updates. The Windows 2000 and Windows Server 2003 DHCP server can be configured to update forward and reverse lookup records for DHCP clients in zones configured to accept dynamic updates, including downlevel clients that do not support dynamic updates. When the DHCP lease expires, the DHCP server can be configured to attempt to remove both the forward and reverse lookup records that have been created in their respective zones.

The ability to perform dynamic updates requires that the DHCP client service is running on the client computer, regardless of whether or not the computer is configured as a DHCP client. For downlevel clients, such as Windows NT 4 servers that are configured with static addresses, the DHCP client service will not perform a dynamic update to the zone file. In these cases, it is necessary to either manually update the DNS RRs or configure the DNS server to do a lookup on a WINS server to resolve the computer name-to-IP address mapping.

A DNS server will perform a WINS lookup for names it cannot resolve authoritatively if a WINS RR is present. The WINS RR provides the DNS server with information on the IP addresses of the WINS servers and the length of time to cache the resolved query. Additionally, it is possible to specify that the WINS record not be replicated during a zone transfer in the event that non-Microsoft DNS servers are being used as secondaries. WINS records can be created for both forward and reverse lookup zones. In the case of a reverse lookup zone, the DNS server performs an nbtstat command to resolve the IP address to a NetBIOS computer name to which it appends a configured domain name.

It is possible to create subdomains to host only WINS forward and reverse lookup records. However, to ensure proper name resolution, it may be necessary to change the client domain suffix search list to ensure name resolution for these domains.

Implementing a DNS infrastructure exposes the network to additional threats that are specific to DNS. These threats include footprinting, DoS attacks, and redirection. To ensure the confidentiality, integrity, and availability of DNS data, DNS administrators should follow recommended best practices. To assist in this, Microsoft has created three different categories of DNS security configurations: low, medium, and high security.

Another best practice for securing a DNS infrastructure includes ensuring that there is no unacceptable single point of failure in the DNS infrastructure, for example, by distributing secondary servers and Active Directory-integrated zones on different subnets served by different routers. Implementing a private root zone and choosing a disjointed namespace based on a registered domain name will also enhance the security of DNS data.

Windows Server 2003 and the DNS service provide a number of tools to monitor the operation, availability, and performance of DNS services in your infrastructure. These tools include the Monitoring tab on the DNS MMC console, DNS debug logging, DNS event logging, and DNS Performance Monitor counters. You can also use command-line tools such as NSLookup.exe, Dnscmd.exe, and DNSLint.exe.

NetBIOS methods of name resolution are invoked whenever a NetBIOS application needs to resolve computer name-to-IP address mappings. Unlike a host name that can be assigned to computer by means of a hosts file or DNS, a NetBIOS name is configured on the computer. A computer can be configured with only one NetBIOS name. Furthermore, NetBIOS computer names must be unique on the network. NetBIOS group names are nonexclusive and are used to identify groups of computers, such as workgroups or domains. They are primarily used to support browsing.

Because NetBIOS names are broadcast-based, special solutions were developed to support NetBIOS name resolution using routable protocols, such as TCP/IP, which uses logical addresses (IP addresses) to resolve the MAC addresses of network devices. NetBIOS is implemented as an interface, equivalent to the WinSock interface, called NetBT. Thus, NetBIOS name requests on a TCP/IP network are processed through the NetBT interface.

However, name resolution is still broadcast-based. Because these broadcasts normally do not cross routers, clients must use either an LMHOSTS files or a WINS server to resolve NetBIOS mappings that are on remote subnets.

The LMHOSTS file is very much like the hosts file that can be implemented for WinSock applications. Like the hosts file, the LMHOSTS file contains a static mapping of IP addresses to names. In order to implement a name resolution strategy using LMHOSTS files, these files must be installed and maintained on every computer that requires the ability to resolve names on remote subnets, creating a significant administrative burden if there are more than a handful of computers, as well as posing significant potential for human error.

To address the limitations of NetBIOS name resolution and the use of LMHOSTS files, WINS servers can be deployed. A WINS server provides a NetBIOS name service for the registration and resolution of NetBIOS names in a distributed database. Communication between WINS servers and NetBIOS clients is unicast-based, rather than broadcast-based. This means that NetBIOS applications and services can register names and perform NetBIOS name queries with a WINS server that is located on a remote subnet.

How NetBIOS name resolution occurs depends on the specific node configuration of the NetBIOS client. There are four kinds of NetBIOS nodes. A b-node (broadcast node) client is exclusively broadcast-based and will not contact a WINS server using a unicast message. A p-node (peer node) client is exclusively unicast-based and will not use broadcasts to perform name registration or name queries. An h-node (hybrid node) will first try to contact a WINS server using unicast messages, before falling back to using broadcasts. An m-node (mixed node) client is like an h-node client except it will use broadcasts before falling back to unicast communication with a WINS server.

An h-node configuration is the default configuration for Windows clients. The order of name resolution for an h-node client is as follows: first, the computer will check its own computer name; second, the computer will check its NetBIOS remote name cache; third, the computer will contact a WINS server; fourth, the computer will send three broadcasts on the local subnet; fifth, the computer will check its LMHOSTS file, if so configured; and sixth, the computer will try host-based methods of name resolution (hosts file and DNS).

Although WINS servers are used for dynamic registrations, they can also store static records that are either manually created or imported from an existing LMHOSTS file. It is not recommended, except in some special circumstances, that static mappings be created on a WINS server. Static mappings never expire, and in cases where these records are replicated to other WINS servers, special care must be taken to ensure that they are deleted on all WINS servers by manually tombstoning them when they are deleted. More importantly, if a WINS client with a static mapping is later upgraded to register with WINS, the registration will fail unless the migrate on setting is enabled on the WINS server (it is disabled by default).

Even a modestly powered computer can provide an adequate level of name services for a large number of clients. Microsoft recommends approximately 10,000 clients per WINS server and goes out of its way to warn of the dangers of installing too many WINS servers on the network. Too many WINS servers can complicate and compound network problems if things go awry. WINS is a relatively CPU- and disk-intensive service. So, if a WINS server needs to handle registrations for a large number of clients, performance can be improved by adding another processor and placing the database on a separate, dedicated hard drive.

The WINS service is cluster-aware and can be set up in a Windows cluster to provide a high degree of availability. In a Windows cluster, the WINS service can be set up on two or more computers, called cluster nodes, that share an external SCSI or Fibre Channel device where the WINS database is located. If the cluster node where an instance of the WINS service is running fails, the WINS service will start up on another node, providing continuity of service. The primary advantage of using a Windows cluster is that in the event of the failure of a WINS server, no replication is necessary to synchronize the database, since only a single database is used.

Using a Windows cluster may not be a desirable solution to provide the availability of the WINS service that you desire. To provide fault tolerance, high availability, and load balancing, you should set up multiple WINS servers as replication partners, keeping in mind the Microsoft recommendation to be as conservative as possible in estimating the number of WINS servers you require.

Replication between WINS servers is configured by means of replication partnerships. There are three kinds of replication partnerships: push-only, pull-only (both known as limited), and push/pull (also known as full), replication partnerships. WINS replication partnerships should be set up on reciprocal basis. For example, WINS-A is configured with WINS-B as its push partner; WINS-B should in turn have WINS-A configured as it pull partner. Ideally, however, both WINS-A and WINS-B will be both push and pull partners of each other. Microsoft recommends using the default push/pull partnerships and avoid using limited partnerships.

The primary difference between push and pull replication is that pull replication can be scheduled to occur at specific intervals or times. (It can also occur when the WINS service starts or when initiated manually by an administrator.) Configuring pull replication is useful in situations where replication needs to occur at off-peak hours over slow WAN links.

The amount of time it takes a replicated record to be replicated throughout the WINS infrastructure is referred to as convergence time. In designing the WINS infrastructure, you need to take into account the longest convergence that is acceptable and balance this with the bandwidth requirements of your network. The WINS replication topology you implement will have an effect on convergence times. If replicated WINS records need to travel through less than optimal paths, convergence times will be longer.

When there are multiple WINS servers in the infrastructure, the most efficient replication topology is the hub-and-spoke model. With this topology, a central hub WINS replicates with other spoke WINS servers using reciprocally configured push/pull partnership agreements. The longest path that any record needs to travel to reach the most distant WINS server is two: one hop to the hub server and a final hop to any spoke server.

Other topologies are possible, such as a ring topology, or hybrid topologies that mix ring and hop-and-spoke topologies. Also, various topologies could use a mix of limited and full partnerships. The optimal topology for the network will be determined by the contingencies of the network infrastructure.

To avoid problems with replication, you should follow best practices, which, in general, advocate simplicity. You should avoid placing WINS servers on multihomed computers. Unless special care is taken in the configuration of the multihomed computer and its replication partners, replication will fail. WINS servers that have the multihomed computer as a replication partner need to configure multiple replication partnerships that point to all the IP addresses on the multihomed computer. It is also possible that each network interface of the multihomed computer could be configured to point to a WINS server other than itself. This can cause a problem known as split registration.

Split registration occurs when a part of a computer’s name mappings are created in more than one WINS server so that the mappings are owned by different servers. If the split registration occurs for the name mappings of the WINS server itself, the likely result will be hard-to-find problems with name resolution. To avoid problems with split registration, you should ensure that the WINS server is configured to register with only itself as the WINS server. Do not specify a different secondary WINS server to register with.

The use of static records can cause problems in a replicated environment. The actual removal of either a static or a dynamic record from a WINS database occurs through a process known as scavenging. The renewal interval determines the TTL of a WINS registration. The default is six days. If a client does not renew the registration, it is marked as released. The extinction interval is the amount of time the must elapse before a released record is marked as tombstoned. The default is four days. The extinction time is the amount of time that must elapse from the time the record is marked as tombstoned and when it is deleted from the database. The default is six days. The verification interval depends on the previous values and is the amount of time that must elapse before a WINS server will validate active records it does not own. The default is 24 days. Changes to these settings will have an effect on the overall performance of the WINS servers in the environment. Other factors that can affect performance of a WINS server include the compaction of the database and when constancy verification is performed.

Another setting that can affect the performance of WINS servers is burst handling. Burst handling, which is enabled by default, gives the WINS server the ability to handle a very large number of registrations simultaneously. For example, if the power to a large number of computers failed and then was restored to all those computers at the same time, this would cause a huge volume of registration requests that could potentially overwhelm the WINS server. When burst handling is enabled and triggered by a surge in registration queries, the WINS server will send a positive response to the client with a very short TTL, forcing the client to renew the registration soon after the surge has abated.

Enabling burst handling has implications for WINS security. Because burst handling events are recorded in Event Viewer, they can provide an indication of a possible DoS attack launched against the WINS server. The only effective way to protect WINS against bogus registration requests is to secure the physical network.

Because NetBIOS is an unauthenticated protocol, it is possible for a rogue server to hijack a dynamic registration that belongs to another computer. To mitigate this risk, you should identify mission-critical servers and assign them static mappings that cannot be overwritten by dynamic registrations (you must ensure that the Migrate On setting is disabled).

To ensure the confidentiality of WINS data, you should physically secure the WINS servers. Also, if you move the WINS database from its default location, it will lose the security it inherits from the parent System32 folder. Thus, if you move the database, you should ensure that the ACL on the WINS folder is configured appropriately. In high-security environments or in situations where WINS data is replicated over a public network, you should encrypt replication traffic using VPNs or IPSec.

Although replication can help to ensure the integrity and availability of WINS data, it should not be considered sufficient for these purposes. It is therefore important that WINS databases be backed up on a frequent basis, either automatically or manually using the WINS backup utility.

In general, your troubleshooting strategy should be based on the OSI model, and you should troubleshoot from the bottom of the OSI model to the top to assist in isolating the precise nature of the problem. Many apparent name resolution problems are actually caused by problems with network communication. Utilities such as PING and Netdiag can help you eliminate network communications as the source of the problem.

Often, name resolution problems are caused by client configurations. Your first step in troubleshooting name resolution problems should be to verify the TCP/IP settings on the client using a utility such as Ipconfig or Netdiag. Your next step at the client computer should be to examine and clear the ARP, NetBIOS, and DNS cache using the arp, nbtstat, and ipconfig commands as appropriate. After you have verified the settings and cleared the cache, you should test network connectivity by first pinging the IP address of the default gateway, and then pinging the IP address of a remote host on your network, usually the WINS included in the DNS servers but could include the IP addresses of Internet hosts. Your next step should be to isolate whether the problem is with NetBIOS or host name resolution, if this is not already obvious.

Once you have determined that the problem is related to the DNS or WINS servers, you can take a troubleshooting strategy appropriate to each service, which should probably start with an examination of events in Event Viewer that would suggest possible causes such as failed zone transfers. Also, you should consider whether the problem is server-wide or related to a subset of name mapping records. If the problem is related to incorrect DNS records, you should consider whether the problem is related to cached or authoritative records. If there is a problem resolving names in an authoritative child domain, a likely cause is lame delegation. If the problem is related to resolution of unqualified names to a record in a parent domain, you should double-check the domain suffix search list on the client. Otherwise, you check to ensure that the DNS server in the child domain can contact a server in the parent domain to resolve names.

If the problem is related to dynamic updates of zones, you should review the client and DHCP server settings to ensure that update requests are sent to the appropriate primary server for the domain. If you have enabled secure-only updates on an Active Directory-integrated zone, the ACL on the RRs may be preventing updates from occurring.

For problems related to NetBIOS records, the most likely causes are related to replication, such as slow convergence times or failed replication owing to network problems or misconfiguration. If a WINS replication partner is a multihomed server, multiple replication partnership agreements need to configured to specify all the IP addresses of the multihomed server, rather than its NetBIOS names.

If the problem is related to the reappearance of a deleted static mapping, you should perform a manual tombstone deletion of the record on the WINS server that owns it. If you can’t overwrite a static mapping with a dynamic mapping, you need to ensure that the migrate on setting is enabled.

Name resolution is a fundamental component of Windows Server 2003 networking. In this chapter, we have examined the many factors involved in developing the best name resolution strategy for your organization’s network, not only to help you master the exam objectives, but to make it easier for you to perform the everyday duties of a network administrator.