A DNS Primer

How DNS works in Windows 2000

You might say DNS is an optional feature in Windows NT 4.0. Neither NT nor NT domains rely on DNS. In fact, most organizations running DNS servers don't run those servers on NT—they use UNIX, DNS's traditional OS home. You could theoretically complete an NT 4.0 MCSE certification without strong DNS knowledge.

Windows 2000 (Win2K) offers a different scenario for DNS. If a Win2K workstation needs to find a particular file share on a server, the workstation looks up the server's name in DNS to find the server's network address. Win2K workstations look in DNS to find a domain controller that they can log on to. (Win2K machines also use DNS to find Global Catalog servers—another important ingredient to logging on.) Finally, if a workstation must choose from a selection of domain controllers, DNS helps the workstation find a domain controller that is nearby rather than one that is a WAN communication away.

DNS is central to Win2K domains' functionality. To use DNS effectively, you need to understand some DNS fundamentals, such as DNS names and addresses, name registration, the DNS hierarchy, primary and secondary DNS servers, and DNS's integration with Active Directory (AD).

DNS Names and Addresses
Every computing device on the Internet has a unique 32-bit IP address (e.g., 154.23.17.8). When you run Internet-savvy programs, you can refer to these devices by their IP address. For example, you can point your Web browser to http://206.246.253.200 to access my Web site. However, most of us prefer to point our Web browser to a more human-friendly name such as http://www.minasi.com. The ability to use human-friendly names requires a database that can convert www.minasi.com to 206.246.253.200. Converting names to addresses is called name resolution.

