Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

Windows Server 2003 : Determining Name Resolution Requirements

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
5/21/2011 11:13:09 AM
Name resolution is an essential function on all TCP/IP networks, and the network infrastructure design process includes a determination of what names your computers will use, and how those names will be resolved into Internet Protocol (IP) addresses. As with IP addressing itself, the names you choose for your computers are affected by your network’s interaction with the Internet and by the applications the computers are running.

What Is Name Resolution?

TCP/IP communications are based on IP addresses. Every IP datagram transmitted by a TCP/IP computer contains a source IP address, which identifies the computer sending the datagram, and a destination IP address, which identifies the computer that is to receive it. Routers use the network identifiers in the IP addresses to forward the datagrams to the appropriate locations, eventually getting them to their final destinations.

Off the Record

Computers are able to read and process IP addresses easily, but human beings unfortunately cannot. It is not practical to expect people to remember the 32-bit IP addresses associated with Web sites, file system shares, and e-mail addresses, so it has become common practice to assign friendly names to these resources. This is why you use names like www.adatum.com for Internet Web sites, access the computers on your network by browsing among a list of names instead of IP addresses, and address e-mail messages to marklee@adatum.com, rather than to marklee@

Friendly names are only for use by people; they do not change the way the TCP/IP computers communicate among themselves. Whenever you use a name instead of an address in an application, the computer must convert the name into the proper IP address before initiating communications with the target computer. This name-to-address conversion is called name resolution. When you type the name of an Internet server in your Web browser, the first thing your computer does is resolve that name into an IP address. Once the computer has the address of the Internet server, it can send its first message, requesting access to the resource you specified in the browser.


Although it is possible, in some cases, for computers themselves to resolve names into IP addresses, most of the time the computer sends the name to another system on the network and receives a response containing the IP address associated with the name. The resource that the computer uses to resolve the name depends on the type of name and the application that generates the name resolution request.

What Types of Names Need to Be Resolved?

To design a name resolution strategy for an enterprise network, you must know the types of names that the computers will have to resolve. Networks running Microsoft Windows operating systems use two basic types of names for computers and other resources: DNS names and Network Basic Input/Output System (NetBIOS) names. DNS is the name resolution mechanism that computers use for all Internet communications and for private networks that use the Active Directory directory service provided with Windows Server 2003 and Windows 2000 Server.

All the names that you associate with the Internet, such as the names of Internet servers in Uniform Resource Locators (URLs) and the domain names in e-mail addresses, are part of the DNS namespace and are resolvable by DNS name servers. All Internet service providers (ISPs) have DNS servers, which they make available to their customers, but Windows Server 2003 includes its own DNS server, which you can deploy on your private network.

Off the Record

Active Directory is also based on DNS, and the names you assign to computers on an Active Directory network can also be resolved by DNS servers, but you must deploy a DNS on your own network for this purpose.

Windows operating systems prior to Windows 2000 used NetBIOS names to identify the computers on the network. The NetBIOS name of a Windows system is the computer name that you assign it during the operating system installation. Windows includes several different name resolution mechanisms for NetBIOS names, and chief among these is WINS.

Off the Record

Even though Windows operating system releases starting with Windows 2000 rely on Active Directory instead of NetBIOS names, all Windows operating system versions still include a WINS client, and Windows Server 2003 and Windows 2000 Server still include the WINS server, so that they can interact with computers on the network running the older operating systems.

If all the computers on your network are running Windows 2000 and later versions, and Active Directory has been installed, the network is not using NetBIOS names, and you don’t have to run WINS servers. You can also disable the NetBIOS Over TCP/IP (NetBT) protocol on your computers, using the controls in the NetBIOS Settings box, found in the WINS tab in the computer’s Advanced TCP/IP Settings dialog box.

Using Host Tables

In the 1970s, when the Internet was still an experimental network called the ARPANET, system administrators assigned friendly names to their computers, which they called host names. A host name is a single word that administrators used to represent the computer’s IP address in applications and other references. To resolve host names into IP addresses, every computer had a host table, which was simply a text file called hosts that contained a list of host names and their equivalent IP addresses, similar to the following list:      server1     # source server client23 # x client host localhost

