A DNS Primer

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 mark@acme.com. 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.