Name Resolution

As useful as the 12-decimal-digit IP numbers (192.168.101.102) are when it comes to computers recognizing other computers, they're not the sort of information that human minds process very well (short-term memory can store a maximum of roughly seven "chunks" of information). Not only is there a limit to how many 12-digit numbers one can memorize, but also numbers can easily change.

IP version 6 addresses are 128 bits expressed in strings that can have as many as 32 hexadecimal characters, although they're often shorter. (Actually, IP version 6 addresses can even be written as 128 ones and zeroes, but that's not likely to catch on.)

Obviously, easy-to-remember names are preferable to strings of numbers or strings of characters and numbers. This section looks at how names are handled in the TCP/IP and Internet world.

The Domain Name System

The Domain Name System (DNS) was designed in the early 1980s, and in 1984 it became the official method for mapping IP addresses to names. With Windows 2000, DNS became the method clients use to locate domain controllers using Active Directory service. (The Lightweight Directory Access Protocol [LDAP] is used by clients to actually access the data stored in the Active Directory database.) Although there have been modifications to the overall structure of DNS, the overall result is still remarkably like the original design.

More Info

See RFC 1591 for an overall description of DNS, and RFCs 1034 and 1035 for the actual specification. RFC 2136 provides the specification for dynamic updates (Dynamic DNS), with which Windows 2000, Microsoft Windows XP, and later versions of Windows comply.

The Domain Namespace

The domain namespace describes the tree-shaped structure of all the domains from the root ("." or "dot") domain down to the lowest level leaf of the structure. It is a hierarchical structure in which each level is separated from those above and below with a dot, so you always know where you are in the tree.

Before the Internet moved to DNS, a single master file (Hosts.txt) had to be sent using FTP to everyone who needed to convert from numbers to names. Every addition or change required a revised copy to be propagated to every system. This obviously created enormous overhead even when the Internet was still quite small.

DNS overcomes the limitations of Hosts.txt files by maintaining a distributed database that is extensible to add information as needed. It permits local administration of local names while maintaining overall integrity and conformance to standards.

Root Domains

The root domains are the first level of the tree below the root. They describe the kinds of networks that are within their domain in two or three letters, such as .com for commercial domains and .edu for educational domains. The original root domains were functionally based and had a decidedly American slant. That's not surprising, given that most of the namespace was originally set up and administered by the U.S. Department of Defense.

As the Internet grew, however, this approach made less and less sense, especially with a distributed database like DNS that allowed for local administration and control. Geographical root domains were added to the functionally based ones, such as .it for Italian domains, and so on. See Chapter 3 for information about planning your namespace and domains.

How Names Are Resolved into Addresses

When you click a link to http://www.microsoft.com and your browser attempts to connect to that site, what actually happens? How does it find www.microsoft.com? The short answer is that it asks the primary DNS server listed in the TCP/IP Properties dialog box on your workstation. But how does that DNS server know where the site is?

Real World

Where Domain Names Come From and How You Get One

These days virtually every business (and many individuals) wants its own domain. The keeper and distributor of domain names used to be Network Solutions, formerly called InterNIC. Recently this task was opened up to competition, and there are now a myriad of companies that will register your domain name for you. The list is too big and volatile to include here—for a complete listing, visit the Internet Corporation for Assigned Names and Numbers (ICANN) Web site at http://www.icann.org. You can link to any of the accredited registrars from this site and perform a search to find out if your chosen name is taken.

Have alternative names in mind as well; you'll probably need them. After you research existing names and choose one that isn't taken, simply register the name with your chosen registrar.

After you acquire a domain name from a registrar such as Network Solutions, you need to properly set up the DNS hosting for the domain name. If you acquired the domain name through your Web hosting company, this is probably done automatically for you. Otherwise, follow the directions provided by your registrar to enter the addresses of two DNS servers that have DNS records for your domain name. If you're using a Web hosting company, these are that company's DNS servers. If you're hosting your Web site in-company, type the addresses of two company DNS servers that are accessible from the Internet and create the necessary DNS records on your DNS servers.