The first column of the host table contained IP addresses, the second column contained host names, and the third column (including everything after the # symbol) contained the administrator’s comments, which the computer ignored when processing the table. When an application encountered a reference to a host name, it consulted the computer’s hosts file, searched for the name, and read the IP address associated with that name. Every TCP/IP computer still contains a host table, although few of them actually use it anymore. On a computer running Windows Server 2003, the host table is called Hosts, and it is located in the %Systemroot%\System32\Drivers\Etc folder.

Because the ARPANET was quite small when the host table was invented, the table was not too large, and the administrators did not have to change it very often. As the ARPANET grew, however, so did the number of computers on the network, and so did the size of the host table. Soon, the network grew to the point that host tables became impractical. To address these problems, development began on what came to be known as the DNS.

Using the DNS

At its core, the DNS is still a list of names and their IP addresses, but instead of storing all the information in one place, the DNS distributes it among servers all over the Internet. The DNS consists of a hierarchical namespace, a collection of name servers, and DNS clients called resolvers. Each name server is the authoritative source for a small part of the namespace. When DNS servers receive name resolution requests from resolvers, they check their own records for the IP address associated with the requested name. If the server does not have the information needed, it passes the request to other DNS servers, until it reaches the authoritative server for that name. That authoritative server is the ultimate source for information about that name, so the IP address it supplies is considered definitive. The authoritative server returns a reply containing the IP address to the requesting server, which in turn relays it back to the resolver, as shown in Figure 1.

Figure 1. DNS servers relay requests and replies to other DNS servers

For the DNS to function in this manner, it was necessary to divide the namespace in a way that would distribute it among many servers. It was also necessary to devise a methodology that would enable a server to systematically locate the authoritative source for a particular name. To accomplish these goals, the developers of the DNS created the concept of the domain. A domain is an administrative entity that consists of a group of hosts (which are usually computers). When a DNS server is the authoritative source for a domain, it possesses information about the hosts in that domain, in the form of resource records. The most common resource record is the Host (A) resource record, which consists of the host name and its equivalent IP address.

Off the Record

In addition to Host (A) resource records, DNS servers also maintain other types of resource records that contain additional information about the hosts.

Therefore, the full name for a computer in the DNS consists of two basic parts: a host name and a domain name. Note the similarity between the DNS name and an IP address, which also consists of two parts: a network identifier and a host identifier. The host name, as in the days before DNS, is a single word that identifies a specific computer. Unlike host names in the early days, however, current host names do not have to be unique in the entire namespace; a host name only has to be unique in its domain.

Understanding Domains

The domain name part of a DNS name is hierarchical, and consists of two or more words, separated by periods. The domain namespace takes the form of a tree that, much like a file system, has its root at the top. Just beneath the root is a series of top-level domains, and beneath each top-level domain is a series of second-level domains.

At minimum, the complete DNS name for a computer on the Internet consists of a host name, a second-level domain name, and a top-level domain name, written in that order and separated by periods. The complete DNS name for a particular computer is called its fully qualified domain name (FQDN).

Understanding FQDN Notation

Unlike an IP address, which places the network identifier first and follows it with the host, the notation for an FQDN places the host name first, followed by the domain name, with the top-level domain name last. For example, in the FQDN www.adatum.com, www is a host (or computer) in the adatum.com domain. In the adatum.com domain name, com is the top-level domain and adatum is the second-level domain. Technically, every FQDN should end with a period, representing the root of the DNS tree, as follows:


However, the period is rarely included in FQDNs today.

Name Resolution and the Domain Hierarchy

The hierarchical nature of the DNS domain namespace is designed to make it possible for any DNS server on the Internet to use a minimum number of queries to locate the authoritative source for any domain name, as shown in Figure 2. This efficiency is possible because the domains at each level are responsible for maintaining information about the domains at the next lower level. For example, if a DNS server receives a name resolution request for www.adatum.com from a client resolver, and the server has no information about the adatum.com domain, it forwards the request to one of the root name servers on the Internet. This is called a referral.

Figure 2. The DNS name resolution process


The root name servers are the highest-level DNS servers in the namespace, and they maintain information about the top-level domains. Software developers preconfigure all DNS server implementations with the IP addresses of multiple root name servers, so they can send referrals to these servers at any time.

On receiving the request, the root name server reads the top-level domain in the requested name, in this case com, and returns a resource record that contains the IP addresses of the authoritative servers for the com domain to the requesting server. With this information, the requesting server can now send a duplicate of the client request to the authoritative server for the top-level, or com, domain. The top-level domain server reads the requested name and replies with a resource record that contains the IP addresses of the authoritative servers for the second-level domain, in this case adatum.

The requesting server can now forward its request to the server that is ultimately responsible for the adatum.com domain. The adatum.com server reads the requested name and replies by sending the resource record for the host called www to the requesting server. The requesting server can now relay the resource record to the client that originally requested the resolution of the www.adatum.com FQDN. The client reads the IP address for www.adatum.com from the resource record and uses it to send packets to that server.

Reverse Name Resolution

The name resolution process described in the previous section is designed to convert DNS names into IP addresses. However, there are occasions when it is necessary for a computer to convert an IP address into a DNS name. This is called a reverse name resolution. Because the domain hierarchy is broken down by names, there is no apparent way to resolve an IP address into a name using iterative queries, except by forwarding the reverse name resolution request to every DNS server on the Internet, which is obviously impractical.

To address this problem, the developers of the DNS created a special domain called in-addr.arpa (described in RFC 1035, “Domain Implementation and Specification”), specifically designed for reverse name resolution. The in-addr.arpa second-level domain contains four additional levels of subdomains. Each of the four levels consists of subdomains that are named using the numerals 0 to 255. For example, beneath in-addr.arpa, there are 256 third-level domains, numbered from 0 to 255. Each of those 256 third-level domains has 256 fourth-level domains beneath it, also numbered from 0 to 255. Each fourth-level domain has 256 fifth-level domains and the fifth-level domains have 256 sixth-level domains, as shown in Figure 3.

Figure 3. The DNS reverse lookup domain

Using this hierarchy, it is possible to express an IP address as a domain name, and to create a resource record in the domain that contains the name associated with the IP address. For example, to resolve the IP address into a name, a DNS server would locate a domain called in the usual manner and read the contents of a special type of resource record called a Pointer (PTR) resource record to determine the name associated with that IP address. The IP address is reversed in the domain name because in IP addresses, the host identifier is on the right and in FQDNs, the host name is on the left.

Speeding Up the DNS

Although this might seem like a long and tedious process, the DNS name resolution procedure usually occurs in a few seconds or less. Several DNS elements speed up the process. The first reason for the quick responses is that the most commonly used top-level domains, such as com, org, and net, are actually hosted by the root name servers, eliminating one iteration from the request referral process.

The second reason is that most DNS server implementations maintain a cache of information they receive from other DNS servers. When a server possesses information about a requested FQDN in its cache, it responds directly using the cached information, rather than sending another referral to the authoritative server for the FQDN’s domain. Therefore, if you have a DNS server on your network that has just successfully resolved the name www.adatum.com by contacting the adatum.com server, a second user trying to access the same host a few minutes later would receive an immediate reply from the local DNS server, rather than having to wait for the entire referral process to repeat.

DNS Query Types

DNS servers recognize two types of name resolution requests: recursive queries and iterative queries. In a recursive query, the DNS server receiving the name resolution request takes full responsibility for resolving the name. If the server possesses information about the requested name, it replies immediately to the requestor. If the server has no information about the name, it sends referrals to other DNS servers until it obtains the information it needs. TCP/IP client computers send recursive queries to their designated DNS servers. In an iterative query, the servers that receive the name resolution request immediately respond with the best information they possess at the time, whether that information is a fully resolved name or a reference to another DNS server. DNS servers use iterative queries when communicating with each other. It is considered impolite to configure one DNS server to send a recursive query to another DNS server, except in the case of a special type of server called a forwarder, which is specifically configured to interact with other servers in this way.

Understanding the Domain Hierarchy Levels

The top two levels of the DNS hierarchy, the root and the top-level domains, exist primarily to respond to queries for information about other domains. The root name servers do nothing but respond to millions of iterative requests by sending out the addresses of the authoritative servers for the top-level domains.


There are seven primary top-level domains: com, net, org, edu, mil, gov, and int, plus two-letter international domain names representing most of the countries in the world, such as fr for France and de for Deutschland (Germany). There are also a number of newer top-level domains promoted by Internet entrepreneurs, such as biz and info, which have yet to be widely used commercially.

Each top-level domain has its own collection of second-level domains. Individuals and organizations can lease these domains for their own use. For example, the second-level domain adatum.com belongs to a company that purchased the name from one of the many Internet registrars now in the business of selling domain names to consumers. For the payment of an annual fee, you can purchase the rights to a second-level domain.

To use the domain name, you must supply the registrar with the IP addresses of the DNS servers that you want to be the authoritative sources for information about this domain. The administrators of the top-level domain servers then create resource records pointing to these authoritative sources, so that any com server receiving a request to resolve a name in the adatum.com domain can reply with the addresses of the adatum.com servers.


To create authoritative sources for your domain, you can deploy your own DNS servers, using Windows Server 2003 or another operating system, or you can pay to use your ISP’s DNS servers.

Determining DNS Requirements

If you plan to give network users client access to the Internet, they must have direct access to one or more DNS servers. You can run your own DNS servers on your network for this purpose, or you can use your ISP’s DNS servers. You do not need to register a domain name. The clients’ DNS servers can be caching-only servers, meaning that they exist only to process name resolution requests sent by clients, and they can be located on your private network, with unregistered IP addresses.

Hosting an Internet Domain

If you plan to host an Internet domain, you must register a second-level domain name and give the IP addresses of your DNS servers to your domain registrar. These servers must have registered IP addresses and must be available on the Internet at all times. The servers do not have to be on your network, and do not have to be in the domain you have registered. You can use your ISP’s DNS servers for this purpose (for a fee), but be aware that you will occasionally have to change the server configuration, to create or modify the resource records stored there. If you maintain your own DNS servers, you can manage the resource records yourself and retain full control over their security. If your ISP hosts your domain, you might have to have them make the changes, and they might charge you an additional fee for each modification.

Hosting Internet Servers

If you plan on hosting Internet servers on your network, you must have access to a registered domain on the Internet, with authoritative DNS servers on which you can create resource records that assign host names to your servers. You can either register your own domain (in which case you must meet the requirements described in the previous paragraph, “Hosting an Internet Domain”), or you can use your ISP’s DNS servers, in which case they must create the necessary resource records for you.

Using Active Directory

If you plan to run Active Directory on your network, you must have at least one DNS server on the network that supports the Service Location (SRV) resource record, such as the DNS Server service in Windows Server 2003. Computers on the network running Windows 2000 and later versions use DNS to locate Active Directory domain controllers. To support Active Directory clients, the DNS server does not have to have a registered IP address or an Internet domain name.

Combining DNS Functions

In many cases, a network requires some or all of these DNS functions, and you must decide which ones you want to implement yourself and which you want to delegate to your ISP. It is possible to use a single DNS server to host both Internet and Active Directory domains, as well as to provide name resolution services for clients. However, when planning a DNS name resolution strategy for a medium or large network, you should run at least two DNS servers, to provide fault tolerance.


If you plan to use your ISP’s DNS servers for any functions other than client name resolution, be sure that the DNS server implementation they are using is compatible with the Windows Server 2003 DNS servers you are using, and that they are able to provide the services you need.

You might also want to consider splitting up these functions by using several DNS servers. For example, you can use your ISP’s DNS servers for client name resolution, even if you are running your own DNS servers for other purposes. The main advantage of using your ISP’s servers is to conserve your network’s Internet bandwidth. Remember that the Internet name resolution requests that DNS servers receive from client resolvers are recursive queries, giving the first server responsibility for sending iterative queries to other DNS servers on the Internet to resolve the name. When the DNS server receiving the recursive queries is on your private network, all the iterative queries the server generates and their responses go through your Internet access router, using your bandwidth (see Figure 4). If your clients use a DNS server on your ISP’s network (which is nearly always a free service), only one query and one response go through your router. The ISP’s DNS servers generate all the iterative queries, and these queries travel directly to the Internet.

Figure 4. Using the ISP’s DNS server saves Internet bandwidth

Using NetBIOS Names

If computers on your network are running versions of Microsoft Windows earlier than Windows 2000, they are using NetBIOS names and must have a means of resolving those names into IP addresses. When Microsoft originally incorporated networking capabilities into the Windows operating systems, it relied on NetBIOS names to identify computers and on the NetBEUI protocol for communications. NetBEUI uses these names exclusively; the protocol has no other addressing system. Later, Microsoft adopted TCP/IP as its default protocols, but continued to use NetBIOS to provide friendly names for computers until the release of Active Directory with Windows 2000.

Off the Record

These earlier Windows operating systems are capable of interacting with computers running Windows 2000 and later versions because the computers maintain an equivalent that is compatible with NetBIOS for every Active Directory name.

The NetBIOS namespace is flat, not hierarchical like the DNS namespace. Each computer and other entity has a single NetBIOS name up to 16 characters long, which must be unique on the network. In the Windows operating system, the sixteenth character is reserved for a code that identifies the type of resource represented by the name; therefore, the NetBIOS names you assign to computers running Windows operating systems can be no longer than 15 characters. The non-hierarchical nature of the NetBIOS namespace means that it is not as scaleable as DNS, and indeed it need not be, because NetBIOS is intended for private networks only, not for huge networks like the Internet.

NetBIOS Name Resolution Mechanisms

Windows has several name resolution mechanisms for NetBIOS names, which are as follows:

  • WINS WINS is a NetBIOS name server included with all current server versions of the Windows operating system, WINS registers the names and IP addresses of Windows NetBIOS computers as they start up and compiles its own name resolution database. Every computer running a Windows operating system includes a WINS client that an administrator must configure with the IP address of at least one WINS server on the network. Before the computer running the Windows operating system can communicate with another NetBIOS computer on the network, it sends a message called a NAME QUERY REQUEST as a unicast to its WINS server. The message contains the NetBIOS name of the other computer, and the WINS server responds with the IP address associated with the name. WINS servers are able to provide NetBIOS name resolution services for an entire enterprise network running Windows operating systems.

  • Broadcast transmissions When an administrator does not configure a computer running a Windows operating system to use WINS for NetBIOS name resolution, the system attempts to resolve names by broadcasting a NAME QUERY REQUEST message. The computer that possesses the name in the message is responsible for replying to the sender with its IP address. The broadcast transmission method is less efficient than WINS, both because broadcasts generate more network traffic than unicasts and because broadcast transmissions are limited to the local network.

  • Lmhosts This text file contains a lookup table that is much like the Hosts file originally used by TCP/IP systems. Lmhosts name resolution is extremely fast, because no network communication is required, but administrators must update the file manually, making the method subject to the same administrative drawbacks as the Hosts file. Computers running Windows operating systems that rely on broadcast name resolution typically use Lmhosts as a backup method for resolving the names of computers that are not on the local network.

  • NetBIOS name cache No matter what other NetBIOS name resolutions they use, all computers running Windows operating systems also maintain a cache of recently resolved names and their IP addresses. When a computer needs to resolve a NetBIOS name, it always checks the cache first. This enables the computer to avoid repeatedly resolving the same names.

Windows uses these name resolution mechanisms in combination, depending on the configuration of the computer. When you configure a computer to use WINS, it resolves NetBIOS names by first checking the NetBIOS name cache, then sending messages to its WINS server. If the WINS server fails to resolve a name or is unavailable, the computer reverts to broadcast name resolution, and then to Lmhosts. Computers not configured to use WINS generate broadcast transmissions after checking the cache then revert to Lmhosts if broadcast transmissions fail to resolve the name.

Determining NetBIOS Name Resolution Requirements

If your network has computers running Windows operating systems that use NetBIOS on multiple local area networks (LANs), running WINS servers is all but essential. Otherwise, your network would be burdened with the additional traffic generated by broadcast name resolution, and you would have to create and update an Lmhosts file for every computer that has to resolve NetBIOS names on other LANs. If all your NetBIOS computers are in the same broadcast domain on a single local area network (LAN), you can do without WINS, because the broadcast transmission method is automatic and requires no administration. However, if you have a large number of NetBIOS computers, you might want to use WINS anyway, to save network bandwidth.

Off the Record

Although WINS is generally not a major administrative burden, you might want to consider eliminating NetBIOS and NetBT traffic from your enterprise completely by upgrading all your downlevel computers to Windows 2000 or higher.

Using Local Host Name Resolution

Although network administrators rarely use Hosts and Lmhosts files as primary name resolution methods, these files are useful as fallback mechanisms. If you have computers performing critical functions that would be interrupted by the failure of a name resolution mechanism, you can create a Hosts or Lmhosts file on these computers. The file would contain the names and IP addresses of systems that must be resolvable for the critical functions to proceed.

Other -----------------
- SharePoint 2010 Central Administration Backup and Restore : Backup,Restore Prerequisites and Considerations
- SharePoint 2010 : An Overview of Backup and Restore Capabilities (part 2) - Granular Backup & Configuration-Only Backup
- SharePoint 2010 : An Overview of Backup and Restore Capabilities (part 1) - Farm Backup and Restore
- Exchange Server 2010 : Generating Reports (part 5) - Using the Microsoft Exchange Best Practices Analyzer (ExBPA) to Create Reports
- Exchange Server 2010 : Generating Reports (part 4)
- Exchange Server 2010 : Generating Reports (part 3) - Testing Mail Flow
- Exchange Server 2010 : Generating Reports (part 2) - Reporting Mailbox Folder Statistics
- Exchange Server 2010 : Generating Reports (part 1) - Generating Mailbox Statistics Reports
- SharePoint 2010 PerformancePoint Services : Using Windows PowerShell and Cmdlets (part 2) - Cmdlet Samples
- SharePoint 2010 PerformancePoint Services : Using Windows PowerShell and Cmdlets (part 1) - Cmdlets Available Out of the Box
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Windows Vista
Windows 7
Windows Azure
Windows Server