Designing the Name Resolution Server Infrastructure

The name resolution requirements for your organization may only include DNS and not WINS. Whereas DNS will be required for Active Directory and hostname resolution, you may be one of the lucky organizations that do not have to keep WINS running. If you are like almost every other organization that has been utilizing Microsoft operating systems and applications, however, you will need to keep WINS up and running for a while. Having these services running on your network will require you to make an investment in the hardware that will run the service. You will also need to determine where you will locate each of the servers so that they are used to their fullest capacity and are most efficient for your network.

Designing the DNS Infrastructure

After you have determined how you are going to name your domains and your clients within each domain, you will need to design the physical server structure to support the name resolution methods you will be employing . DNS servers will need to be deployed in a manner that will enable your users to have efficient name resolution, while at the same time, not cause adverse issues within the network infrastructure.

Determining the Number of DNS Servers

As with most servers, allocating the fastest processors, more memory, and faster, larger hard drives will improve the performance of a DNS server. By increasing the amount of memory that the server has, you will be able to more efficiently handle large zones since all of the resource records are pulled into memory as the system starts up and records are added to the zone. Each resource record will consume approximately 100 bytes of RAM, so you should be able to determine the amount of RAM that you will need based upon the number of records the zone will host. You will need to determine the number of clients that will be registering within the zone so that you will have an estimation of the total amount of RAM dynamic updates will consume . Along with the client registrations, remember that each domain controller will register many SRV records in order to identify the domain controller and Global Catalog server services within the forest, domain, and site.

Tests have shown that a DNS server running on a server with a Pentium III 800MHz processor with 512MB RAM can support nearly 10,000 queries per second. Always test the systems you are putting into place to make sure that they will support the client base that you are assigning to them. If you find that the servers are having a hard time keeping up with the queries, add an additional server to take on some of the client query load. You can change the primary DNS server settings on some of the clients to direct their queries to the new server, thus relieving the load from the original DNS server.

If you are planning on creating Active Directory “integrated zones within your design, remember that the DNS service will have to be located on a domain controller. Make sure that the domain controllers you are planning to use as DNS servers are able to take on the additional DNS traffic load and still efficiently respond to clients needs.

Determining DNS Server Placement

Placing DNS servers could be as easy as putting one in each subnet so that every client has a local DNS server, but this is probably not a realistic option for most companies. However, it does address the first rule of DNS server placement: make sure the DNS service is highly available. DNS is used by servers and clients alike; they both rely on the service to be available so that they can perform the functions they are called upon to do. Try to place DNS servers close to the clients that will use them the most. You should always have redundancy built into your namespace design, giving each of the clients at least two DNS servers to call upon.

Most organizations cannot afford one server per subnet, let alone two, so you will have to design the placement of servers where they can be the most effective for the most clients. In Figure 10.3, DNS servers are placed at each of the locations that need to have local name resolution. In this example, each of the segments contains servers that the workstations need to locate, even if the network links to the other locations fail.

Figure 10.3: DNS server placement to support username resolution queries

There could be instances where a remote site needs to have name resolution, but it may not have any resources local to the site. To reduce the amount of name resolution traffic that is sent across the WAN link, you could implement a caching-only server. A caching-only server does not have any zones created on it; it simply forwards queries to another DNS server to resolve on its behalf . The results that are returned are cached for future requests for the same information. As the cache is built, fewer and fewer queries are sent across the WAN link, reducing the overhead on the link. There is a downside to using a caching only DNS server: if the actual IP address for an external resource changes after the external resource s IP address has been cached, the external resource will be unavailable to your internal users until the data in your cache expires and a new query is sent to the outside DNS server.

Now that we have taken a look at the DNS infrastructure, let s turn our attention to the WINS infrastructure. If you are an administrator for an organization that still supports NetBIOS within their infrastructure, you will need to take what we discuss next into account.

Designing the WINS Infrastructure