Long ago, domain names were free and forever, but those days are gone. If you don't pay your bill from your chosen registrar, your domain name is put up for grabs, and chances are that someone else will claim it before you're able to reregister it. The available short names are disappearing at a rapid rate, and many people are finding that they need to think up longer versions to find something that isn't taken.

When a TCP/IP application wants to communicate with or connect to another location, it needs the address of that location. However, it usually knows only the name it's looking for, so the first step is to resolve that name into an IP address. The first place it looks for the name is in the locally cached set of names and their IP addresses that it has resolved recently. After all, if you asked about http://www.microsoft.com just a few minutes ago, why should it go through the trouble of looking that name up again? It's not likely that the IP address will have changed in that time.

Suppose, however, that you haven't been on the Internet for a couple of days, and your computer doesn't have the address for http://www.microsoft.com cached. In this case, Windows queries your primary DNS server (specified in the connection properties for your Internet connection). If your DNS server doesn't have any recent information about http://www.microsoft.com the DNS server asks around to see whether anyone else knows the IP address.

This can happen in a couple of ways. The default method is to use recursion, in which the DNS server queries the root server of the domain, which passes back the location of the DNS server that is authoritative regarding the next level down in the domain, which the original DNS server then queries. This process recurs until it reaches a DNS server that contains the IP address of the desired host in its zone data.

You might want to disable the use of recursion on your DNS server if it is in use on an internal network and you want your clients to fail over to a secondary DNS server that handles name resolution for hosts outside your local network.

If you disable recursion on the DNS server, or if the client doesn't request the use of recursion, the DNS entry for the desired host is found by iteration. When using iteration, the DNS server checks its zone and cache data, and when it finds that it cannot complete the request, it sends the client a list of DNS servers that are more likely to have the host name in their zones. The client then contacts those servers, which might in turn respond with their own list, possibly even to the point that the client might query the Internet root servers looking for the appropriate DNS server.

You might want to enable the use of WINS lookup to search the WINS database for any names not located in the DNS zone data, providing for a complete search of both the DNS and NetBIOS namespaces.

Reverse Lookups

In most cases, you have a host name for which you need to locate the IP address, but in some instances you might have only an IP address for which you need to look up the host name. Reverse lookup was added to the DNS specification for this reason. The only problem with creating reverse lookups is the difference between the way the DNS namespace is organized and the way in which IP addresses are assigned. DNS names go from specific to general, beginning with the host name and ending with the root of the domain (the period at the end of a fully qualified domain name [FQDN]). IP addresses work in reverse fashion, so to facilitate the lookup of a host name from an IP address, a special domain, the in-addr.arpa domain, was created.

In the in-addr.arpa domain, the octets of an IP address are reversed, with in-addr.arpa appended to the address. For example, the IP address 10.230.231.232 is queried as 232.231.230.10.in-addr.arpa.

The reverse lookup zone is maintained as a separate database within the DNS database. The resource records (RRs) in the reverse lookup zone are of the type PTR (pointer). Much like pointers in common programming languages, or shortcuts in Windows, these PTR RRs simply refer to a different record—the associated A (address) record in the forward lookup zone. For example, the following list describes two records that a host might have:

• A record (forward lookup zone) srv1.scribes.com IN A 10.230.231.232
• PTR record (reverse lookup zone) 232.231.230.10.in-addr.arpa. IN PTR srv1.scribes.com

You can perform a reverse lookup of an IP address by typing nslookup followed by the IP address you want to look up at a command prompt. For example, if you type nslookup 10.230.231.232, the DNS server responds with the name and address of the DNS server, followed by the name and address of the host.

Dynamic DNS and Active Directory Integration

Dynamic DNS, which was new to Windows 2000 Server, makes DNS more flexible by permitting clients to update their DNS records dynamically. This capability eliminates the need to update DNS entries manually when clients change IP addresses. Unfortunately, the standard dynamic DNS service described in RFC 2136 allows for only a single-master model, in which a single primary DNS server maintains the master database of zone data (the addresses and host names for a particular domain). This database can be replicated with secondary DNS servers, but only the primary server can manage dynamic updates to the zone. If the primary server goes down, client updates to the zone aren't processed.

