With Active Directory, youll 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.
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 NTs entry into the enterprise league.
As I discuss in this months 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. Thats because today, Windows NT administrative
domains dont 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 groups decisions
will have an impact on the other groups activities.
Therefore, as a Windows NT administrator, its 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
Microsofts current version of DNS, its important
to explore fundamental DNS functionality further.
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 thisin mapping
host names to IP addressesbut 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. Its 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 companys 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, its considered authoritative. The cooperation
among various authoritative zones is what makes the entire
As with any network device, theres 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, youll 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.
Whats 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.
The heart of the DNS server is the Address record, which
lists the actual mappings of host names to IP addressesthe
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, 188.8.131.52,
184.108.40.206, and 220.127.116.11, 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:
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). Its
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
clientor resolver, in DNS terminologywill
locate its DNS server for the address. (The DNS server
location is specified in the clients IP configuration.)
The local DNS server will look in its address record and,
when it doesnt 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 youd 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 doesnt
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.
Heres 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 dont want the cache to hold
information for too long because mappings change over
time with IP redesigns. Theres always a trade-off
between keeping information in cache for speed and flushing
the cache to maintain accurate mappings.
A classic resource of DNS Information
is DNS & BIND by Paul Abitz
and Cricket Liu (O'Reilly and Associates,
#32.95, ISBN 1-56592-512-2).
You can also read the RFC source descriptions
available at www.rfc-editor.org
as well as other locations on the Internet.
RFC 1034 covers domain names, concepts,
and facilities; and RFC 1035 covers
domain names, implementation, and specification.
But with Windows NT, you'll still need
more information than what's provided
in the standard DNS descriptions. Another
good source of this information is Chapter
9 of the Networking Guide in the NT
4.0 Server Resource Kit.
Tip of the Iceberg
These are just some of the basics of DNS functionality
and architecture. Youll need to dig much deeper
if you plan to implement AD. See the resources listed
in Additional Information to continue your
What about the flat NetBIOS namespace or DHCPallocated
addresses? These present some challenges that the static
and hierarchical records of the current implementation
of DNS dont address. They can make the Microsoft
version of DNS an attractive option for an NT network.
Next month, Ill explore the added functionality
that Windows NT 4.0 version brings to bear and how it
integrates with the Unix-based DNS thats already
running in the back room.