Windows Server 2012 R2 Inside Out: Networking with TCP/IP

Understanding name resolution

Although IP addressing works well for computer-to-computer communications, it doesn’t work so well when you want to access resources. Could you imagine having to remember the IP address of every computer you work with? That would be difficult, and it would make working with computers on networks a chore. This is why computers are assigned names. Names are easier to remember than numbers—at least for most people.

When a computer has a name, to access it you can type that name rather than its IP address. This name resolution doesn’t happen automatically. In the background, a computer process translates the computer name you type into an IP address that computers can understand. Windows Vista and later versions natively support three name-resolution systems:

• Domain Name System (DNS)
• Windows Internet Naming Service (WINS)
• Link-Local Multicast Name Resolution (LLMNR)

The sections that follow examine these services.

Domain Name System

DNS provides a distributed database that enables computer names to be resolved to their corresponding IP addresses. When working with DNS, you need to understand what is meant by the terms “host name,” “domain name,” “fully qualified domain name,” and “name resolution.”

Host names

A host name identifies an individual host in DNS. Ordinarily, you might call this a computer name. The difference, however, is that there is an actual record in the DNS database called a host record that corresponds to the computer name and details how the computer name is used on the network. Host names can be assigned by administrators and other members of the organization.

Domain names

A domain name is the logical identity of a network in DNS. Domain names follow a specific naming scheme that is organized in a tree-like structure. Periods (dots) are used to separate the name components or levels within the domain name.

The first level of the tree is where you find the top-level domains. Top-level domains describe the kinds of networks that are within their domain. For example, the .edu top-level domain is for educational domains, the .gov top-level domain is for U.S. government domains, and the .com top-level domain is for commercial domains. As you can see, top-level domains generally are organized by category. There are also top-level domains organized geographically, such as .ca for Canada and .uk for United Kingdom.

The second level of the tree is where you find parent domains. Parent domains are the primary domain names of organizations. For example, City Power & Light’s domain name is cpandl.com. The domain name cpandl.com identifies a specific network in the .com domain. No parent domain can be used on the public Internet without being reserved and registered. Name registrars, such as Network Solutions, charge a fee for this service.

Additional levels of the tree belong to individual hosts or subsequent levels in the organization’s domain structure. These subsequent levels are referred to as child domains. For example, City Power & Light might have Tech, Support, and Sales child domains, which are named tech.cpandl.com, support.cpandl.com, and sales.cpandl.com, respectively.

Fully qualified domain names

All hosts on a TCP/IP network have what is called a fully qualified domain name (FQDN). The FQDN combines the host name and the domain name and serves to uniquely identify the host. For a host named CPL05 in the cpandl.com domain, the FQDN would be cpl05.cpandl.com. For a host named CORPSVR17 in the tech.cpandl.com domain, the FQDN would be corpsvr17.tech.cpandl.com.

Name resolution

Name resolution is the process by which host names are resolved to IP addresses and vice versa. When a TCP/IP application wants to communicate with another host on a network, it needs the IP address of that host. Typically, the application knows only the name of the host it is looking for, so it has to resolve that name to an IP address.

To do this, the application first looks in its local DNS cache of names that it has previously looked up. If the name is in this cache, the IP address is found without having to look elsewhere and the application can connect to the remote host. If the name isn’t in the cache, the application must ask the network’s DNS server or servers to help resolve the name. These servers perform a similar lookup. If the name is in their database or cache, the IP address for the name is returned. Otherwise, the DNS server has to request this information from another DNS server.

That’s the way it works—the simplified version at least. Most of the time, a TCP/IP application has the host name and needs to find the corresponding IP address. Occasionally, a TCP/IP application has the IP address and needs to find the corresponding host name. To do this, the application must perform a reverse lookup, so instead of requesting an IP address, the application requests a host name using the IP address.

The application first looks in its local cache of information that it has previously looked up. If the IP address is in this cache, the name is found without having to look elsewhere and the application can perform whichever tasks are necessary. If the IP address isn’t in the cache, the application must ask the network’s DNS server or servers to help resolve the IP address. These servers perform a similar lookup. If the IP address is in their reverse lookup database or cache, the name for the IP address is returned. Otherwise, the DNS server has to request this information from another DNS server.

Windows Internet Naming Service

Windows Internet Naming Service (WINS) is a name-resolution service that resolves computer names to IP addresses. For example,  using WINS, the computer name COMPUTER84 could be resolved to an IP address that enables computers on a Microsoft network to find one another and transfer information. WINS is needed to support applications that use Network Basic Input/Output System (NetBIOS) over TCP/IP, such as Exchange Server 2003, the .NET command-line utilities, and network browsing for users in pre–Windows Server 2008 environments. If you don’t have NetBIOS applications on the network or pre–Windows Server 2008 infrastructure, you don’t need to use WINS.

