Integrating DNS with WINS

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Michael Masterson, Herman Knief, Scott Vinick, and Eric Roul

Chapter 12, from Windows NT DNS, published by New Riders Publishing

This chapter will review:

How Integration Works. This section explains why it's a good idea to make WINS and DNS cooperate. Multiple-platform networks can benefit by providing several kinds of name resolution to various clients with different client configurations.
Enabling WINS Lookups. This section shows how to establish WINS lookups through a DNS server.
Testing WINS Lookups. This section shows how to be sure that WINS lookups through DNS are working properly.
Reverse Lookups with WINS. This section shows how to establish reverse lookups through DNS for clients that register to a WINS server.
Multihomed Servers. WINS typically does a good job of handling multihomed computers. This section shows how to provide multihomed resolutions through DNS for WINS-registered computers.

Mixed networking environments are today's norm. A multiple-platform network can have a UNIX-based server to handle DNS requests and a Windows NT-based server to handle WINS requests, but this means you'd spend a lot of time administering two separate name resolution methods. Windows NT 4.0 cuts this administrative overhead by integrating both name resolution methods.

DNS and WINS both participate in resolving host names and computer (NetBIOS) names to IP addresses in a typical Windows environment. They help you resolve names so you can connect to remote computers across the LAN and across the Internet. WINS resolves computer names that are flat names, such as \\EARTH, and DNS resolves FQDNs, such as earth.paradise.com.

Table 12.1 shows some noteworthy comparisons illustrating key differences between WINS and DNS:

Table 12.1 WINS Versus DNS

WINS	DNS
The purpose is to resolve NetBIOS names to IP addresses.	The purpose is to resolve host names to IP addresses.
Names are flat and 15 characters long.	Names are hierarchical in nature.
Name registration is dynamic and happens automatically.	Name registration is static and has to be done manually.
Supports incremental replication of the data, which means that only changes in the database are replicated between WINS servers.	Doesn't support incremental replication of data between DNS servers. This means the whole database has to be replicated every time.
Supports DHCP.	Doesn't support DHCP.
Doesn't support email routing or additional TCP/IP application services.	Supports other TCP/IP application services such as email routing.

These differences create a challenge for anyone designing name resolution in a mixed naming environment. WINS also supports dynamic name registration, which makes name resolution possible in a DHCP environment. By contrast, DNS depends on static files for host name resolution. Only dynamic DNS using the latest versions of BIND for UNIX can support dynamic updates.

How Integration Works

For ideal integration, NetBIOS and DNS hosts should support both name resolution and reverse address lookups. Name resolution is a process in which a NetBIOS or DNS host name is resolved to an IP address. It simply means that such a name as Host.taos.Com (the DNS name) or Host (the NetBIOS name) should uniquely resolve to an IP address such as 198.25.40.31. Reverse address lookups resolve IP addresses to a unique NetBIOS or DNS host names. It simply means that an IP address, such as 198.25.40.31, should uniquely resolve to such a name as Host.Company.Com or Host.

This section discusses how to integrate name resolution methods and identifies issues you may face when implementing support for reverse address lookups. When dealing with name resolution, the part that involves more effort is the process to ensure that DNS hosts can resolve dynamic NetBIOS names. The opposite is trivial because NetBIOS hosts can use a DNS resolver to resolve any static DNS host names.

Depending on the amount of interaction between the DNS hosts and NetBIOS hosts, the whole name resolution issue brings some interesting scenarios.

One scenario is where the clients connect to the servers and no interaction is necessary between clients. If the connectivity involves NetBIOS hosts (such as Microsoft hosts) and DNS hosts (such as UNIX hosts), then the integration can be done without many problems simply because

The NetBIOS hosts have the capability to query a DNS server for DNS host name resolution. This ensures that the UNIX servers can be accessed from the NetBIOS clients.
The NetBIOS hosts (such as a Windows NT server used to run FTP, Telnet, or other TCP/IP-based server services) can be assigned static IP addresses that can be mapped in the DNS database. UNIX clients will be able to use DNS to resolve these important NetBIOS hosts.
The WINS clients continue to use WINS servers for resolving dynamic NetBIOS host names to IP addresses.

The second scenario is where every host may need to connect to every other host, such as in a workgroup setting. The integration becomes more challenging if you want peer-to-peer connectivity between NetBIOS-based hosts and UNIX hosts. Windows NT DNS Server can accomplish this integration.

