- Shopping Bag ( 0 items )
Ships from: Phoenix, MD
Usually ships in 1-2 business days
Ships from: streamwood, IL
Usually ships in 1-2 business days
|I||Understanding Windows Name Services|
|1||Introducing the Domain Name System||3|
|3||How Windows Clients Use DNS and WINS||33|
|4||WINS and DNS: Making the Most of Both Services||53|
|II||Introducing Windows NT DNS|
|5||How DNS Works||63|
|6||Nam Server Types||81|
|7||What DNS Knows||93|
|8||Dissecting Name Queries||113|
|9||How MS DNS Works with Other Servers||121|
|III||Using Windows NT DNS|
|10||Designing Your DNS Service(s)||127|
|11||Installing and Setting Up DNS||137|
|12||Integrating DNS with WINS||153|
|14||Working with Service Providers||195|
|17||Troubleshooting Tools and Utilities||231|
|18||Dynamic Host Configuration Protocol (DHCP)||249|
|A||Third Party Utilities and DNS Servers||265|
|B||RFCs on DNS, BIND, and NetBIOS||271|
|C||Top-Level Internet Domains||275|
|D||Registering Addresses on the Internet||281|
|E||Sample Network Traces for DNS Resolutions||301|
|F||Resource Records and the InterNIC Cache File||307|
[Figures are not included in this sample chapter]
This chapter will review:
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."
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.
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
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:
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.
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:
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
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
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:
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.
Four possible node types exist, specifying which method is used to resolve NetBIOS
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.
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 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.
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.
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 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.
|#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.
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