A DNS Primer

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.

   Previous  [1]  2  Next