The WINS infrastructure will be based upon the computer and application needs. If any of the operating systems or applications within your organization has a NetBIOS dependency, you will have to make sure they are able to resolve names and locate services. Once you determine the extent of the NetBIOS infestation, you can then determine how many WINS servers you will require and where you will place them. If you deem that multiple servers are necessary, you will also need to configure the replication between the servers to allow all of the clients to interoperate within the network.

Determining the Number of WINS Servers

As with any service, you should always test to see how your servers will handle any type of service. Microsoft has identified that a typical WINS server can support approximately 1,500 name registrations per minute or respond to 4,500 queries per minute. If this is the case with your hardware, you should be able to host approximately 10,000 clients per WINS server. However, other issues come into play when you are trying to determine the number of WINS servers you should deploy.

The first thing you should consider is the WAN links that you have. Depending upon the current level of traffic on the link, you may not want to have WINS traffic passing across it. Plus, you may want to have the WINS server local for the users in case of a WAN link failure. This way, if a WAN link were to go down, the clients would have local name resolution and could continue with any work they need to perform locally. At the same time, you may not want to put a WINS server in an office that only hosts five systems. You will need to determine what the trade-off limit is going to be.

Design Scenario ”Determining WINS Population

Michelle is trying to determine how many WINS servers she will need for her organization. Currently, she has four sites, each of which will have domain controllers from her domain. The corporate office consists of 15,000 users and each of the regional offices employs between 5,000 and 10,000 users. Four regional offices exist: Washington, DC, with 5,000 users; Los Angeles with 6,500 users; Atlanta with 8,000 users; and Houston with 10,000 users. All of the offices are connected to the corporate office through T1 connections. In order to control the replication of Active Directory objects, sites have been created for each location. She has already decided upon the hardware that she is going to use for the WINS servers: a Pentium 4 2.4GHz processor, 512 MB RAM, and 100 Mbps network cards. A performance test on the hardware has proven that the servers can handle more than 20,000 queries per second in the lab, while the anticipated peak query rate is 13,000 queries per second.

Michelle wants to make sure that each of her locations has a level of redundancy that will guarantee name resolution in case of a link failure between locations or a server failure within the site. She also wants to keep the WINS traffic that has to pass across the WAN links to a minimum.

Question: Where should Michelle locate WINS servers to meet her needs? Answer: She should place a WINS server at each location to make sure that she has name resolution capabilities even if the WAN link fails.
Question: How many WINS servers are required at each location to support queries? Answer: The hardware specifications will allow one server to support all of the users at the same location as the WINS server; however, you may need to add additional hardware to support redundancy.
Question: To support all of the requirements that she has identified, redundancy, and efficient use of the WAN link, how many WINS servers should Michelle implement? Answer: She should implement at least ten WINS servers, two at each location. When she locates the WINS servers at each site, she is reducing the query traffic on the WAN links. By implementing two WINS servers at each site, she will also meet her specification that name resolution will survive if a WINS server fails.

Identifying WINS Replication Options

WINS replication is enabled by choosing which servers will be made replication partners of one another. With the exception of automatic partner replication, the administrator is responsible for determining which servers will replicate with each of the other servers in the organization. Automatic partner replication, if turned on, will find other WINS servers within the same subnet and automatically create replication connections to them. WINS servers in other subnets are not detected and will not participate in the automatic partner replication. The administrator must explicitly configure the replication between two servers. Replication can be configured as push replication, pull replication, or push/pull replication.

Tip	If your infrastructure allows multicast forwarding between subnets, the WINS servers will configure automatic partner replication.

In push replication , the replication partner that is the owner of records is configured to wait until a specific number of record changes has occurred before notifying its partners that there are changes they need to accept.

In pull replication , the replication partner is configured to wait a specific amount of time before requesting a list of the changes from its partners with which it is configured to replicate.

