Name Resolution

[Previous] [Next]

As useful as the 12-decimal-digit IP numbers are when it comes to computers recognizing other computers, they're not the sort of information that human minds process very well. Not only is there a limit to how many 12-digit numbers one can memorize, but numbers can easily change. IP version 6 addresses are 128 bits expressed in strings that may have as many as 32 hexadecimal characters, though they're often shorter. (Actually, IP version 6 addresses could 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 has also become the method clients use to locate domain controllers using Active Directory. (The Lightweight Directory Access Protocol, or LDAP, is used by clients to actually access the data stored in the Active Directory database.) While 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 RFC 1034 and RFC 1035 for the actual specification. RFC 2136 provides the specification for dynamic updates (Dynamic DNS), with which Windows 2000 complies.

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 that 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 via FTP to everyone who needed to convert from numbers to names. Every addition or change required the Hosts file to be propagated to every system. This, obviously, created an enormous overhead even when the Internet was still quite small. DNS is 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 U.S. slant. That's not surprising, given that most of the namespace was originally set up and administered by the 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 ones, and so on. See Chapter 3 for information on planning your namespace and domains.

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 doman 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) website 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.

You should have alternative names in mind as well; you'll probably need them. After you've researched existing names and chosen one that isn't taken, simply register the name with your chosen registrar. Pay roughly $70(US) when they send you the bill or you'll lose the name. That fee is good for two years; then you'll be billed at about $35(US) per year.

Finally, you must create the necessary DNS records on your DNS server, or have your ISP do it. If you're connecting to the Internet through an ISP that is going to be maintaining your DNS records, by all means let the ISP do the work and set everything up, once you've done the name research.

Long ago, domain names were free and forever, but those days are gone. If you don't pay your bill from Network Solutions, your domain name will be 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.

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 window on your workstation. But how does that DNS server know where the site is?

When a TCP/IP application wants to communicate with or connect to another location, it needs the address of that location. But 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 www.microsoft.com just a few minutes ago, why should it go through all 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 DNS server doesn't have any recent information about www.microsoft.com. In that case the TCP/IP application asks around to see if anyone else knows the IP address. This can happen in a couple 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.

TIP

---

You may want to disable the use of recursion on your DNS server if your server is in use on an internal network and you want your clients to failover 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 to 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 may in turn respond with their own list, possibly even to the point that the client may query the Internet root servers looking for the appropriate DNS server.

TIP

---

You may want to enable the use of Windows Internet Name Service (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 may 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). 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 would be queried as 232.231.230.10.in-addr.arpa. This query locates the new resource record type PTR (pointer), which is used to map an address in the reverse lookup zone to the A record (address) of the desired host. Once the A record is found, the associated DNS name is then returned to the client.

Dynamic DNS and Active Directory Integration

Dynamic DNS, 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. Since 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 will be installed by default on the domain controller. Once 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 will be 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, as shown in Figure 13-3.

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

Figure 13-3. DNS zone stores in an Active Directory tree.

The second method is much 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.

MORE INFO

---

DNS is one of the (many) subjects in this book that is a book-length topic in its own right. For more on the configuration of DNS, consult the Microsoft Windows 2000 Server Resource Kit (1999), available from 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

The 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 of the IP addresses can quickly become an administrator's nightmare, especially if you deal with intermittently connected computers such as laptops and remote computers. The Dynamic Host Configuration Protocol (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 that the client can 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 won't see (and thus won'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 may well 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 should the main DHCP server fail.

If you do opt to allow your routers to pass along broadcasts, they must support RFC 1542 (BOOTP) as well as 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 do not 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.

TIP

---

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 poor gamble.

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. Unfortunately, the IETF did not finish the final specifications for dynamic updates between DNS servers before Windows 2000 was completed, so it is likely that this DHCP-dynamic DNS integration will work only with Windows 2000 DNS servers.

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, you should replace or upgrade existing static DNS servers with dynamic DNS servers such as the one provided with Windows 2000.

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 32.

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 may 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 Microsoft's MS-DOS operating system. NetBIOS host names are up to 15 characters long and part of a flat namespace, so that all names must be unique on a network. 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.

The Windows Internet Name Service (WINS) provides 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 is now an optional service in a Windows 2000 network. While many of us may be eager to do away with WINS, it will be around for quite some time to provide compatibility with downlevel (legacy) Microsoft operating systems such as Microsoft Windows 95/98 and Windows NT. 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, uses no more than about 12 WINS servers worldwide.)

TIP

---

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, you should keep a few tricks in mind. There are three possible scenarios listed here, and each will be 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'll 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. And they 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 may not be able to avoid Lmhosts, since these clients won'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, since every authentication request would have 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, since 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'll try to avoid that here by always capitalizing "Browsing" when using it in the Microsoft networking sense.

Multiple Domains Within a Subnet Boundary

If you're running a forest within a single subnet, you'll probably 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'll need to set everything up very carefully. Since the Browsing packets won't cross the subnet boundary unless they know where they're going, you'll 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 will need 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've gotten to a pure Windows 2000 network, with no downlevel clients, you can happily turn off WINS and make your life a lot easier.