With Active Directory, you’ll need to be able to manage DNS. This primer will get you started.

Let's Just All Get Along: DNS Fundamentals

With Active Directory, you’ll need to be able to manage DNS. This primer will get you started.

• By Michael Chacon
• 12/01/1998

With the introduction of Active Directory (AD) in Windows 5.0, Microsoft will bring a welcome new level of functionality to Windows NT. Active Directory is one of the last major pieces of the information system puzzle that must be in place for NT’s entry into the enterprise league. As I discuss in this month’s cover story (see page 26), part of that entry means that Active Directory must integrate into the Domain Name System (DNS) that already exists in most large networks.

Integrating the two will cause a substantial shift in the demarcation lines between the management of physical networks and operating systems. Traditionally, different groups within a company have managed LAN operating systems and the DNS. That’s because today, Windows NT administrative domains don’t have any direct relationship to DNS domains. This will change with Active Directory. Suddenly, these different administrative groups will have to work together more closely, because each group’s decisions will have an impact on the other groups’ activities. Therefore, as a Windows NT administrator, it’s important that you have a solid understanding of the architecture and functionality of DNS.

Windows NT 4.0 ships with a version of DNS that has added functionality to the standard versions to optionally look up WINS for NetBIOS name resolution while maintaining strict compliance with the RFCs. But before discussing Microsoft’s current version of DNS, it’s important to explore fundamental DNS functionality further.

DNS Fundamentals

First, you need to understand why host names exist in the first place. The fact is, humans find them easier to work with than IP addresses alone. A HOSTS file on every machine was a partial fix for this—in mapping host names to IP addresses—but a DNS is a central database that everyone can reference.

DNS is a distributed database of mappings between IP addresses and logical names of network devices. The names are organized into a hierarchical tree structure called the namespace. It’s similar to the directory structure of a hard disk in that it branches out as it deepens, creating unique names for every domain. This namespace is divided into parent and child relationships called domains and subdomains. At the top of this domain structure is the root domain. This root domain is represented as a “.” (period) and is managed by the InterNetwork Information Center (InterNIC) under the auspices of Network Solutions (www.internic.net). InterNIC controls the next level of domains, the one that most people are familiar with: .net, .com, and .org, and others. They follow an internationally agreed-upon standard. As Internet DNS systems continue to balloon, with more companies joining the fray, the types of domains allowed will be expanded.

Today, companies registering their chosen names with the InterNIC join the next level of domains: .microsoft, .sun, .hp, and .ibm, for example. Although the first two levels of the DNS system are centrally managed by InterNIC, each company handles its own domain administration independently, following accepted guidelines.

Once a company receives its domain name, it can create further subdomain levels, thus establishing a flexible hierarchy while maintaining unique names for all of the devices within the company’s domain. This area of independent management is called a zone. Each zone is determined by a set of database records defining its configuration. When a DNS name server contains the database records of a domain, it’s considered authoritative. The cooperation among various authoritative zones is what makes the entire system work.

As with any network device, there’s always the danger of hardware or connectivity failure with a DNS server. It is accepted practice to implement at least two DNS servers to handle name resolutions within your authority. In the likely event that you have slow connections between remote networks, you’ll also want more DNS servers to handle local name resolution. Using the classic master-slave database model, the main DNS server is called the primary; it receives its configuration information from local resource records. Secondary DNS servers then receive their configuration information from the primary server. This exchange of information from the primary server is called a zone transfer. A secondary server can also receive its information from another secondary server to reduce demands on the primary server, but the information for all secondary servers ultimately comes from the primary server. Any primary or secondary server that provides a zone transfer is also referred to as a master DNS server.

What’s actually being transferred are ASCII database files containing structured resource records. A DNS server normally contains several different database files and classes of resource records. The main database file is usually called db.domainname. The first record in all of the database files is called the Start of Authority record (SOA). The SOA record specifies that this name server is responsible for all of the domains instantiated in the zone records. The SOA record also specifies configuration information such as how often the DNS server will communicate with other servers, how long it will cache information, and how often and in what sequence the record has been changed. Another record is the Name Server (NS) Record, which lists all the DNS servers within your domain.

Address Record