Push/pull replication configures a partner to utilize both options when working with its partners. Whenever possible, you should try to configure your WINS replication partners to use push/pull replication. Using push/pull replication will allow you to maximize the replication topology. If several record changes exist, the push partner will notify the pull partner that it needs to request the changes. During slow times when there are not very many changes to the WINS database, the pull partner will still request the changes, but only after a certain time interval has passed. Having each of the WINS servers configured in this manner will allow you to preserve the WAN traffic while minimizing false responses from the WINS server when a client queries.

You will need to determine the maximum amount of time you will allow before changes should be replicated to each partner. The longer you wait before implementing pull replication or the more changes you allow before you initiate push replication, the more out of sync the WINS servers will be. In order to maintain a consistent WINS topology, you need to take into consideration the convergence time that will occur as the WINS servers replicate all of the changes. The more hops a record needs to take going from WINS server to WINS server, the longer the updates will take to reach every server within the organization. Try to use a hub-and-spoke method of propagating the changes. Figure 10.4 shows an example of the hub-and-spoke method of replicating changes.

Figure 10.4: WINS hub-and-spoke-replication-topology

When you use the hub-and-spoke method, servers in the hub are responsible for replicating changes to all of the WINS servers at the spokes . In addition, each WINS server passes their replication data to the central WINS server, which is responsible for replicating the data to the other servers in the organization. This reduces the maximum number of replication hops to 2. If each of the replication partners is configured to pull every 15 minutes, the convergence time would be 30 minutes.

Figure 10.5 illustrates another method of replicating data between WINS servers ”the linear model .

Figure 10.5: WINS linear replication topology

If we still have a 15-minute pull replication cycle, data from WINS1 will not reach WINS 5 until an hour has passed. As you can see, the hub-and-spoke method is more efficient. However, there is a problem with either of these methods. If communication to along any of the network links is lost, replication traffic will not make it to the other servers. If you decide to build a WINS hub-and-spoke or linear topology into your design, you should also build in redundancy and fault tolerance within your network infrastructure.

The larger your organization is, the more challenging it will be to design a functional WINS topology. Review the resource usage patterns of the clients to determine where the changes within the WINS database will need to be replicated. Make sure that those servers can replicate efficiently with one another and then configure replication to the other WINS servers on a schedule that will keep the users happy.

In Figure 10.6, a company that has several locations uses a two-level hub-and-spoke topology. Each of the sites where users need to be updated on changes is tied to the others by a hub system. WINS servers at each of the spoke sites are configured as primary WINS servers for the clients and the hub system is defined as the secondary in case the primary WINS server fails. Each of the hub WINS servers is interconnected to the other hub servers to guarantee that all of the changes within the organization are replicated throughout. If you configure each of the servers within the spokes to replicate with two WINS servers in the hub, you will increase the total amount of replication traffic, but you will ensure that each spoke WINS server will have a partner to replicate changes from if one hub server were to fail.

Figure 10.6: Multi-level WINS hub-and-spoke topology

One thing that you can do to make sure that the hub WINS server is available is to implement a clustering solution. Because the WINS service is cluster aware, you can put a clustered system in place that hosts the WINS service. If one of the nodes fails, you will still have the remaining node online. You should determine if the cost of building a clustered solution is worth the uptime that you will achieve from the fault tolerance that is gained . You should also determine how you will keep the systems communicating, because the clustering solution will only protect the servers, it will not guarantee that the communication lines will remain available.

Design Scenario ”Determining WINS Replication Paths

Acme Creations has four offices within its organization: the corporate office in New York, and three regional offices located in Hawaii, Taiwan, and Japan. Each of the WAN links has approximately 1Mps available, but due to additional anticipated client traffic, Acme wants to reduce the total query traffic across the WAN links. The regional offices in Japan and Taiwan are connected to the Hawaii office through dedicated WAN links that have traditionally held an 88-percent uptime. The corporate office in New York is connected to the Hawaii office through a WAN link that has maintained an uptime rating of 96 percent, whereas the WAN connections from New York to Japan and Taiwan have proven to be less reliable, with an uptime rating of only 73 percent.

