Read an Excerpt
[Figures are not included in this sample chapter]
Windows NT® DNS
- 3 -
How Windows Clients Use DNS and WINS
This chapter will review:
- Introducing the Windows resolver. This section introduces the Windows
client resolver and also explains what a resolver is and how it differs from a name
- How WINS serves the Windows name resolver. WINS is the NetBIOS name server
and, as such, provides an invaluable service to Windows clients by helping Windows
computers find one another in a local area network and even over a WAN. This section
explains the role WINS can play to help you resolve names.
- How DNS serves the Windows name resolver. DNS is the irreplaceable Domain
Name Service that helps clients resolve Internet names. This section explains in
some detail how this service works, including a description of iterative, recursive,
and reverse queries.
- How the resolver works. The Windows client resolver is complex because
it must deal with two different name types (DNS and NetBIOS) and can use up to six
methods. This section explains how the resolver thinks--and how it actually works
its way through three separate phases to resolve names depending on different configuration
options at your disposal.
WINDOWS COMPUTERS HAVE SO MANY NAME-RESOLUTION OPTIONS to use that it's
hard sometimes to predict just how they'll behave. The way in which the resolver
is configured makes a huge difference. Sometimes a computer just can't find others
on the network--even those listed in the Network Neighborhood. If you know how resolvers
work, the mysteries behind a success or failure are easier to solve. Helping you
understand the Windows resolver is the purpose of this chapter. For guidance on how
to configure your computers to take advantage of all the resolver's options, take
a look at Chapter 13, "Configuring Clients."
Introducing the Windows Resolver
A resolver is the collection of programs and processes a client computer
uses to take advantage of available name services. A Windows resolver that asks a
WINS or a DNS name server for an address stays engaged until an answer comes back,
even if it means that other servers must also be queried or other methods invoked.
Resolvers typically use all options at their disposal. For the purposes of the discussion
in this chapter, name-resolving is strictly a client function. This isn't to say
that name servers don't help--they simply play a supporting role in the process.
Clients resolve names.
UNIX resolvers deal almost exclusively with IP host names. By contrast, Windows
resolvers must support two name types: NetBIOS computer names and IP host names.
What's more, Windows resolvers must decide which of several possible options to use
to resolve the names--and the resolvers also must know what to do if the first approach
doesn't succeed, if the second doesn't succeed, and so on.
Variations in resolver behavior among Windows 95, Windows 98, and Windows NT are
not explored in detail here because the differences are too few.
Having said that, the main difference between Windows NT 4 and Windows 95 is that
Windows NT queries DNS first if any periods (".") exist in the name, or
if the name is more than 15 characters in length. Windows 98 acts more like Windows
NT than Windows 95. By contrast, Windows 95 first attempts to use NetBIOS resolution
methods, and only when these fail will it query the LMHOSTS and HOSTS files--and
finally a DNS server lookup. The calling order and the method of deciding which are
used or ignored are determined by configuration settings.
The general-purpose resolver facility inside a Windows operating system is available
to any program that needs it--even those with no name-resolving capabilities. Most
applications needing name service use the general purpose resolver by giving it computer
names to resolve.
The Windows name resolver submits queries to name servers and handles the various
possible responses they can return. When names are resolved, applications can usually
proceed with their tasks. If, for any reason, the resolver does not succeed in locating
a name, it sends an appropriate failure message to the local application that requested
service. Most Windows applications are designed to handle these conditions gracefully;
they'll warn the user about the failure instead of crashing.
Some applications have built-in resolver capabilities so that they don't even
need the general-purpose resolver. Examples of this approach include ping and nslookup.
The ping tool, which sends Internet Control Management Protocol (ICMP) echo requests
to verify other computers on the network, parses names and numbers and can query
a DNS server itself without calling its host's general-purpose resolver. The nslookup
tool is a comprehensive, standalone DNS server diagnostic utility that also contains
a resolver. Chapter 17, "Troubleshooting Tools and Utilities," can tell
you more about ping and nslookup and explains how to use them.
A useful feature of Windows resolvers is that they automatically switch between
various name services including WINS and DNS, saving users from having to decide.
The following sections review what WINS and DNS servers can do for clients.
How WINS Serves the Windows Name Resolver
WINS servers have one simple query-handling behavior: They reply positively with
the address and name sought, or they reply negatively with a Requested Name Does
Not Exist message. WINS servers search through the names and addresses in their
own database file of registered computers and any other databases they've received
by replication from other WINS servers. A Windows client sends up to three requests
to a primary WINS server. The IP number (address) of WINS servers is set in the Network
Control Panel under TCP/IP settings. If a secondary WINS server's address is included,
the client then queries the secondary server at its address, sending up to three
requests before giving up. If either server responds before all six queries are sent,
the client will not query again. If all six queries fail, the client may or may not
have alternatives, depending on its configuration. Using a DNS server is one possible
How DNS Serves the Windows Name Resolver
Windows computers can use DNS, too. You can even give a Windows client several
DNS servers to choose from, specifying in the Network Control Panel which to use
first, second, and so on. Figure 13.10 in Chapter 13 illustrates this. If a Windows
computer is configured to use DNS in the Network Control Panel (see Figure 3.1),
it can request three types of queries:
- Recursive name queries
- Iterative name queries
- Reverse name queries
- FIGURE 3.1 Windows NT 4.0 enabling DNS for Window resolution.
The Microsoft DNS server accepts all three kinds of queries, whether recursive,
iterative, or reverse. DNS servers are configured by default to issue recursive queries
to other DNS servers in the hope that they can off-load the burden to retrieve a
final, authoritative answer. You can set a DNS server so that it won't attempt recursion
by changing the NoRecursion Registry key from 0/False to 1/True,
as in the following code:
Value Type: REG_DWORD - Boolean
Default: 0 (Recursion Enabled)
Valid Range: 0,1 (False, True)
Description: Enables/disables if the DNS Server should do recursive lookups to other DNS Servers.
Other recursion options in the Registry are RecursionRetry (default=every
2 seconds) and RecursionTimeout (default=every 15 seconds).
Recursive queries force the DNS server to take on the whole burden to retrieve
an authoritative answer on behalf of the client. This is illustrated in Figure 3.2
where the client, pc.acme.com, issues a recursive query to the DNS server,
acme.com. In Figure 3.2, the DNS server acme.com itself becomes
an iterative DNS client/resolver to four other DNS servers after it accepts a recursive
query request from pc.acme.com.
- FIGURE 3.2 Recursive and iterative queries are both required
to resolve some client requests.
When the bigcompany.com DNS server replies with an authoritative answer,
acme.com passes it to pc.acme.com, which completely resolves the
query. Resolution isn't final until the client is satisfied.
If acme.com had refused the recursive query request from pc.acme.com,
pc.acme.com would have had to perform all the iterative queries for itself,
going to each DNS server in turn, just as acme.com does in Figure 3.2. Client
resolvers issue recursive requests almost exclusively, but they are sometimes refused.
The only reply a client will accept from a DNS server in response to a recursive
query is success or failure. Until then, the client just waits. If the result isn't
an authoritative IP address for the host sought but is instead a "hint"
or referral to another DNS server, the client next queries the hint address looking
for an authoritative reply.
Recursion means that a DNS server stays with the query on the client's behalf
until it's resolved. The DNS server uses its own resolver, switching roles instantly
from server to client and back again until it or another server can provide an authoritative
reply. Ironically, the DNS server handling a recursive client query usually issues
iterative queries to other DNS servers, following their pointers up and down the
DNS name tree to reach a server with a match for the queried name, or until an end
condition is met such as a timeout or error.
Recursion can happen only if the following conditions are met:
- The client requests recursion.
- The DNS server accepts recursive queries. (Most do, with the exception of root
- The client's DNS server can't answer out of its own cache or database.
If the client's DNS server could answer out of its own cache or database, it would
reply immediately and authoritatively, eradicating the need to perform further queries.
Most resolvers attempt a recursive query first. If the server refuses recursive
queries and can't return the address itself out of its own cache or data files, clients
usually try again using an iterative query.
Iterative queries enable the DNS server to pass back best-guess pointers, also
called hints or referrals. An iterative query may not return a final result, but
a recursive query does return a final result. An iterative query may return a partial
result, or a suggestion about where to look next. The client (resolver) uses iterative
queries to get closer to an answer, iteratively querying other DNS servers until
a final answer (resolution), an error, or a timeout occurs. Iteration puts less work
on DNS servers but requires more from clients. Referring back to Figure 3.2, the
second query to ns.myisp.com returns a hint referring acme.com
to the root domain DNS server. This repeats until an authoritative answer is received
from bigcompany.com's DNS server in response to the fifth query.
If the first DNS server iteratively queried can't return an address, it tells
the client which DNS server is the next best to query. The next best server is usually
one somewhere up the name tree closer to the DNS root, or it may be a root server.
After a root server is located, it usually takes very few queries to walk back down
the name tree to an authoritative server for the domain sought, which returns the
desired address or an error to conclude the original query.
DNS Servers can be DNS Clients
When talking about iterative and recursive queries, it's easy to get confused. The
reason is simply that DNS servers also have a resolver, or client, and they instantly
and frequently change roles from one client's server to another server's client.
To satisfy one original client query, many queries can be performed by a series of
DNS servers acting as servers and as clients to one another.
If a DNS server sends a query, it acts as a client to another DNS server. It's helpful
to view each query along the way individually, as a unique query with its own client
and its own server.
If you keep this in mind, it will help you remember who's the server and who's the
client in any given query--and you're less likely to become confused by recursive
and iterative queries.
Reverse queries are another thing altogether. Recursive and iterative queries
are both forward queries, which means that they take a domain name and return
an IP number. A reverse query does the opposite--it takes an IP number from
the client and returns a fully qualified domain name (FQDN). A special domain was
created in the domain namespace for this purpose using reversed IP numbers instead
of names. All registered IP numbers are joined to (made members of) the in-addr
subdomain of the arpa domain. Typically, host names can be duplicated
because domain name qualifiers separate them sufficiently into domains and subdomains.
Because no two hosts in the Internet can have the same registered IP address, they
can all be members of one subdomain--but only by number. In this scheme, unique IP
numbers replace host names in the domain name hierarchy. In the in-addr.arpa
domain, host2.acmecompany.com would have a pointer (PTR) record appearing
like the following:
126.96.36.199.in-addr.arpa IN PTR host2.acmecompany.com
The matching address entry in the acmecompany.com subdomain for this
PTR record would look like this:
host2.acmecompany.com IN A 10.1.1.2
In this example, the IP address for host2 is stored in the in-addr.arpa
domain and is sorted along with all other registered Internet hosts. MS DNS creates
a matching PTR record in the in-addr.arpa domain for every A record.
To reverse-query host2 (by IP number) requires only that a few numbers
be reversed. The FQDN for host2 can then be returned simply by querying
its reversed IP number in the in-addr.arpa subdomain, where all registered
hosts are members known by IP address instead of their domain name.
When everything is working, the type of query a client or even a DNS server uses
is more important to administrators than users. If you're having performance or resolution
problems, you can try changing the default setting. Clients almost always attempt
recursive queries--and the default for MS DNS is also to attempt recursive queries
when going to other DNS servers--but recursive queries can be refused by other servers.
If you want to change a server's default setting, refer to the discussion earlier
in this chapter describing Registry keys.
Reverse Queries are IN. Inverse Queries are OUT.
Inverse queries are sometimes confused with reverse queries, but their method is
radically different. Instead of scanning an index of names, inverse queries ask the
DNS server to scan sequentially (no index) the IP addresses of A records to match
a number the client provided. Inverse queries were supported in earlier versions
of the popular BIND program (mostly a UNIX-based DNS server), but now inverse queries
are rare. They're slow because A records aren't sorted by IP address like the PTR
records in the in-addr.arpa domain designed for the purpose. What's more,
inverse queries always fail if the IP number isn't stored directly on the queried
DNS server because, unlike with other queries, the client cannot be referred to another
How the Resolver Works
DNS helps clients reach Internet hosts such as Web servers, and WINS servers help
Windows clients reach local Windows computers. Querying name servers, however, is
just one of several methods a Windows resolver can use.
The resolver described in this chapter is the one in Windows NT 4.0. Prior versions
of Windows NT and Windows 95 differ only slightly from Windows NT 4.0.
One difference is that the resolver in Windows NT 4.0 can handle an IP number or
a domain-qualified host name in almost any place it takes a NetBIOS name.
Another difference is that the resolver in Windows NT 4.0 implements a new phase
of resolution that other versions do not: Phase One, "Query DNS for obvious
non-NetBIOS names," which is described in the text immediately following. Other
Windows versions start at Phase Two, "Attempt NetBIOS methods." To understand
these phases, read on.
Chapter 2, "Introducing NetBIOS," briefly described the six possible
- Name cache
The remainder of this chapter describes each of these methods in more depth and
explains how the resolver decides which to use.
The resolver works through three phases when trying to resolve a name, and it
may use any or all of the six possible methods in the process. The three name-resolution
phases are as follows:
- 1. Query DNS for obvious non-NetBIOS names.
2. Attempt NetBIOS methods.
3. Query local files LMHOSTS and HOSTS.
If a name is greater than 15 characters in length or contains a "." it
is not a NetBIOS computer name. This makes things simple; such a name must be resolved
using one of the methods that works for domain host names. DNS and the local mapping
file, HOSTS, are the only options for resolving names such as the following:
- webservertwentytwo. Consists of 18 characters.
- webserver.isp.com. Is qualified by a domain name.
- web.server. Contains the "." character.
If "Enable DNS for Windows Resolution" is not checked in the Network Control
Panel (see Figure 3.1) resolution will quickly fail as Figure 3.3 illustrates.
- FIGURE 3.3 The first resolution phase involves querying
DNS for obvious non-NetBIOS names.
To resolve these names, your client must be configured to "Enable DNS for Windows
Resolution." The resolver then will query the DNS server(s) listed under the
Control Panel's DNS tab.
If the name could be either a NetBIOS name or a domain host name (containing 15 or
fewer characters in length without any "." characters), its namespace can't
be determined. In this case, the Windows client resolver provisionally assumes it
is a NetBIOS name and begins to attempt to resolve the name using NetBIOS methods.
Because Windows doesn't know for sure what kind of service to use, it first checks
the local NetBIOS name cache. If that doesn't work, Windows decides what to do next
based on the client's node type. Let's briefly discuss the name cache and then cover
node types in more detail.
The NetBIOS Name Cache
As mentioned previously, it doesn't matter what the node type is: The NetBIOS cache
is checked first if the resolver thinks it might be a NetBIOS name. The address will
be there if this is indeed a NetBIOS name that has been recently resolved. There
is no such thing as a remote NetBIOS name cache. A NetBIOS name cache is always local
and belongs only to the machine it's on. Names and addresses previously resolved
by that client remain in cache for 600 seconds (10 minutes).
You can preload addresses into cache to guarantee reliable and fast name resolution
of any important computer. The technique requires that you use the #PRE
directive in the LMHOSTS file. For an explanation of this technique, refer to the
LMHOSTS section later in this chapter.
To check the name cache, use the nbtstat -c command, which is documented
in Chapter 17.
The NetBIOS Node Types
The first thing to know about a Windows computer resolver is its node type. Every
NetBIOS computer has a node type. Node type has nothing to do with DNS domains and
IP hosts name resolution; it is a configuration parameter for NetBIOS computers only.
Four possible node types exist, specifying which method is used to resolve NetBIOS
- b-node. Uses broadcasts only (also called broadcast method).
- p-node. Uses point-to-point with the name server only.
- m-node. Mixed; uses broadcasts first and then point-to-point.
- h-node. Hybrid; uses point-to-point first and then broadcasts.
Regardless of the node type, at this point in the process the resolver assumes that
it's dealing with a NetBIOS computer name, even though it's not sure. That's why
the resolver checks its own local NetBIOS name cache before taking any further steps
to implement a specific node type behavior.
Configuring the Node Type
To configure a client to be an h-node, enter a WINS server address. To configure
a client to be a b-node, leave the WINS address empty. It's that easy! Windows NT
node configuration is pretty reliable. Windows 95, though, has shown instability
in that clients configured to use WINS (h-nodes) may fall back to b-node configuration.
Although this problem is most likely to occur over dial-up networks, it has been
observed even on computers with Ethernet connections.
To check your node type on a Windows 95 machine, just run winipcfg.exe /all,
the configuration display utility, in the Start/Run... menu or in a MS-DOS prompt
(command) window. Figure 3.4 shows the information you'll see. To check a Windows
NT machine, run ipconfig.exe /all in a command window.
- FIGURE 3.4 A Windows 95 client is configured to
be an h-node.
The node types you're most likely to encounter are b-nodes and h-nodes. The m-node
and p-node types are rare and, in fact, don't even appear unless configured manually,
as with a DHCP server (see Chapter 18, "Dynamic Host Configuration Protocol
(DHCP)"). The following section briefly discusses p-nodes and m-nodes before
moving on to a fuller explanation of the more common h- and b-node types.
The Rarest Node Types: p-node and m-node
The p-nodes don't ever broadcast to register themselves or find addresses. They only
communicate point-to-point using directed User Datagram Protocol (UDP) datagrams
and TCP sessions to register with a NetBIOS name server (WINS) and resolve names
using the same server. These p-nodes are a practical configuration to have for clients
on the remote side of a WAN link from the main office, for example, where broadcasts
would surely fail often because the computers being resolved live on the other side
of a router. The downside of this node type is that all systems must know the IP
address of the WINS server. Those that don't won't resolve. To configure a p-node,
you use a DHCP server. Chapter 18 covers this in depth.
The m-nodes broadcast and then go directly to a WINS server if this fails. This
is by far the least-used configuration because it's so impractical. The m-nodes might
be useful in an instance in which a remote WAN site has no WINS server and the client
mostly needs servers located in the same subnet. If a local broadcast name-resolution
attempt fails, the client connects with a WINS server over the router, in the main
office, to resolve a server there. The delays could be as long as several seconds,
but if there's a slow WAN link anyway, the delay may not bother users.
As described in Chapter 18, DHCP covers node configuration in some detail. DHCP
clients can be set to any node type: b, h, p, or m.
The b-nodes resolve names by broadcast only, which usually means that their effective
scope is limited to the single subnetwork they're on. Because routers typically block
broadcasts, they prevent b-nodes from resolving any computers on the other side.
These b-nodes never use a name server, as Figure 3.5 illustrates.
- FIGURE 3.5 This second resolution phase involves attempting
NetBIOS b-node method.
A downside to b-nodes is that they put unnecessary traffic on the network that can
be removed simply by employing a WINS server. If you don't want to use WINS and plan
to rely mostly on broadcasts, you can still get the benefit of some direct addressing
across routers by preloading addresses into the local NetBIOS name cache. To do this,
just employ an LMHOST file and the #PRE directive. This technique also reduces
broadcasts from b-nodes because every preloaded address that would otherwise require
a broadcast will be first found in cache.
The h-nodes, or hybrid nodes, resolve names by asking the WINS server. If that fails,
they broadcast. The h-nodes overcome the limitations of b-node address resolution
because the queries pass directly through routers to get to the name server. Because
an h-node's resolver already knows the WINS server's address, it's easy to resolve
a target computer's address. Then the client can pass through routers again to connect
with the target computer. This is where h-nodes really shine. Figure 3.6 illustrates
how h-nodes work. These nodes can locate any computer that's registered in their
same WINS server, in contrast to b-nodes, which typically can't locate any addresses
outside their own subnet. There's little to dislike about hybrid nodes: Simply install
a WINS server and use them! WINS is very easy to install and takes no configuration
to get running. You can take some time to configure replication between the primary
and secondary WINS server to provide a bit of redundancy, but that's all there is
to it, and the benefits are many. The following sequence illustrates the operation
of a typical h-node, from startup to shutdown.
- 1. Registration. At startup, the h-node registers its own name
and address with the WINS server using point-to-point communications with the server
via the address it already knows.
2. Resolution. Until shutdown, the h-node resolves names as often
as necessary by asking the WINS server directly. The h-node uses addresses the WINS
server sends back to directly contact other computers.
3. Release. At shutdown, the h-node releases its own registration
from the WINS server to indicate that it is no longer available.
- FIGURE 3.6 This second resolution phase attempts the NetBIOS
- The h-nodes always use the WINS server after checking the local NetBIOS name
cache; they resort to b-node behavior only if that fails. The exception to this operation
is if the WINS server doesn't respond or if, for some other reason, the client can't
register itself upon startup. Even in one of these cases, or if the WINS server goes
offline, the client continues to attempt to contact the WINS server to try to return
to a direct addressing method.
Regardless of node type, the resolver has two last options if the NetBIOS methods
fail: It can query one or two local files. The LMHOSTS file is usually checked first,
before the HOSTS file. If the DNS server(s) is unable to locate a name and the NetBIOS
methods fail, resolution fails unless the name exists in the LMHOSTS or HOSTS file.
Figure 3.7 shows the decisions the resolver makes at this stage, assuming that NetBIOS
methods have failed.
- FIGURE 3.7 The third resolution phase involves querying
local LMHOSTS and HOSTS files.
The difference between the LMHOSTS and HOSTS files is slight from a cosmetic perspective--they
look almost identical. In fact, under certain circumstances, both files could actually
be identical and function just fine. However, each file reflects a different namespace.
The LMHOSTS file is for NetBIOS names, and the HOSTS file is for domain host names.
If you had only Windows computers, you wouldn't need a HOSTS file. If you had only
one Windows computer and all the rest were UNIX hosts, you wouldn't need an LMHOSTS
file because the UNIX hosts would be listed only in the HOSTS file.
LMHOSTS: A Local NetBIOS Name/Address Listing
The LMHOSTS file is always checked first if the Enable LMHOSTS Lookup checkbox is
checked (refer back to Figure 3.1). If LMHOSTS is not enabled, it's not used at all.
LMHOSTS is kept in the \<systemroot>\system32\drivers\etc directory,
where you'll find a sample named LMHOSTS.sam that Microsoft provides to
get you started. If you decide to use the sample, remove the .sam extension.
LMHOSTS is much like a hosts file on UNIX, but, as mentioned earlier, it works
with NetBIOS names and uses the same syntax as Microsoft LAN Manager 2.x. LMHOSTS
is primarily a hosts file for simple name-to-address mappings, but it also supports
directives that aren't allowed or aren't that meaningful in a HOSTS file.
The following is a sample of Microsoft's LMHOSTS file that's automatically installed
on Windows NT computers:
# Copyright 1993-1995 Microsoft Corp.
# This is a sample LMHOSTS file used by the Microsoft TCP/IP for Windows
# This file contains the mappings of IP addresses to NT computernames
# (NetBIOS) names. Each entry should be kept on an individual line.
# The IP address should be placed in the first column followed by the
# corresponding computername. The address and the comptername
# should be separated by at least one space or tab. The "#" character
# is generally used to denote the start of a comment (see the exceptions
# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
# files and offers the following extensions:
# #INCLUDE <filename>
# \0xnn (non-printing character support)
# Following any entry in the file with the characters "#PRE" will cause
# the entry to be preloaded into the name cache. By default, entries are
# not preloaded, but are parsed only after dynamic name resolution fails.
# Following an entry with the "#DOM:<domain>" tag will associate the
# entry with the domain specified by <domain>. This affects how the
# browser and logon services behave in TCP/IP environments. To preload
# the host name associated with #DOM entry, it is necessary to also add a
# #PRE to the line. The <domain> is always preloaded although it will not
# be shown when the name cache is viewed.
# Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT)
# software to seek the specified <filename> and parse it as if it were
# local. <filename> is generally a UNC-based name, allowing a
# centralized lmhosts file to be maintained on a server.
# It is ALWAYS necessary to provide a mapping for the IP address of the
# server prior to the #INCLUDE. This mapping must use the #PRE directive.
# In addition the share "public" in the example below must be in the
# LanManServer list of "NullSessionShares" in order for client machines to
# be able to read the lmhosts file successfully. This key is under
# \machine\system\currentcontrolset\services\lanmanserver\parameters\ nullsessionshares
# in the registry. Simply add "public" to the list found there.
# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
# statements to be grouped together. Any single successful include
# will cause the group to succeed.
# Finally, non-printing characters can be embedded in mappings by
# first surrounding the NetBIOS name in quotations, then using the
# \0xnn notation to specify a hex value for a non-printing character.
# The following example illustrates all of these extensions:
# 188.8.131.52 rhino #PRE #DOM:networking #net group's DC
# 184.108.40.206 "appname \0x14" #special app server
# 220.127.116.11 popular #PRE #source server
# 18.104.22.168 localsrv #PRE #needed for the include
# #INCLUDE \\localsrv\public\lmhosts
# #INCLUDE \\rhino\public\lmhosts
# In the above example, the "appname" server contains a special
# character in its name, the "popular" and "localsrv" server names are
# preloaded, and the "rhino" server name is specified so it can be used
# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
# system is unavailable.
# Note that the whole file is parsed including comments on each lookup,
# so keeping the number of comments to a minimum will improve performance.
# Therefore it is not advisable to simply add lmhosts file entries onto the
# end of this file.
The # character appearing first on a line is the comment symbol, indicating
that the line contains only comments for users to read. However, if the characters
immediately following the # are reserved words, as shown in Table 3.1, they're
directives, not comments.
Table 3.1 Reserved words in the LMHOSTS.sam file
|#BEGIN_ALTERNATE||Indicates the beginning of a section where #INCLUDE <filename> statements |
exist. The first <filename> successfully included (loaded) in any
group during processing causes the others to be skipped.
|#INCLUDE <filename>||Used to specify one or more LMHOST files on other computers to be read and included |
in the list of names and addresses. Uses UNC syntax.
|#END_ALTERNATE||Indicates the end of a section where #INCLUDE statements exists, delimiting |
|#PRE||Preloads an entry into the NetBIOS name cache, where it remains as long as the computer |
is running. It's required and must precede computer names that will be #INCLUDED.
Up to 100 entries may be preloaded.
|#DOM: <domain_name>||Identifies the name of a computer acting as a domain controller, either a PDC or |
a BDC. It's important, especially in the absence of WINS, that DCs be identified
because of their name-integration role in browsing (as Domain Master Browser).
|\0xnn||Specifies the hex value of a nonprinting character to be appended to the NetBIOS |
name at the 16th byte. This enables you to manually identify service codes with computers
in a manner similar to the registrations in WINS. If you use this feature with a
name less than 15 characters, enclose the name in quotes, pad it with spaces, and
insert the \xnn within the quote marks beginning at the 16th character
position. See Table 2.1 for the resource codes these represent. Other special application
codes may also be used as documented in product literature. Note that this feature
is not backward-compatible with LAN Manager.
The LMHOSTS file is really easier to use than it may appear from this description.
Just remember to make sure the Enable LMHOSTS Lookup checkbox is checked, as indicated
earlier in Figure 3.1.
HOSTS: A Local DNS Name/Address Listing
If the Enable LMHOSTS Lookup checkbox is not checked, or if the name isn't found
there, the resolver can check the HOSTS file--but only if the Enable DNS for Windows
Resolution checkbox is checked (refer back to Figure 3.1). HOSTS is a reflection
of the domain host namespace, not the NetBIOS namespace. The HOSTS file works exactly
like a UNIX hosts file--and like LMHOSTS, this file is also stored in the \<systemroot>\system32\drivers\etc
Here's the sample Microsoft HOSTS file that comes with Windows NT:
# Copyright 1993-1995 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows NT.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a `#' symbol.
# For example:
# 22.214.171.124 rhino.acme.com # source server
# 126.96.36.199 x.acme.com # x client host
Notice that the # symbols are only comment characters. Another difference
from the LMHOSTS file is that the names can be fully qualified domain names (FQDNs).
This chapter presented an ambitious overview of the Windows NT name-resolution client
and gives a thorough description of how it works, including what WINS and DNS do
to help it get the job done. The next chapter, "WINS and DNS: Making the Most
of Both Services," explains how WINS and DNS can be made to cooperate at the
server level to functionally make the NetBIOS and domain namespaces appear as one.