The heart of the DNS server is the Address record, which lists the actual mappings of host names to IP addresses—the main function of the DNS server. This mapping also allows network designers to abstract the logical organization of the network from the physical subnets where the actual network devices reside. Different servers can belong to the same domain while residing in different subnets.

Most underlying IP networks consist of multiple subnets that are created to control packet traffic. The DNS namespace can span the subnets and create a logical view of the network resources for users to navigate.

For example, you might have three subnets, 122.0.0.0, 132.12.0.0, and 192.121.29.0, that exist in Los Angeles, San Francisco, and New York, respectively. Within each subnet you could have a server containing information for the sales staff that travels throughout the country. Instead of making users follow the IP subnet structure, you can use the DNS to build a logical structure by mapping the IP addresses to a consistent hierarchy, such as:

122.0.0.1 la-server.sales.company
132.12.0.1 sf-server.sales.company
192.120.29.1 ny-server.sales.company

Users can now refer to the individual servers by name, such as “la-server” or the fully qualified domain name, “sf-server.sales.company”. The DNS will resolve the appropriate IP address.

Six Degrees of DNS Server Separation

For a DNS to be useful, however, it must be able to communicate with other DNS servers. For this to work there must be an authoritative domain that knows how to locate all the other DNS servers (or that knows how to find other DNS servers that know all the other DNS servers). It’s similar to the notion that all people on the planet are related by six degrees of separation. Bill knows Jane who knows Sam who knows someone who knows Elvis. The difference, however, is that DNS has a center or, more appropriately, a top. The root DNS servers point to all the second-level DNS servers that we know as .com, .edu, .org, and so on. These second-level domains have the addresses of the organizations registered within each of these domains. These organizations are required to maintain their servers in a specific manner to foster 24-by-7 worldwide name resolution communication.

An organization with registered domains from the InterNIC can create any namespace structures they want within their authoritative domain. The domain names begin with the specific device followed by the increasingly general domain, such as server1.irv.sales.ascolta.com.

For example, the .irv domain might have authority over the .irv domain and any sub-domains created below the .irv domain, with a Start of Authority record declaring this. A request to server1.irv.sales. ascolta.com for resolution would first go to ascolta.com, which would point the request to the .irv domain containing the specific IP address for server1 in its address record.

Say a user in your domain wants to download information on the latest political tribulations from http:// thomas.loc.gov. Assuming no caching has occurred in your DNS server, the client—or resolver, in DNS terminology—will locate its DNS server for the address. (The DNS server location is specified in the client’s IP configuration.) The local DNS server will look in its address record and, when it doesn’t find the name, send a query to one of the thirteen “.” root-level servers. It obtains the address of the root-level server from a record in its database. The “.” server will have a pointer to a .gov domain server and send this information to your local DNS server. Your DNS will then send the query to the .gov server, which sends the address of the authoritative DNS server for the .loc domain, which will, in turn, return the address of the thomas server. Your DNS will then send the IP to name mapping obtained by the query to the client. The client will then use this address to establish a session with the thomas server.

This is fine, but you’d have serious performance degradation if you let every query follow this process. During the resolution process, your DNS learns about the namespace involved and saves this information in its cache. The next time a client using your DNS has a similar request, the DNS already has the necessary information and doesn’t need to go to the root DNS server, or the .com DNS server, to reach the resource. This caching prevents the top-level DNS servers from melting down from overload. However, any resolver query not held in cache will still require a trip to a root DNS server.

Here’s where the Time to Live parameter in the SOA record comes into play. The Time to Live parameter lets you configure how long cache information is allowed to remain in memory. You don’t want the cache to hold information for too long because mappings change over time with IP redesigns. There’s always a trade-off between keeping information in cache for speed and flushing the cache to maintain accurate mappings.

Tip of the Iceberg

These are just some of the basics of DNS functionality and architecture. You’ll need to dig much deeper if you plan to implement AD. See the resources listed in “Additional Information” to continue your studies.

What about the flat NetBIOS namespace or DHCP—allocated addresses? These present some challenges that the static and hierarchical records of the current implementation of DNS don’t address. They can make the Microsoft version of DNS an attractive option for an NT network. Next month, I’ll explore the added functionality that Windows NT 4.0 version brings to bear and how it integrates with the Unix-based DNS that’s already running in the back room.