Microsoft's Windows NT-based DNS Server offers connectivity between DNS and WINS. In addition to being a regular DNS server, the Windows NT DNS Server helps in checking the WINS database for a given host name that can't be found in the DNS database. For example, if a UNIX client is querying for a dynamic host, the DNS resolver software on the UNIX box can be configured to point to the Windows NT machine running the DNS service. The Windows NT machine will go through the DNS part of the resolution and then use the WINS database (located either on the same machine or on a remote machine) to resolve the dynamic name.

In Windows NT 4.0, Microsoft's implementation of DNS is tightly integrated with WINS. This enables non-WINS clients to resolve NetBIOS names by querying a DNS server.

Administrators can now remove any static entries for Microsoft-based clients in legacy DNS server zone files in favor of the dynamic WINS/DNS integration. For example, if a non-Microsoft-based client wants to get to a Web page on an HTTP server that is DHCP/WINS enabled, the client can query the DNS server, the DNS server can query WINS, and the name can be resolved and returned to the client. Previous to the WINS integration, there was no way to reliably resolve the name because of the dynamic IP addressing.

For more information, refer to Chapter 18, "Dynamic Host Configuration Protocol (DHCP)."

Analyzing Name Registration in WINS Systems

In a WINS system, all names are registered with a WINS server. The names are stored in a database on the WINS server which answers requests for name-to-IP address resolution based on the entries in this database. Redundancy and load balancing are maintained by allowing more than one WINS server in the WINS system. These servers replicate their database entries among one another periodically in order to maintain a consistent view of the name space.

Each name has an entry in the database. The name is owned by the WINS server it registered with and is a replica on all other WINS servers. Each entry has a state associated with it—the entry may be in the active, released, or extinct (also known as tombstone) state. Entries are also assigned a version ID. This number is used in the replication process.

The WINS system also allows the registration of static names. This enables the administrator to register names for servers running operating systems that are not capable of dynamic name registration. WINS distinguishes between dynamic and static entries. Static names are treated somewhat differently than dynamic names. If you register non-WINS computers as static entries, WINS clients will not register that name.

Resolving WINS/DNS Integration Problems

Some critics like to point out that the arrangement with WINS and DNS can lead to problems involving static DNS name registration and Dynamic Host Configuration Protocol (DHCP)-assigned IP addresses. Integrating WINS and DNS in Windows NT 4.0 helps a lot to solve these problems.

The first problem involves clients trying to reach a server in a network where the DNS administrator is far behind schedule on updating the DNS. Consider the network shown in Figure 12.1.

Suppose Terri tries to ping a new host recently installed (frenchy.paradise.com) on the corporate side of the network.

After checking its WINS server, Terri's computer (terri.paradise.com) checks its lmhosts and hosts files for a frenchy.paradise.com entry. If Terri has no entries in her LMHOSTS or HOSTS files and doesn't know the host's IP address, she queries her DNS server, earth.paradise.com. Terri's request will then reach mars.paradise.com, called the authoritative DNS server for the paradise.com domain.

If the DNS administrator hasn't yet manually updated the configuration files for paradise.com, Terri's DNS request fails. If Terri is a Windows client, however, she has another option: She can query her WINS server on wins1.paradise.com. If this WINS server has a mapping for \\FRENCHY, Terri can ping frenchy.paradise.com.

Figure 12.1: A typical LAN setup.

Another problem you can face when integrating WINS and DNS involves networks that manage IP addresses with DHCP. If frenchy.paradise.com has a static IP address of 199.103.10.41 and the DNS administrator manually creates an address (A) record in the configuration file to reflect that address, Terri can ping frenchy.paradise.com. If \\FRENCHY uses DHCP, however, the IP address is dynamic and can therefore change. So, when you are using DHCP, make sure your host is not also registered in DNS because the static DNS name registration of an IP address relies exclusively on manual updates.

In order to query a WINS database by DNS hosts (using Windows NT DNS Server), you must decide the zone of the DNS name space in an organization that will have dynamic (WINS-enabled) hosts. For example, if an organization has an Internet domain called taos.com assigned to it, then it should allocate a zone, say, interactive.taos.com, where the zone interactive will contain all the dynamic DHCP (WINS-enabled) clients.