The dynamic DNS server in Windows 2000 Server can overcome the limitations of a single-master model and use Active Directory to store its zone data, permitting a multiple-master model. Because the Active Directory database is fully replicated to all Active Directory-enabled domain controllers, any domain controller in the domain can update DNS zone data. Using Active Directory to store the zone data also allows for added security features and simplified planning and management, as well as faster directory replication than is possible using a single-master model, because Active Directory replicates only relevant changes to the zone.

Zone Storage and Active Directory

A DNS server is required to support the use of Active Directory, so if a DNS server can't be found on the network when a server is being promoted to domain controller, the DNS service is installed by default on the domain controller. After Active Directory is installed, the storage and replication of your zones can be done in one of two ways:

• Standard zone storage using a text-based file With this method, zones are stored in .DNS text files located in the %SystemRoot%\System32\DNS folder. The filename is the same as the zone name you chose when creating the zone. Figure 13-2 shows part of a text DNS zone file.
• Directory-integrated zone storage Zones are stores in a dnsZone container object located in the Active Directory tree.

Figure 13-2. Zone storage in a text file.

The second method is preferred, not only because integrated zones are automatically replicated and synchronized whenever a new domain controller comes online, but also for reasons of administrative simplicity. Keeping a DNS namespace separate from the Active Directory namespace doubles your work (and your chances for error) when testing replication or modifying your domain, for example.

However, it is important to realize that using directory-integrated zone storage decreases the number of dynamic updates per second that the DNS server can process by a factor of two, and secure dynamic updates decrease this number by an additional 25 percent. Although performance varies widely depending on the hardware in question and what services are running, Microsoft found that a dual-processor Pentium II 400 system with 256 MB of RAM running Windows 2000 Server can process 900 queries per second and 100 dynamic updates per second with 30 percent processor usage when using a standard primary zone storage. The same hardware can process 50 dynamic updates per second when using directory-integrated zone storage.

More Info

DNS is one of the (many) subjects in this book that is a book-length topic in its own right. For more information on the configuration of DNS, consult the Microsoft Windows 2000 Server Resource Kit (Microsoft Press). For in-depth coverage of the subject, see DNS and BIND by Paul Albitz and Cricket Liu (O'Reilly & Associates).

Lightweight Directory Access Protocol

LDAP is used to access data in the Active Directory database. Once again, DNS is used to locate domain controllers, and LDAP is used to access the Active Directory data. LDAP runs on top of TCP/IP, and Active Directory supports both versions 2 and 3 of LDAP. Any LDAP product complying with these specifications can be used to access data in Active Directory. For more information on Active Directory and LDAP, see Chapter 2.

Dynamic Host Configuration Protocol

One of the problems facing organizations using TCP/IP these days is deciding how to manage internal IP addresses. This is a special concern for companies that hand out addresses that are Internet-valid. However, even if your company uses a private network, the chore of managing all the IP addresses can quickly become an administrator's nightmare, especially if you deal with intermittently connected computers such as laptops and remote computers. DHCP provides a simpler way to handle addresses for computers that are connected irregularly.

DHCP allows the administrator to assign the available IP addresses only as required. A mobile user can connect a laptop to the network when necessary and be assigned an appropriate address automatically. Likewise, a dial-in user doesn't need a permanent IP address; one can be assigned when the connection is made to the network, and when the connection is broken the address is made available for someone else's use. With DHCP, a modest pool of IP addresses can serve a much larger pool of users.

How DHCP Works To receive an IP address, the client computer sends out a DHCP discover broadcast, which a DHCP server picks up and responds to by offering the client an IP address for its use. The client responds to the first offer it receives and sends back to the DHCP server a request for the IP address offered. The DHCP server sends an acknowledgment telling the client that it succeeded in leasing the IP address for the amount of time specified by the DHCP server.

DHCP clients attempt to renew their leases at bootup, as well as after 50 percent of the lease time has passed. In this renewal process, the discover stage is skipped and the client simply begins with a request. If the renewal of the lease fails at the 50 percent mark, the client waits until 87.5 percent of the lease has passed and then attempts to acquire a new IP address by sending out a DHCP discover broadcast and starting the IP lease process again.

Using Multiple DHCP Servers Because DHCP uses UDP broadcasts, your DHCP servers don't see (and thus don't respond to) client requests on a different subnet unless the router between the two is configured to forward broadcasts. In most large establishments, this means separate DHCP servers for each subnet because broadcast traffic is an unnecessary burden on your routing capacity. In addition, you might want a second DHCP server configured (if not activated) for each subnet to provide for redundancy and to give your network a way to issue addresses if the main DHCP server fails.