WINS is designed for client/server environments in which WINS clients send queries to WINS servers for name resolution and WINS servers resolve the queries and respond. To transmit WINS queries and other information, computers use NetBIOS. NetBIOS is an interface developed to allow applications to perform basic network operations, such as sending data, connecting to remote hosts, and accessing network resources.

NetBIOS computer names can be up to 15 characters long. They must be unique on the network and can be looked up on a server called a WINS server. WINS supports both forward lookups (NetBIOS computer name to IP address) and reverse lookups (IP address to NetBIOS computer name).

NetBIOS applications rely on WINS or the local LMHOSTS file to resolve computer names to IP addresses. On early Windows networks, WINS was the primary name-resolution service available. On current Windows networks, DNS is the primary name-resolution service and WINS has a different function. This function is to allow applications written to the NetBIOS interface to browse lists of resources on the network and to allow systems to locate NetBIOS resources. To enable WINS name resolution on a network, you need to configure WINS clients and servers. When you configure WINS clients, you tell the clients the IP addresses of WINS servers on the network. Using the IP address, clients can communicate with WINS servers anywhere on the network, even if the servers are on different subnets. WINS clients can also communicate using a broadcast method in which clients broadcast messages to other computers on the local network segment requesting their IP addresses. Because messages are broadcast, the WINS server isn’t used. Any non-WINS clients that support this type of message broadcasting can also use this method to resolve computer names to IP addresses.

If you are using applications that rely on NetBIOS over TCP/IP, your organization must set up WINS. If you are currently using WINS and don’t have applications that rely on NetBIOS over TCP/IP, you can eliminate the need for this service by moving workstations and servers to currently supported versions of Windows.

Link-Local Multicast Name Resolution

Link-Local Multicast Name Resolution (LLMNR) fills a need for peer-to-peer name-resolution services for devices with IPv4, IPv6, or both addresses, enabling IPv4 and IPv6 devices on a single subnet without a WINS or DNS server to resolve each other’s names—a service that neither WINS nor DNS can fully provide. Although WINS can provide NetBIOS name-resolution services for IPv4, it does not support IPv6 addresses. Although DNS supports IPv4 and IPv6 addresses, it depends on designated servers to provide name-resolution services.

Windows Vista and later support LLMNR. LLMNR is designed for both IPv4 and IPv6 clients when other name-resolution systems are not available, such as on a small-office or ad hoc network. LLMNR can also be used on corporate networks where DNS services are not available.

LLMNR is designed to complement DNS by enabling name resolution in scenarios in which conventional DNS name resolution is not possible. Although LLMNR can replace the need for WINS in cases in which NetBIOS is not required, LLMNR is not a substitute for DNS because it operates only on the local subnet. Because LLMNR traffic is prevented from propagating across routers, it can’t accidentally flood the network.

As with WINS, you use LLMNR to resolve a host name, such as COMPUTER84, to an IP address. By default, LLMNR is enabled on all computers running Windows Vista and later, and these computers use LLMNR only when all attempts to look up a host name through DNS fail. As a result, name resolution works like this for Windows Vista and later:

1. A host computer looks up the name in its internal name cache. If the name is not found in the cache, the host sends a query to its configured primary DNS server. If the host computer does not receive a response or receives an error, it tries each configured alternate DNS server in turn. If the host has no configured DNS servers or fails to connect to a DNS server without errors, name resolution fails over to LLMNR.
2. The host computer sends a multicast query over User Datagram Protocol (UDP) requesting the IP address for the name being looked up. This query is restricted to the local subnet (also referred to as the local link).
3. Each computer on the local link that supports LLMNR and is configured to respond to incoming queries receives the query and compares the name to its own host name. If the host name is not a match, the computer discards the query. If the host name is a match, the computer transmits a unicast message containing its IP address to the originating host.

You can also use LLMNR for reverse mapping. With reverse mapping, a computer sends a unicast query to a specific IP address, requesting the host name of the target computer. An LLMNR-enabled computer that receives the request sends a unicast reply containing its host name to the originating host.

LLMNR-enabled computers are required to ensure that their names are unique on the local subnet. In most cases a computer checks for uniqueness when it starts, when it resumes from a suspended state, and when you change its network-interface settings. If a computer has not yet determined that its name is unique, it must indicate this condition when responding to a name query.

By default, LLMNR is automatically enabled on computers running Windows Vista and later. You can disable LLMNR through registry settings. To disable LLMNR for all network interfaces, create and set the following DWORD value to 0 (zero): HKLM/SYSTEM/CurrentControlSet/Services/Dnscache/Parameters/EnableMulticast. To disable LLMNR for a specific network interface, create and set the following DWORD value to 0 (zero): HKLM/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/AdapterGUID/EnableMulticast, where AdapterGUID is the globally unique identifier (GUID) of the network interface adapter for which you want to disable LLMNR.

You can reenable LLMNR at any time by setting these DWORD values to 1. You also can manage LLMNR through Group Policy.