Dns On Windows Server 1002003 [Electronic resources] نسخه متنی

11.2 WINS Linkage

Our next topic requires a short detour into the world of Microsoft
networking. Networks based on NetBT (NetBIOS over TCP) need to
perform name resolution, too: hosts need a way to map NetBIOS
names^[3] to IP addresses. The way this name resolution works has
evolved over time. In the early days, hosts broadcasted a query on
the LAN to resolve a NetBIOS name. This forced all hosts to listen to
every broadcast. Since broadcasts don't leave the
local LAN, this method didn't allow name resolution
beyond the local network segment. The next evolutionary step was the
LMHOSTS file, which is just a list of NetBIOS
names and IP addresses. Every host needed an
LMHOSTS file to resolve names beyond the local
subnet. This model didn't scale very well, either:
it was tough to keep the LMHOSTS files up to
date and distribute them. And the introduction of the Dynamic Host
Configuration Protocol (DHCP) essentially made basing a
network's NetBIOS name resolution on
LMHOSTS files
impossible.

^[3] A host's NetBIOS name is
simply the name by which it's known for NetBT
networking purposes. NetBIOS names are limited to one label of up to
15 octets (that is, no multiple-label names like DNS domain names).
On Windows Server 2003 systems, a host's NetBIOS
name is derived automatically from the host's fully
qualified DNS name, which is called the computer name and is set in
the System Properties
window's Computer
Name tab (choose Control
Panel System). The NetBIOS name is forced to be the
first label (i.e., everything to the left of the leftmost dot) of the
host's DNS name. Windows 2000 allowed the NetBIOS
name to be different from the DNS name, but that feature
didn't carry over to Windows Server 2003.

A detailed description of DHCP is beyond the scope of this
book,^[4] but
suffice it to say that DHCP eliminates the requirement of configuring
a static IP address on every one of your hosts. If those hosts
support DHCP, they can contact a DHCP server when they boot to obtain
an IP address and other configuration parameters, such as the IP
addresses of the default router, name servers, and WINS servers.

^[4] But see another book from
O'Reilly: TCP/IP Network
Administration by Craig Hunt.

WINS, which stands for Windows Internet Naming Service, is a
Microsoft invention introduced in Windows NT 3.5. The server
component of WINS is an implementation of a NetBIOS Name Server as
described in RFCs 1001 and 1002. The idea is nothing new; the RFCs
date from early 1987. The function of a NetBIOS Name Server is
simple: it maps NetBIOS names to IP addresses.

The name and IP address information in a WINS server comes from the
various hosts on the network. Once a host sets its IP address using
the value sent by a DHCP server, the host registers its name with the
WINS server the DHCP server told it about. Actually, any modern NetBT
host registers its name with a WINS server (if it is configured to
use a WINS server, of course), regardless of how it obtained its IP
address (e.g., dynamically from a DHCP server or statically from a
user-input configuration). Modern NetBT hosts also know to contact a
WINS server for NetBIOS name resolution, rather than relying solely
on broadcasting or an LMHOSTS file.

So where does DNS fit in to all this? Before Windows
2000's support of dynamic update, it
wasn't possible to make the new name-to-IP address
mappings generated by the DHCP server visible to DNS. Microsoft
realized there would be some value to enabling a DNS server to query
a WINS server, which knows about names for dynamically assigned IP
addresses. After all, a NetBIOS name in the WINS server is usually
the same as a machine's hostname (the first label of
its fully qualified domain name in DNS), which is what it would be in
the DNS server if there were an easy way to get it there. (Remember,
we're talking about the days before Windows 2000
with its improved integration with DNS.) So a Microsoft DNS Server
can be configured to ask a WINS server when it receives a query for a
domain name that's not in its zone data.

You may be thinking that a name server contacting a WINS server is
kind of silly; isn't there a way for name servers to
know what the DHCP servers are doing directly? There is. In a network
with Windows 2000 or Windows Server 2003, DHCP servers can update
name servers using dynamic update after every address assignment, as
we discussed earlier in this chapter. The importance of WINS in
recent versions of Windows (Windows 2000 and Windows Server 2003) is
greatly reduced, too. Modern Windows hosts allow domain names (which
are resolved with DNS) to be used in places where previously only
NetBIOS names (typically resolved with WINS) were allowed. WINS is
still required to support older, legacy clients. You can find more
information about how modern Windows hosts use DNS for hostname
lookups in Chapter 6.

11.2.1 Configuring WINS Lookup

WINS
lookup, as it's called, is enabled on a zone-by-zone
basis using the WINS tab of a
forward zone's properties window. When the DNS
server receives an address (A) record query for which it
doesn't know the answer, if the zone where the
record would exist has WINS lookup enabled, the DNS server queries a
WINS server. The NetBIOS name sent to the WINS server is the first
label of the domain name in the A record query. For example, if the
domain name in the A record query is
terminator.movie.edu, the NetBIOS name queried
is terminator. If the WINS server responds with
an IP address for terminator, the DNS server
synthesizes an A record for terminator.movie.edu
and returns it to the original querier.

The WINS lookup configuration for the movie.edu
zone on the zone's primary,
terminator, is shown in Figure 11-6.

Figure 11-6. WINS lookup settings for movie.edu

WINS lookup is enabled by checking the Use WINS
forward lookup box. You can specify the IP addresses of up
to eight WINS servers, and the DNS server will try them in the order
listed.