The Windows NT-based DNS server can be designated as the primary DNS server for the interactive zone. The primary Windows NT DNS machine for the dynamic zone can also be a WINS server or can point to another WINS server on the network. The UNIX hosts can be configured to query the Windows NT DNS Server for all host names to be resolved in the interactive.taos.com part of the DNS name space. The Windows NT DNS Server will in turn use the WINS database (local or remote) to resolve the names in the dynamic zone.

Now consider another situation, with the same company, but with the dynamic NetBIOS hosts split among two zones, such as, interactive1.taos.com and interactive2.taos.com. In this situation, having one Windows NT-based DNS server as the primary host for both the interactive1 and interactive2 zones will help resolve dynamic NetBIOS host names by UNIX hosts following the process described in the previous section. Also, having a separate Windows NT DNS Server as primary for each dynamic zone will achieve the same result.

The Windows NT DNS Server, while using WINS to resolve dynamic names, won't know that a given dynamic NetBIOS host truly belongs to the interactive1 or interactive2 zone from a DNS perspective (because WINS is just a database of flat names). This granularity of difference becomes important while doing reverse address lookup, as discussed in a later section in this chapter, "Reverse Lookups with WINS."

Note: Although DNS dynamic update is not yet an IETF standard, some implementations already exist. Microsoft has chosen to wait until this is standardized in order to minimize impact on customers if changes are made before the standard is released.

Although WINS is actually based on IETF standards (RFC 1001, 1002), its NetBIOS roots have very limited acceptance by IETF and the UNIX community.

Enabling WINS Lookups

In addition to the basic Resource Records (A, PTR, NS, SOA, CNAME, MX, MB, MR, MG, HINFO, TXT, MINFO, RT, RP, X25, ISDN, WKS, AFSDB) that the DNS configuration files support, Windows NT 4.0 DNS includes a WINS lookup record. The lookup record is specific to Windows NT and solves the problems previously described by letting DNS query WINS (see a sample of WINS lookup record in the "Testing WINS Lookups" section).

As the PLACE.DOM sample file that Microsoft provides in the \SYSTEM32\DNS directory states, "the presence of a WINS record at the zone root instructs the name server to use WINS to look up any request for A records for names which are direct children of zone root, and which do not have A records in the zone file."

You can configure non-NetBIOS hosts to query Windows NT DNS Server for names in the zones that use WINS lookups. If the dynamic portion of the network exists in several zones, you can give each of those different zones its own DNS Server, or you can even set up one Domain Name Server as the primary master name server for each one of them.

WINS lookup can be enabled for a zone through the DNS Manager instead of requiring manual entry of the WINS record. This is accomplished by first selecting the zone with the secondary mouse button and clicking Properties. Then click the WINS Lookup tab. Check the Use WINS Resolution check box and type in the IP address of the WINS server that you want to use and click Add.

You can also add the WINS record to the BIND file and then import it as demonstrated in the following code:

A WINS lookup record might resemble the following:

PARADISE.DOM File

@ IN WINS earth.paradise.com

earth.paradise.com. IN A 198.25.40.20

mars.paradise.com. IN A 198.25.40.30

Notice that you can add multiple WINS server addresses, as shown in Figure 12.2.

You probably only need to use WINS lookup if you have non-Microsoft-based TCP/IP clients (UNIX clients) that need to resolve host name to IP addresses, for example, if there is a need in your organization to be able to use FTP or HTTP on your servers running Windows NT from non-Microsoft-based clients.

If you have a zone configured to do WINS lookup, then all DNS servers that are authoritative for that zone need to be able to do WINS lookup or you will have intermittent behavior.

In order to easily add the Microsoft WINS/DNS lookup to a legacy DNS architecture, you have to create a new DNS subdomain in your company and have the Windows NT-based primary and secondary servers enabled to do WINS lookups in this domain. For example, there is a paradise.com domain and a mydomain.paradise. com domain in Figure 12.3. All of the Microsoft-based clients will register with the WINS server in the mydomain.paradise.com domain.

Figure 12.2: Adding WINS lookup to a DNS zone.

Figure 12.3: A domain with a subdomain just for WINS.

WINS lookup is always done on a DNS-zone basis. A query to a DNS server for ericr.taos.com would go to the WINS server if the DNS server that had the WINS lookup record was authoritative for zone taos.com. But a query for ericr.france.taos.com would not go to that same WINS server.

Setting the Time-to-Live for WINS