Because few machines existed on the Internet in its early days, Internet-attached machines handled name resolution via a simple ASCII table—a HOSTS file—that listed IP addresses and machine names. (TCP/IP software still lets you place a HOSTS file on your system, but you probably won't ever need to use one.) Since 1984, machines on the Internet have chiefly used DNS to resolve names. Imagine needing to maintain on your computer a HOSTS file that not only contains the names of hundreds of millions of computers but also changes daily. With DNS, you don't need to worry about such a scenario.

As the Internet Engineering Task Force (IETF) Request for Comments (RFC) 952 defines, a computer's DNS name consists of several parts separated by periods. For example, www.minasi.com consists of www, minasi, and com. Each part can use no more than 24 characters. The only RFC-approved characters that can go into those name parts are the letters a through z, the numerals 0 through 9, the dash or minus character, and the period that connects the name's components. In addition, Win2K uses DNS names that use the underscore character—a feature that will affect your choice of DNS servers.

Registering a Name
To register a domain name, you go to a central organization called Network Solutions (http://www.networksolutions.com). Located in northern Virginia, Network Solutions uses many computers to run an Oracle database that keeps track of millions of registered domain names. You can go to the company's Web site and query those computers to find out whether someone has registered a particular domain name (e.g., acme.com). Because name registration is becoming decentralized, you'll soon be able to register a domain name with groups other than Network Solutions. (For more information about name registry decentralization, see Barry Sosinsky, News Analysis, "The Internet Name Game," September 1999.)

DNS's greatest strength is its hierarchically distributed nature. A query of Network Solutions' database will show that someone has registered the name acme.com, but the database won't yield any information about that domain. Network Solutions' computers can't tell you whether a particular computer in the acme.com domain exists—for example, you can't find out whether a computer named wile-e-coyote.acme.com or meepmeep.acme.com exists. Even if those computers existed, Network Solutions couldn't give you their IP addresses. Network Solutions neither knows nor cares about what goes on inside acme.com, and therein lies the beauty of the hierarchical system. To function, Network Solutions needs only the names of a few acme.com contact people, and the names and IP addresses of two computers that will act as DNS servers in that domain.

Suppose the domain name acme.com is still available, and you decide to register it with Network Solutions. You'd first give Network Solutions the names and IP addresses of two computers running some kind of DNS server. The computers could be machines inside the acme.com network, or you could simply pay your ISP to keep your DNS data on one of the ISP's DNS servers. (One machine can act as a DNS server for many DNS domains.) You decide to run one of these DNS servers locally on a machine called names.acme.com (IP address 217.44.93.5) and pay your ISP to run the other. The ISP puts your domain's DNS information on a server named ns2.safety-net.net (120.10.20.15). In DNS terms, those two DNS servers are authoritative for the acme.com domain.

With the correct software, any computer that runs TCP/IP can be a DNS server. The most popular implementation is UNIX's Berkeley Internet Name Domain (BIND), but I've seen implementations on IBM's mainframes and midrange systems, Digital's (now Compaq's) VAX systems, NT, and OS/2. DNS server implementations for DOS might exist. For the purpose of this article, I assume you're running DNS server software on NT.

Now suppose you create machines in the acme.com domain with names such as roadrunner.acme.com, www.acme.com, or coyote.acme.com. Remember, you don't need to tell Network Solutions about roadrunner, www, and coyote—the company doesn't care. Rather, you give the information to the two acme.com DNS servers (which you told Network Solutions about). Both DNS servers keep a database of information, called a zone file, about acme.com.

Meeting the New Host
The method you use to add a record that describes a new computer—a new host, in DNS terminology—to a DNS server's zone file varies according to the DNS server software that you're running. Most DNS servers use zone files that are ASCII files, so simple file editing would inform a DNS server of the new machine in town. Other DNS server implementations (e.g., in Win2K and NT 4.0) offer GUI front ends.

Recently designed DNS server software doesn't require you to inform the software about a new host because the software follows a standard called dynamic DNS (DDNS). RFC 2136 describes DDNS in detail. In a DDNS-compliant network, computers can introduce themselves to DNS without requiring an administrator to add the new computers to the DNS zone files.

Using the Hierarchy
After the acme.com DNS servers have the records for roadrunner, www, and coyote in place, you can see how the DNS hierarchy works. Suppose someone from a domain named products.com points a Web browser to www.acme.com. That browser asks the local domain's DNS server for www.acme.com's IP address. The products.com DNS server doesn't know the answer, but it knows about 13 DNS servers (which Network Solutions and other organizations operate) that know the names and addresses of the DNS servers for each Internet domain. These servers, which are at the root of the DNS tree, are called root servers. The products.com DNS server asks one of the 13 root servers for www.acme.com's IP address. The root server responds that it doesn't know but that the machines that would know are the two authoritative DNS servers for the acme.com domain—the machines with IP addresses 217.44.93.5 and 120.10.20.15. So, the products.com local DNS server opens hailing frequencies to 217.44.93.5 and again asks for www.acme.com's IP address. The machine at 217.44.93.5 responds with www.acme.com's address, and the name resolution is complete.

Zones vs. Domains
You can further extend DNS's hierarchy. Suppose you have a West Coast office and an East Coast office. Each office wants to run a local DNS server. To accommodate the two offices, you can add a level to acme.com's machine names: Instead of ending with acme.com, each machine's name ends with westcoast.acme.com or eastcoast.acme.com. Each DNS server has a DNS domain subsection (or zone, in DNS jargon). The central acme.com DNS server now keeps the names of only a few hosts. In addition, it keeps track of the fact that two zones now exist, and it stores the names and addresses of the authoritative DNS servers for those zones.

Thus, if the machine named roadrunner is at the West Coast office, the machine gets the name roadrunner.westcoast.acme.com. The offices have separate DNS servers, so a name resolution query from outside the organization would require another round of DNS server queries. A products.com DNS server that wants to retrieve roadrunner.westcoast.acme.com's IP address would first query Network Solutions for the addresses of the acme.com DNS servers. The main acme.com DNS server, unable to provide the IP address, would direct the products.com DNS server to the main acme.com DNS server. The main acme.com DNS server, recognizing that the query is about a West Coast machine, refers the query to the specific DNS server for the West Coast. Finally, that West Coast DNS server gives the products.com DNS server the IP address of westcoast.acme.com's DNS server.

The name structure is completely hierarchical. When you separated acme.com to two coasts, you didn't need to inform Network Solutions. Systems that need an address from one coast simply discover where to find addresses as they thread their way through the DNS hierarchy.

Although I describe a hierarchy of names with the root servers at the top, you needn't use that hierarchy. If your network isn't connected to the outside world, you can define your own top-level or root servers. (For more information, see Inside Out: "A Root of Your Own," November 1999.)

Locating Mail Servers
Another useful DNS feature is the ability to locate a domain's email servers. If I have a user account called mark in the acme.com domain, I'd like people to be able to send mail to [email protected]. But email needs to go from email server to email server. Suppose I have a friend named Tom at domain apex.com, and Tom wants to send me an email message. His email server must find acme.com's email server. How does this server-to-server rendezvous take place?

To answer that question, consider how you find servers in another popular Internet application—the Web. If you want to examine acme.com's Web page, how do you find the Web server's address? You'd guess that its name is www.acme.com (and you'd probably be right), but a more formal way to find the name of a Web server in a given domain would be nice. No such capability exists, but you can look up the name of an email server in a specific domain. Zone files can contain a mail exchanger (MX) record that names the zone's email server.

Primary and Secondary DNS Servers
You've probably guessed the reason why you need two DNS servers—reliability. If one server goes down, the other can perform acme.com's name-resolution functions. But how do you keep the servers synchronized? If you add a machine named yosemitesam.acme.com to the domain, how do you ensure that both the names.acme.com DNS server and the ns2.safety-net.net DNS server receive that information? Simply designate one server to be a primary DNS server and the other to be a secondary DNS server.

I do all my acme.com zone file editing on the primary DNS server. Then, the primary server sends the most recent zone file information to the secondary server. When a machine queries the secondary server about acme.com, the secondary server answers the query from its copy of the zone file. The secondary server's zone file typically has a Time to Live (TTL) period. If the primary DNS server doesn't update the secondary server's zone file within this expiration period (i.e., a certain number of hours), the secondary server assumes that all the zone information is stale and disregards it. The TTL period is typically 24 hours or more, so if the primary DNS server is down for only a few hours, you won't experience a problem.

Which DNS server is the primary server, and which is the secondary server? Network Solutions doesn't know or care; you won't find that information in the company's database. You determine which DNS server is the primary name server in the Start of Authority (SOA) record. The SOA record also tells secondary DNS servers how long to keep old zone file information, specifies the TTL period, and reports the email address of the domain's technical contact.

You can have as many secondary DNS servers as you want. This scenario might sound familiar. In many respects, primary and secondary DNS servers are similar to PDCs and BDCs in NT 4.0 and NT 3.x.

DNS and Windows 2000
With MX records, standard DNS lets you easily find the email servers for a particular domain. RFC 2052 lets you look up other kinds of servers via a new kind of DNS record—an SRV record. An SRV record lets you ask a DNS server whether it knows of any machines that act as servers of a specific type. Win2K-aware machines look in the SRV records to find domain controllers.

Win2K-aware machines exploit another DNS feature: DDNS. When a Win2K client machine starts, it asks its local DNS server to add the client name to the zone database. Although pre-Win2K systems don't know to ask the DNS server to add them to the zone database, Win2K's DHCP server accomplishes the task for them. So, even legacy machines get added to the local zone file. Win2K blurs the line between NT domain and DNS domain. A DNS zone file under Win2K functions similarly to a WINS database under NT 4.0 and earlier.

Win2K uses DDNS in another way. When you create or modify an AD-based domain, the domain controller automatically reflects that domain's structure in the domain's zone files. And the domain controller uses DDNS to enter those records into the DNS database.

Microsoft's DNS Server
To benefit fully from the integration of DNS and AD, you don't need to use the DNS server that ships with Win2K. However, you can't continue using a 1992 copy of BIND.

To work with Win2K, DNS servers must satisfy a couple of prerequisites. First, the DNS servers must support RFC 2052 (the SRV record type) and RFC 2136 (DDNS). Many current DNS server products (including the current version of BIND) offer such support. Second, the DNS server must accept host names that include the underscore character. Many of the records that AD automatically creates include underscores. Because DNS doesn't accept underscores by default, many recent DNS implementations won't accept DDNS registrations on names that include underscores. Alternatively, you can divide your existing DNS domain into two or more zones, place the Win2K and NT machines into a new zone, make a Win2K system the authoritative DNS server for only that zone, and leave all your other machines in the old zone.

In Your Hands
To fully understand DNS, you need to know how the international DNS hierarchy functions, how new RFCs extend DNS's power, and how you can fit your organization into the DNS hierarchy. All these pieces fit together to make DNS the perfect choice for a Win2K naming infrastructure.