By default, the WINS lookup configuration you establish on the
primary takes effect on the secondaries as well. The primary inserts
a special WINS record that gets transferred with the rest of the zone
to the secondaries. If the secondaries are Microsoft DNS Servers,
they understand the WINS record and perform WINS lookups accordingly.
If the secondaries are BIND name servers, they complain about the
unknown WINS record. You can suppress sending this WINS record to the
secondaries by checking Do not replicate this
record.

The Time to live (TTL) field in the
lower left corner specifies the TTL for the synthesized A records
that result from WINS lookups.

Pressing the Advanced button yields
a window like that in Figure 11-7. Cache time-out controls how long the DNS
server will cache the synthesized A records. The default value is 15
minutes. That value may seem small, but it's a good
choice: information in the WINS server is transient by nature, so you
don't want the DNS server to hold onto it for a long
time. If it needs a name again, the DNS server can just ask the WINS
server for it. Lookup time-out
controls how long the DNS server will wait after querying a WINS
server. The default is 2 seconds.

Figure 11-7. Advanced WINS lookup settings

You can enable WINS lookup on in-addr.arpa
zones, too. It's called WINS reverse lookup, and
it's implemented differently than plain WINS lookup.
When the name server receives a PTR query it can't
answer and WINS reverse lookup is enabled for the zone, it sends a
NetBIOS Adapter Status request directly to the IP address referenced
by the PTR record. In other words, the name server asks the host
directly what its name is. The name server can't ask
a WINS server because lookups based on IP address
aren't supported: you can't give a
WINS server an IP address and get the corresponding NetBIOS name
back. WINS servers have obviously never heard of
Jeopardy! ("The host with IP
address 192.249.249.3.," "What is
terminator?")

WINS reverse lookup is configured
similarly to WINS lookup: select the WINS-R tab of the zone properties window of
any in-addr.arpa zone. The WINS reverse lookup
configuration for the 249.249.192.in-addr.arpa
zone on the zone's primary,
terminator, is shown in Figure 11-8.

Figure 11-8. WINS reverse lookup settings for 249.249.192.in-addr.arpa

Use WINS-R lookup enables the
NetBIOS Adapter Status requests for unknown PTR records in this zone.
Do not replicate this record has the
same effect as its WINS forward-lookup counterpart. If you look in an
in-addr.arpa zone datafile, though,
you'll see a WINS-R record instead of a WINS record.
The Domain to append to returned
name field takes a DNS domain name that will be appended
to the NetBIOS name returned by the host to form a fully qualified
domain name. The Advanced button
controls cache and lookup timeouts, just like its WINS forward-lookup
counterpart.

11.2.2 Using WINS Lookup and WINS Reverse Lookup

What's WINS lookup
good for? In most networks, not a lot. For one thing, Windows Server
2003 integrates tightly with DNS so that in a properly configured
network, all Windows hosts have forward- and reverse-mapping
information in DNS. (More information about this new integration with
DNS is found in Chapter 8.) But
let's say you still have a lot of older Windows
hosts on your network. Do you need WINS lookup? Well, we still
can't get excited about it. Think about it this way:
the names that get resolved the most are the servers, and they
usually have fixed IP addresses and thus static DNS entries.
They're resolved directly in DNS, not via the WINS
lookup detour. Most networks don't have much
peer-to-peer networking; your average desktop host usually
doesn't offer network services, such as a web
server, name server, and so on. It's the need to
reach those kinds of network services that requires DNS name
resolution to work for every host. (Sure, there's a
lot of NetBIOS-based file and print sharing among desktop hosts, but
that process uses WINS natively.)

If you do need to support WINS lookup in your network, a big problem
with it is that the standard BIND name server
doesn't support it.^[5] Many people find that
they need WINS lookup after they have a DNS infrastructure in place
using BIND name servers. One option is to replace all those name
servers with the Microsoft DNS Server and enable WINS lookup.
That's not realistic for most people. A better, but
not perfect, option is to create a new subdomain for DHCP clients
resolvable via WINS lookup and delegate the subdomain to a set of
Microsoft DNS Servers.

^[5] MetaInfo, a
subsidiary of Check Point, has ported BIND to Windows and added WINS
lookup and WINS reverse lookup. See
http://www.metainfo.com/.

For example, let's say the folks running the domain
acme.com suddenly find themselves with dozens of
PCs doing peer-to-peer networking with DHCP-assigned IP addresses.
Since they've already got a BIND infrastructure in
place, they decide to create the domain
pcs.acme.com for these PCs. (The domain name
could be anything: dhcp.acme.com,
wins.acme.com, whatever.) They configure a
couple of Microsoft DNS Servers for this zone and enable WINS lookup.
Finally, they delegate to the pcs.acme.com zone
from the acme.com zone.

In practice, we find WINS reverse
lookup is much more useful. It's really nice to have
complete reverse-mapping information for your network in DNS.
Network-management applications can report names rather than IP
addresses. Web servers can log usage statistics by name and make
named-based authorization decisions, such as giving access only to
hosts in the movie.edu domain. Troubleshooting
is easier as well. Without WINS reverse lookup, the name server
can't reverse map dynamically assigned IP addresses
in networks with older Windows hosts. Of course, for you to be able
to use WINS reverse





lookup
in your network, all the name servers for your
in-addr.arpa zones need to support it.