If you are using a WINS record, the time-to-live (TTL) in the SOA record doesn't affect WINS. The WINS TTL is configured, as shown in Figure 12.4, in the Advanced Zone Properties dialog box under the WINS Lookup tab. To get to the Advanced Zone Properties dialog box, select the zone with the secondary mouse button and click Properties. Then click the WINS Lookup tab. Check the Use WINS Resolution check box and then click the Advanced Button.

When an IP address or host name gets resolved via WINS, the address is cached for the WINS Cache Timeout Value. If this address is ever forwarded to another DNS server, the WINS Cache Timeout Value TTL is sent.

Figure 12.4: Configuring the WINS time-to-live (TTL) value.

If your data doesn't change much, then you will want to set your TTL high. Keep in mind that you can set the TTL on individual records as well.

If the TTL on an individual Resource Record's address is lower or higher than the TTL in the SOA record, the individual RR's TTL takes precedence.

Testing WINS Lookups

Considering the network and the computers shown in Figure 12.1, imagine that Terri tries to reach joanne.paradise.com. If she doesn't find a listing for joanne.paradise.com in her LMHOSTS or HOSTS files, she queries her DNS server, earth.paradise.com, which queries Joanne's DNS server mars.paradise.com. So far, she can reach only the DNS at mars.paradise.com looking for an A record for joanne.paradise.com. If that A record is not there, Judy's request fails.

If the DNS administrator of mars.paradise.com adds a WINS lookup record for wins2.paradise.com to the configuration files, DNS can query the WINS database for joanne.paradise.com and respond to Terri's request. If joanne.paradise.com is registered in the corporate WINS database on wins2.paradise.com, Terri can ping joanne.paradise.com successfully.

Notice with host name resolution, if DNS doesn't have an A record for joanne.paradise.com, Terri tries her WINS server, wins1.paradise.com, which doesn't know anything about this. Now, consider if DNS on \\MARS doesn't have an _A record for joanne.paradise.com, \\MARS tries its registered WINS server, wins2.paradise.com. This redirection takes the burden off Terri's WINS server and puts the load on the paradise.com corporate network WINS server where it belongs.

This DNS/WINS integration solves the first big problem of the busy DNS administrator not updating the name registration. By removing most A records from the DNS server and it to the local WINS Server, you can make the DNS server work as if it were dynamically updated.

The same approach also solves the problem associated with DHCP-assigned IP addresses. Because in this particular case, the WINS server updates the WINS database when the DHCP-enabled client's IP address changes. Then, the system picks up this change when someone sends a query to the Domain Name Server for a name not in the DNS database.

The Microsoft DNS server works hand in hand with the Microsoft WINS server and provides a great deal of interoperability. To provide this interoperability, a new record was defined as part of the zone database file. The WINS record is specific to Windows NT and may be attached only to the zone root domain. The presence of a WINS record instructs the name server to use WINS to look up any requests for hosts in the zone root that do not have static addresses in the IP database. This functionality is particularly useful for UNIX-based clients that need to contact DHCP/WINS- enabled clients via Internet Protocol.

Reverse Lookups with WINS

Although WINS was not constructed to provide reverse lookup capabilities, this functionality can still be accomplished for DHCP/WINS-enabled clients when using Microsoft's DNS server. The presence of a WINS-R record at the zone root instructs the name server to use a NetBIOS node adapter status lookup for any reverse lookup requests for IP addresses in the zone root that are not statically defined with PTR records. The following is a sample of a WINS-R record:

Using a real-world domain, this would appear as

@ IN WINS-R taos.com.

You use reverse address lookups—the process of obtaining the DNS domain name of a host, given its IP address—for login, printing, and firewall applications. The process tends to complicate WINS and DNS integration. Because the WINS database contains flat names, reverse lookup functionality needs a mechanism for associating a dynamic NetBIOS name to a DNS domain name.

Consider the example where you have two dynamic zones (paradise1 and paradise2) in a DNS name space with WINS-enabled clients. The WINS system in this case will be completely replicated and synchronized. It is impossible to associate the dynamic NetBIOS hosts to a specific DNS zone by looking at the WINS database.

If all the dynamic hosts are located in a single DNS zone in a company, it's easier to devise a method to append the result of a reverse address lookup of a WINS database with a default DNS domain name (this helps to achieve reverse lookup functionality with dynamic hosts). It is recommended to restrict the dynamic NetBIOS hosts to a single DNS zone in a company to achieve complete DNS/WINS integration with the current tools available.

Name resolution integration between WINS and DNS can be done with the proper design.