Joel is trying to determine the best method of keeping the WINS servers synchronized. He has placed two WINS servers at each location and made them replication partners of each other. Now he needs to determine how the rest of the WINS topology will be designed.

Question: How should Joel implement the replication topology if he wants to use the most reliable communication paths? Answer: Hub-and-spoke topologies allow for the most efficient replication of database entries because each of the sites has a maximum of one server to pass the replicated data through before it reaches the intended WINS server.
Question: Which of the locations would make the best hub? Answer: Hawaii has the most reliable links to all of the other locations, so it would make the most sense to implement the hub there and make the other three spoke locations.
Question: What options should Joel consider for guaranteeing the WINS service at the hub location? Answer: Because Joel is already planning on having two WINS servers at each location, each of the WINS servers within the Hawaii site could be configured as push/pull partners with the WINS servers from the other locations. This would allow all the records to be replicated to each of Hawaii s WINS servers and would guarantee that replication could continue if one of the servers failed. He could also use a clustered solution if he wanted to go to the added expense of installing clustered equipment.

As with many Microsoft products, the name resolution services can be used in conjunction with one another so that you have a comprehensive name resolution strategy. Both services will also take advantage of the DHCP service to help an administrator configure the infrastructure.

Integrating Name Resolution Services

DNS, WINS, and DHCP are all important services within an network. Each of them provides functionality that makes networks more efficient and easier to administer. When using them, you should take advantage of their interoperability. DHCP provides functionality that makes using WINS in your network easier, and DNS and WINS work together to create a solid name resolution topology.

Through the following sections we are going to discuss how each of the services interact with one another.

Integrating DNS and WINS with DHCP

DHCP is the service that provides IP configuration settings to DHCP-enabled clients. DHCP can also be integrated with the DNS service to assist in the dynamic registration of clients. If the two services are integrated, the DHCP server can be responsible for updating and removing the PTR record for the DHCP client, which is the default setting for Windows 2000 or later clients, or, with a small configuration change, both the A and PTR records.

The DHCP server can assign WINS and DNS server addresses and WINS node types to DHCP clients. As a result, you will not have to configure each of the clients manually; you can centralize the control. Since the client will receive the WINS server address from DHCP, you can make changes to your infrastructure and not have to reconfigure the client. The node type controls how the clients will query for name resolution. On each of the DHCP servers, make sure the entries for each of the subnets is valid and that the clients are directed to the correct WINS and DNS servers on their subnet.

Integrating DNS with WINS

If you still have systems within your network that register computer names with your WINS server and do not support dynamic DNS registration, you can allow the DNS server to perform WINS lookups to locate computer names that match the hostname for which another system has sent a query. This configuration is especially convenient if your environment supports clients who cannot perform a WINS lookup and clients who cannot dynamically register within DNS.

You may also need to support clients that do not interact with WINS servers. If you have clients that only broadcast for name resolution, you can configure a WINS proxy agent on the segment where the non-WINS client resides. The WINS proxy will intercept the queries and will send the query to the WINS server for processing. Once the WINS server responds, the WINS proxy will broadcast the response for the client to receive. For other clients to locate the non-WINS clients, you can add static entries within the WINS server.

However, this scenario has a caveat. If the third-party DNS servers that you are using do not support WINS referrals, you may elicit errors in the zone when zone transfers occur. To alleviate this issue, you can create a zone on the Windows-based DNS server that is used for WINS referrals. Then, configure the clients to search both the original DNS zone and, if they are unable to locate the appropriate record there, they will issue a request to the zone enabled for WINS referrals. The thirdparty DNS server will host the original zone and a delegation to the server hosting the WINS-enabled zone. Records that are transferred to the third-party DNS server will not cause errors because of the unknown record types.

You will find that there are very few, if any, services that will not have to be secured. The name resolution services are no exception. You need to determine the level of security you need to provide each of the services with based upon where they will be used.