If you do opt to allow your routers to pass along broadcasts, they must support RFC 1542 ("BOOTP") and be configured to forward broadcasts. Check the documentation for your router for configuration information; most new routers (and newer versions of router software) support this. If your router doesn't support RFC 1542 and you have clients that don't have access to a local DHCP server, you must configure a DHCP relay agent to forward client broadcasts to a DHCP server on another network segment.

Although you can use DHCP remotely with supported routers, it's best to situate your DHCP servers on-site. WAN failures do occur, and even a brief one can keep clients from being able to acquire or maintain an IP address. Letting a WAN be in a position to put your LAN out of business is a bad idea.

Windows 2000 Server supports integration of DHCP with dynamic DNS to facilitate the updating of a client's DNS record when the client receives a new IP address from a DHCP server. This feature fixes an incompatibility between DHCP and DNS that has existed until this point.

If you're still using static DNS servers on your network, you need to enable WINS lookup for DHCP clients that use NetBIOS to help avoid failed DNS lookups for DHCP clients. Whenever you can, however, replace or upgrade existing static DNS servers with dynamic DNS servers such as the one provided with Windows 2000 Server. If you want to use BIND, we recommend using version 8 or later, although using Windows 2000 DNS servers is the most painless method of providing DNS services to a Windows-based network.

Zone transfers between Windows 2000 and BIND version 9.x DNS servers might not work unless the Windows 2000 server is running Service Pack 3 or later.

Typically, you need one DHCP server for every 10,000 clients, though this number can be higher if you have large disk capacity and a fast CPU, or lower if your IP address class or network layout prevents this kind of server utilization. DHCP is very disk-intensive, so make sure that if your server will be handling a significant number of clients you have sufficient hardware, such as a large and fast redundant array of independent disks (RAID), adequate memory, and one or more fast CPUs. For information on evaluating the performance of your current system, see Chapter 33.

Real World

DHCP and Availability

DHCP itself does not support synchronization with other DHCP servers. If your network demands increased reliability, have a backup DHCP server offline with the same scope as the primary server, so if the primary server goes down you can bring the backup online immediately. (You can also use the Windows 2000 Server Cluster service to create a DHCP cluster.)

You might also want to split the address space between two DHCP servers, with the primary server handling 80 percent of the address space and the secondary server handling 20 percent. If the primary server fails, the secondary server handles all client leases from its 20 percent of the address space until the primary server is brought back online. If both servers are down, clients maintain their IP addresses until their leases run out.

If server reliability is a problem on your network, consider increasing the lease time to allow more time to bring servers back online before clients lose their addresses.

Windows Internet Name Service

NetBIOS is an interface originally developed to allow applications to access network resources in the Microsoft MS-DOS operating system. As such, it was the primary networking API and naming method for Microsoft networks until the release of Windows 2000.

NetBIOS host names are up to 15 characters long and part of a flat namespace, so all names on a given network must be unique. Normally, host names are resolved by broadcast—not the most efficient means in terms of either time or network bandwidth. Routers also usually do not forward NetBIOS broadcasts, eliminating the ability to resolve host names on a different subnet.

WINS was created to provide a solution to this problem by maintaining a dynamic database of IP addresses and their associated NetBIOS names. However, WINS is still limited in many ways by the underlying architecture of NetBIOS and it is now an optional service in a Windows 2000 network.