You need to know that having a single dynamic zone (a zone with dynamic NetBIOS hosts) in an organization's DNS name space ensures almost complete DNS-to-WINS integration (taking into consideration that reverse address lookup is slated to be added to the Windows NT DNS Server for WINS hosts). This may change if any modifications are done to the WINS replication process in order for DNS-WINS integration to have multiple dynamic zones.

It remains a challenge, however, to achieve reverse address lookups of dynamic NetBIOS hosts (belonging to multiple DNS zones) to map to a unique DNS domain name.

WINS reverse lookups can be enabled for a zone through the DNS Manager instead of requiring manual entry of the WINS-R record. This is accomplished by selecting the appropriate in-addr.arpa zone with the mouse button and clicking Properties. Then click the WINS Reverse Lookup tab. Check the Use WINS Reverse Lookup check box, as shown in Figure 12.5, and type in the DNS Host Domain to be appended to the NetBIOS name before returning a response to the resolver.

The Microsoft DNS server can be configured to not send WINS records to secondary servers. This is necessary if you have a mixture of Microsoft- and UNIX-based DNS servers because UNIX-based DNS servers do not have the capability to do WINS lookups.

However, there are other things you need to know. DNS and WINS integration does not establish an efficient DNS reverse lookup. Both the DNS server and the host being located are involved when a reverse lookup is requested for a WINS client because the DNS server does a NetBIOS node adapter status lookup to resolve the IP address to a name. DNS-only reverse lookups are more efficient.

Figure 12.5: Establishing a reverse WINS lookup.

The following is a sample of tracing a reverse name lookup using the PING -a [IP address] command:

Ping -a 198.25.40.20
DNS: 0x1:Std Qry for 20.40.25.198. in-addr.arpa of type Dom. name ptr on 
Ê
class INET addr.
DNS: Query Identifier = 1 (0x1)
DNS: DNS Flags = Query, OpCode-Std Qry, RD Bits Set, RCode-No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 0 (0x0)
DNS: Name Server Count = 0 (0x0)
DNS: Additional Records Count = 0 (0x0)
DNS: Question Section: 20.40.25.198.in-addr.arpa of type Dom. name ptr on 
Ê
class INET addr.
DNS: Question Name: 20.40.25.198.in-addr.arpa
DNS: Question Type = Domain name pointer
DNS: Question Class = Internet address class
You can notice that the Question name is the IP address backwards 
Ê
20.40.25.198.in-addr.arpa of type PTR.
DNS: 0x1:Std Qry Resp. for 20.40.25.198.in-addr.arpa of type Dom. name 
Ê
ptr on class INET addr.
DNS: Query Identifier = 1 (0x1)
DNS: DNS Flags = Response, OpCode-Std Qry, AA RD RA Bits Set, RCode-No 
Ê
error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 1 (0x1)
DNS: Name Server Count = 0 (0x0)
DNS: Additional Records Count = 0 (0x0)
DNS: Question Section: 20.40.25.198.in-addr.arpa of type Dom. name ptr on 
Ê
class INET addr.
DNS: Question Name: 20.40.25.198.in-addr.arpa
DNS: Question Type = Domain name pointer
DNS: Question Class = Internet address class
DNS: Answer section: 20.40.25.198.in-addr.arpa of type Dom. name ptr on 
Ê
class INET addr.
DNS: Resource Name: 20.40.25.198.in-addr.arpa
DNS: Resource Type = Domain name pointer
DNS: Resource Class = Internet address class
DNS: Time To Live = 86400 (0x15180)
DNS: Resource Data Length = 23 (0x17)
DNS: Pointer: frenchy.paradise.com

This sends the IP address to the DNS server and asks for the host name associated with the NetBIOS name. Remember that if the DNS server didn't have this name in its table, the DNS server will actually do an Adapter Status on the IP address rather than going to WINS. However, that's only if you have the Use Wins Reverse Lookup check box checked in the properties of the *in-addr.arpa zone.

Multihomed Servers

This is similar to a unique name in that it is the WINS Client's computer name; however it can have up to 25 addresses and is for use by multihomed systems. A multihomed system is a system with more than one network card and more than one IP address.

warning: Be aware that extending network bandwidth in your server has some trade-offs. Extra overhead and I/O processing (such as interrupt handling) come into play when you add cards.

Each PCI network interface card you add is another interrupt that the CPU must handle to service I/O requests. More CPU interruptions result in slower processing. Adding bandwidth increases the amount of information the system must process and consumes extra resources such as memory and CPU time. You may need to augment these resources to maintain your desired performance level.

A multihomed server is a server with multiple network interface cards (NICs). A multihomed server can be defined by a single, unique name with which multiple IP addresses are associated.

Mapping IP Addresses for Multihomed Servers

You can provide multihomed name-to-IP-address mappings in the LMHOSTS file by creating entries that are specified by using the keyword #MH (MultiHomed). An #MH entry associates a single, unique NetBIOS computer name to an IP address. You can create multiple entries for the same NetBIOS computer name for each NIC in the multihomed server, up to a maximum of 25 different IP addresses for the same name. That means the administrator will need 5 NICs (maximum) for a multihomed server.

The format of the LMHOSTS entry that is used to specify name-to-IP-address mappings for multihomed servers is the same as the other keyword entries. For example, the entries required to map a name to IP address for a multihomed server with two NICs are as follows:

38.168.20.106 Sales #sales server NIC 1

38.168.20.107 Sales #sales server NIC 2

You can set up to five IP addresses for each installed NIC. From the Control Panel, double-click the Network icon, then click the Protocols tab; from the Protocols tab select TCP/IP Protocols, then click the Properties button; on the IP Address tab, click Advanced, and add the IP addresses and subnet mask, as shown in Figure 12.6.

Figure 12.6: Advanced IP Addressing.

You can also add those IP addresses to a network card by modifying the Registry. This method of adding IP addresses through the Registry is a way around the limit of 5 IP addresses in the control panel.

Use the Registry Editor (REGEDT32.EXE) to add your IP addresses and subnet masks, as follows:

Start REGEDT32.EXE and locate the following Registry subkey: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services<Adapter Name>\Parameters\Tcpip
Find the IP Address value and double-click it.
The Multi-String Editor dialog box should appear with the IP address selected. Type each additional IP address on a new line within the dialog box, then click OK. For example:

38.168.20.106

38.168.20.107

38.168.20.108
Find the SubnetMask value and double-click it.
The Multi-String Editor dialog box should appear with the Subnet Mask selected. Enter each additional subnet mask on a new line within the dialog box, then click OK. For example:

255.255.255.0

255.255.255.0

255.255.255.0

important: The order of the IP addresses and subnet masks must cor-respond.
Exit REGEDT32.EXE.
Exit Windows NT and reboot your computer.

Make sure to have all of the IP addresses specified in the Registry bound to your network interface cards.

warning: Be aware of using the Registry Editor very carefully. Any incorrect use of the Registry can cause serious problems that may require you to reinstall your operating system!

Directing Queries in Multihomed Server Systems

DNS can operate on all the NICs of a mutihomed server if you don't specify any particular IP addresses. Actually, this could be the first reason to install multiple network cards in a DNS server. But it could just as well be because you want to specify which NICs will accept DNS queries.

To do so, in the Server List, right-click the Server icon. Choose Properties, and select Interfaces tab. In the DNS Server IP Addresses field (see Figure 12.7), type the IP addresses for each NIC that you want to enable for DNS traffic.

NetBIOS over TCP (NetBT) only binds to one IP address per physical network interface. From the NetBT viewpoint, a computer is multihomed only when it has more than one NIC installed. When a name registration packet is sent from a multihomed computer, it is flagged as a multihomed name registration so that it will not conflict with the same name being registered by another interface in the same computer.

If a broadcast name query is received by a multihomed computer, all NetBT/interface bindings receiving the query will respond with their addresses, and by default the client will choose the first response and connect to the address supplied by it. This behavior can be controlled by the RandomAdapter Registry parameter.

Figure 12.7: IP addresses for a multihomed DNS server.

When a directed name query is sent to a WINS server, the WINS server responds with a list of all IP addresses that were registered with WINS by the multihomed computer.

Choosing the best IP address to connect to on a multihomed computer is a client function. The following algorithm is employed, in the order listed:

If one of the IP addresses in the name query response list is on the same logical subnet as the calling binding of NetBT on the local computer, then that address is selected. If more than one of the addresses meet this criteria, one is picked at random from those that match.
If one of the IP addresses in the list is on the same logical subnet as any binding of NetBT on the local computer, then that address is selected. If more than one of the addresses meet this criteria, one of these is picked at random.
If none of the IP addresses in the list is on the same subnet as any binding of NetBT on the local computer, then an address is selected at random from the list.