Although many of us might be eager to do away with WINS, it is still used by many companies to provide NetBIOS name resolution services to downlevel (legacy) Microsoft operating systems, such as Microsoft Windows 98 and Windows NT, that don't function properly in a NetBIOS-free network. (Windows 2000 and Windows XP don't require NetBIOS support.)

WINS is usually deployed in conjunction with DNS to provide optimal support for newer clients. Although BIND 8 and newer versions can be used adequately as a DNS server for Microsoft Windows .NET Server and Windows 2000 Server networks, BIND doesn't support WINS records, which can cause issues with DNS zone transfers. For this reason, stick with Windows 2000 or newer DNS servers if you need to use WINS servers on your network (although there are workarounds, as discussed in Chapter 14).

When deploying WINS servers on your network, deploy only the minimum number necessary to provide adequate service to your clients. WINS servers can be a pain to replicate, so keeping the number of servers down can be a big plus. (Microsoft itself, for example, used no more than about 12 WINS servers worldwide before moving to Windows 2000.) If you're doing any major restructuring of your network, consider upgrading earlier clients to Windows XP (or at least Windows 2000) and eliminating WINS from your network.

Don't install WINS on a multihomed server. WINS has enough replication problems without complicating the situation by placing the server on two subnets.

To make WINS and Browsing work correctly when you are in an enterprise environment with subnets and multiple domains, keep a few tricks in mind. There are three possible scenarios listed here, and each is discussed in the sections that follow:

• Single domain across a subnet boundary
• Multiple domains within a subnet boundary
• Multiple domains across a subnet boundary

Single Domain Across a Subnet Boundary

To see the resources of a single domain across a subnet boundary, with only TCP/IP as your protocol, you need to set up WINS servers on both sides of the router or mess around with Lmhosts files. Avoid Lmhosts files like the plague: They're a pain to get right in the first place and have to be manually edited every time there is a change anywhere. They also don't deal well with DHCP, under which IP addresses are subject to change. However, if you're setting up a virtual private network with Internet-connected clients, you might not be able to avoid Lmhosts because these clients don't have an available WINS server.

In general, it's a good idea to have a domain on each side of your router. The alternative is much more traffic across the router than you really want, because every authentication request has to cross over. The obvious choice is to put a WINS server in each domain. No special requirements need to be met for this to work because Browsing doesn't need to be told about another domain.

Real World

Browsing vs. browsing

A source of possible confusion in any discussion about Microsoft networking is the subtle distinction between the common meaning of the word "browsing" and the very specific meaning that the word has in Microsoft networking. Many texts use "browsing" to mean looking for or at the resources available, which is a reasonable use of the word. However, "Browsing" in the Microsoft networking sense refers to the Computer Browser service used by Windows-based computers to maintain browse lists of all shared resources on the network. It's easy to get confused, and we try to avoid that here by always capitalizing "Browsing" when using it in the Microsoft networking sense.

With the growth of networks and the introduction of directories such as Active Directory in Windows 2000, Browsing has become much less important. Most networks are too large to browse for resources, and Active Directory helps alleviate this issue by permitting you to query Active Directory for the resources you want. This makes finding resources easier, and also reduces the network traffic caused by Browsing.

Multiple Domains Within a Subnet Boundary

If you're running a forest within a single subnet, you might want a WINS server in each domain, but you don't need to do anything special with Browsing. You can set up and explicitly add the other domains to browse, but this step isn't required.

Multiple Domains Across a Subnet Boundary

Now we get to the tricky one. For everything to work in multiple domains across a subnet boundary, you need to set everything up very carefully. Because the Browsing packets don't cross the subnet boundary unless they know where they're going, you need to explicitly set the Computer Browsing service to browse the domain on the far side of the router. Each domain in the forest or tree needs to be configured to browse any domains on the far side of the router.

For the technical details of WINS and Browsing, see the Microsoft Windows 2000 Server Resource Kit. Once you have a network free of Microsoft clients earlier than Windows 2000 (Microsoft Windows Me doesn't count), you can happily turn off WINS and make your life a lot easier.