This algorithm provides a reasonably good way of balancing connections to a server across multiple NICs, while still favoring direct connections when they are available.

warning: Keep in mind, however, that you need to have computers running at least Windows NT 4.0 Service Pack 2; otherwise some problems can occur. If the IP address chosen from the list does not respond, the connection attempt will fail. In some cases, another attempt to connect the resource may succeed; however, the user or application may receive an error and the retries may need to be done manually.

Connecting to Multihomed Server IP Addresses by Preference

Service Pack 2 includes an enhancement to NetBT. NetBT still uses the algorithm previously outlined to choose a "best" IP address to connect to on a multihomed computer; however, now NetBT retains the list of addresses and orders them by preference. NetBT attempts to ping each of the addresses in the list in order, until one of them responds. Two ping attempts are made for each address, with a two-second wait for a response after each attempt. If there is a successful response to one of the pings, then a TCP connection and NetBIOS session are established to that address.

If none of the addresses respond to the ping attempts, then NetBT will revert to the old behavior, and attempt to establish a TCP connection to the best address in the list.

In addition, if a session is already in existence and the network interface responsible for the session on the multihomed computer fails, the failure will be detected and a new session will be established over one of the working interfaces, provided that one exists. The status of open files may not be preserved because file handles will be invalidated when the old session is deleted.

This feature is only specific to NetBT sessions, and does not apply to TCP connections used by other protocols or interfaces, such as Windows Sockets.

Connecting to Multihomed Servers with Disabled NICs

Service Pack 2 also includes an enhancement to NetBT that improves the capability to connect to multihomed computers even when one or more of the NICs are disabled. There are currently no plans to port this enhancement back to prior versions of Windows NT.

On a computer running Windows NT with multiple IP addresses assigned to the same network interface card, resolving the computer's host or NetBIOS name will return the last IP address listed in the Network Control Panel, Advanced TCP/IP Properties sheet, rather than the first address listed. All other computers on the network that resolve this name will correctly get the first IP address listed.

This can cause problems with applications that are running on a computer that performs a lookup of its own host name (such as Web servers).

If you are using DNS for name resolution, however, you can add an additional A record for the same computer, with a different name. For example, if your computer name is listed in DNS as SIRF_NT4, you may also want to add an entry in DNS for WWW that refers to the same IP address. In this case, when you type ping WWW, the name is not resolved locally, but rather at the DNS server, and the correct IP address will be indicated in the reply.

The following is an example of this configuration:

HOST name = SIRF_NT4

Assigned IP Addresses #1= 38.168.20.106

Assigned IP Addresses #2= 38.168.20.107

Assigned IP Addresses #3= 38.168.20.108

If you are at SIRF_NT4 and type ping SIRF_NT4, your reply will indicate the 38.168.20.108 address.

If you are at another computer on the network and type ping SIRF_NT4, your reply will indicate the 38.168.20.106 address.

Fortunately, this problem has been corrected in the latest Microsoft Windows NT 4.0 U.S. Service Pack. (Check the Microsoft Web site at https://support.microsoft.com/gp/DOWNLOADOVER .)

Summary

This chapter explained how to integrate WINS and DNS to support environments with mixed name types. You also learned how to test lookups and how to establish reverse lookups for clients that are registered via WINS and not directly via DNS. Chapter 13, "Configuring Clients," goes the next step to show you how to set up clients to properly take advantage of the name resolution features in WINS and DNS as separate services, and as an advanced integrated service, as this chapter illustrated.

About The Authors

Mike Masterson is currently the Director of Technical Services at Taos Mountain, Silicon Valley's largest provider of system administration services. A Microsoft Certified Professional, he is also the founder and president of the Silicon Valley NT Engineering Association.

Herman Knief is a Senior Technical Advisor at Taos Mountain. He's provided system and network administration services for various clients, including Netcom and Bay Networks.

Eric Roul is a Taos Mountain Information Technology Consultant with several certifications: Microsoft Certified Systems Engineer, Citrix Certified Professional, Compaq and HP Certified Professional.

Scott Vinick is a Systems and Network Administrator with Taos Mountain, Inc. in the San Francisco Bay area. Scott has worked on Windows NT cross-platform projects for a number of companies, helping them migrate from or integrate with UNIX, Macintosh, and Novell-based networks.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English only.

Click to order