MICROSOFT has borrowed yet another page from the Unix playbook: Domain Name System (DNS) is now a part of the Windows NT game plan. DNS first showed up under the NT 3.51 Resource Kit and emerged as part of NT 4.0. Once you understand what DNS does, how to configure it, and how to install it, DNS can help you locate remote computers by name.
Resolving Addresses with DNS
When you use FTP, email, or even a Web browser to connect to a remote
computer, your computer needs to resolve user-friendly names such as mail
addresses ([email protected], [email protected]) and host addresses
(ftp.microsoft.com, www.whitehouse.gov) into the cryptic IP address
(204.241.137.2) of the destination computer so that your computer can send
packets over the network. DNS is a way to resolve addresses on a TCP/IP network.
Before DNS, to point your Web browser to a universal resource locator (URL) such as http://www.microsoft.com, you had to know that www.microsoft.com was running on a computer with IP address 207.68.137.35 and type that address into the URL field. Similarly, to send mail to [email protected], you had to tell your mail client that the computer with IP address 204.241.136.3 handled Spyros's mail. The alternative to memorizing these various addresses was to have a table on your computer that mapped the URL or mail address to an IP address. If your desktop was a Unix system, this local table was the file /etc/hosts or /etc/resolv.conf; if your desktop was an NT or Windows 95 system, the file was \system32\drivers\etc\hosts.
The problem with a local table was that you had to get a copy of a hosts file with every IP address of any remote host you might need to contact. This approach made finding computers on the Internet almost impossible--you had to distribute huge files daily to every desktop in your network to access the outside world. Imagine getting, in advance, the IP address of every computer that handled mail for every recipient your users might want to send email to next week!
With DNS, you simply point your desktop to one computer (local or on the Internet), the Domain Name Server. It contains the addresses for some computers and knows who to ask for any other addresses. You no longer need to distribute hosts files to the desktop--you update only the Domain Name Server with the names of the computers in your network. In the past, setting up a Domain Name Server was possible only on a Unix platform (though your desktops could be NT- or Windows-based). With the NT 3.51 Resource Kit and NT 4.0, you can set up a Domain Name Server on NT.
DNS Components
The major components of DNS are the Domain Name Space and Resource Records
(RRs), Domain Name Servers, and Domain Name Resolvers (DNRs). The Domain Name
Space is a tree-structured name space with the domain names and associated data.
For example, the domain ftp.paradigms.com is a node in the paradigms.com domain,
which is a node in the com domain. Data associated with ftp.paradigms.com
includes its IP address. When you use DNS to find a host address, you are
querying the Domain Name Space to extract information. RRs let you maintain the
overall DNS configuration information on a record-by-record basis.
A Domain Name Server is a computer that provides information about a subset of the Domain Name Space, such as the paradigms.com domain. The two types of Domain Name Servers are primary and secondary. A primary server stores configuration files with information about the subset of the name space for which the server is authoritative. A secondary server doesn't own configuration files, but loads data from the primary server in a process called a zone transfer. These Domain Name Servers provide performance and availability benefits because you can split the workload between servers, and if one goes down, the other can take over.
One Domain Name Server points to others with information about other subsets of the Domain Name Space. When you query a Domain Name Server, it returns information if it is an authoritative server for that domain. If the server doesn't have the information, it refers you to a higher level server, which can refer you to another server, until it locates the one with the requested information. In this way, no one server needs to know about all the hosts you might need to contact.
A DNR is a program that extracts information from Domain Name Servers so you can use host addresses instead of IP addresses in clients such as a Web browser or an FTP client, or with utilities such as ping, traceroute, or finger. The DNR is typically built into the TCP/IP implementation on the desktop, and needs to know only the Domain Name Server's IP address.
For example, after you configure TCP/IP on NT Server, you can enter the IP address of up to three Domain Name Servers. Select the Network applet in the Control Panel, highlight TCP/IP, and click Configure to open the TCP/IP Configuration dialog you see in Screen 1. The IP information will appear in this screen. Click on the DNS command box to open the DNS Configuration dialog you see in Screen 2. The DNS Search Order box lists up to three Domain Name Servers. Based on the entries shown in Screen 2, if you run a Web browser on the current system and enter http://www.paradigms.com, the system will query the DNS at 204.241.138.10 for the IP address of the www.paradigms.com. If the DNS responds with an IP address, the browser looks to that host; if the DNS at 204.241.138.10 is down, the current system will query the DNS at 38.8.32.2.
You can apply to InterNIC, the organization that manages US Internet domains, for valid IP addresses for your network and to register a domain name. Point your Web browser to http://ds1.internic.net/ds/dspg01.html, InterNIC's Directory and Database Services page.
Typically, however, you contract with an Internet Service Provider (ISP) to register your domain, get an IP address for your network, and establish a physical connection to the Internet. You then connect to the ISP through a dial-up Point-to-Point Protocol (PPP) connection or leased line. Invariably, the ISP runs DNS, which probably will be the Domain Name Server responsible for your domain's data. For reasons of control or cost, you can run your own DNS. If so, you can use native services on NT Server. You need at least two Domain Name Servers: If one goes down, users can still look up the names of servers on your network.
Configuring DNS
When DNS starts, it reads a local boot configuration database. Under Unix,
it's usually a file named /etc/named.boot; under NT Server 3.51, it's
\system32\drivers\etc\boot; and under NT Server 4.0, it's the file
\system32\dns\boot or a Registry entry (you can start DNS from a file or from
the Registry as you'll see in part 2 of this series). This database points DNS
to the configuration files (domain files, reverse lookup files, and a cache
file) on the primary Domain Name Server, both for the database's Domain Name
Space and for hosts in other domains. Let's focus on the boot file and the
configuration files it points to.
The Boot File
DNS reads the boot file or Registry entry to locate the database files. Four
main types of records are in the boot file. The syntax for these files is
directory <pathname>
cache <filename>
primary <domain> <filename>
secondary <domain> <hostlist>
In NT Server 3.51, the directory entry specifies the pathname for the directory where DNS stores the DNS database files. Leave this entry commented out so you get the default directory (system32\drivers\etc\). In NT Server 4.0, you must put the files in the directory \system32\dns.
Listing 1 shows an example boot file. The cache entry shows that entries for domains above the current one are in a file called cache. The primary entries in Listing 1 show that the configuration records for the paradigms.com domain are in the file paradigms.dom, for the patmos.com domain in the file patmos.dom, etc. Finally, the secondary entry in Listing 1 shows that this Domain Name Server functions as a secondary server for the aegean.com domain and that the primary server for this domain is on the host at 204.241.138.5.
You can set up a computer (loki.paradigms.com) as the primary (authoritative) Domain Name Server for the domain paradigms.com and another computer (surtur.paradigms.com) as a secondary Domain Name Server. Loki maintains the paradigms.dom file with the IP addresses of the hosts in the domain. When DNS on loki starts, loki can respond to requests from any DNR. Surtur maintains a boot file that identifies surtur as loki's secondary server; surtur doesn't maintain any configuration files for paradigms.com. If the boot file on loki is the same as in Listing 1, the boot file on surtur is
cache
secondary paradigms.com
cache 204.241.136.2 paradigms.dom
When DNS starts on surtur, it queries 204.241.136.2 (loki) for information on the paradigms.com domain, copies the configuration file paradigms.dom, and can respond to DNR queries for that domain. In NT 4.0, the zone transfer begins when DNS starts and completes after the files are copied. If you look at the System Log in the Event Viewer on \\surtur, you see a message with Source=DNS and EventID=701 showing the zone transfer: Zone paradigms.com in sync with version 995071201 at DNS server at 204.241.136.2.
This message tells you that the configuration files on the primary Domain Name Server are synchronized with the read-only copy at the secondary server, and no zone transfer was necessary. DNS compares a manually entered version number in the configuration files to determine whether both server files are identical. In addition, the zone transfer repeats according to the timing parameters you enter in the configuration files. If the configuration files on the primary server change, the message on the secondary server will read New version 995071202 of zone paradigms.com found at DNS server at 204.241.136.2. Zone transfer is in progress.
This message means DNS at the secondary server found a difference between the version number of the configuration file at the primary server (\\loki) and its local version number, and requested the updated file. A corresponding message in the Event Viewer on the primary server (\\loki) will read DNS Server transfer of zone paradigms.com to DNS Server at 204.241.136.3 successfully completed.
This message shows that the DNS on the primary Domain Name Server sent the configuration files to the secondary server (\\surtur) and placed an updated version of the configuration files in the \system32\dns directory. When the boot file loads, it points to three types of configuration files: domain files, reverse lookup files, and the cache file.
Domain Files
The domain files contain RRs--RFC 1034 defines these records. The main RR
types are Statement of Authority (SOA), which identifies the authority
for this domain data; Name Server (NS), which lists a name server for
this domain; Address (A), which provides name-to-address mapping; CNAME,
which allows canonical names (aliases); and Mail Exchanger (MX), which
identifies the mail exchanger.
The SOA record identifies the server with authority to define the hosts in its Domain Name Space. Listing 2 shows a sample SOA record. The SOA record is usually at the beginning of the domain file--in this case, paradigms.dom. Listing 2 shows that the server loki.paradigms.com is authoritative for that domain and mail administrator is spyros. You also see various default parameters for the operation of the DNS (e.g., a version number of 1996031201--the number that tells the zone transfer process whether the file on the primary is more recent than the file on the secondary--and a refresh time of 10800 seconds--the time after which the Domain Name Servers perform a zone transfer regardless of whether the domain files changed). If a DNR queries the ISP's DNS for the authoritative server for paradigms.com, the answer will be loki.
The NS record identifies servers running DNS in a domain. For two servers in the paradigms.com domain, the NS record entries might be
paradigms.com. IN NS
surtur.paradigms.com.
paradigms.com. IN NS
loki.paradigms.com.
This entry tells a DNR that surtur and loki run DNS for paradigms.com. The DNR doesn't care that loki is authoritative, and nothing in the NS record identifies which is the primary or secondary server. To find out, query the SOA record.
Address (A) records and CNAME records provide name-to-address mappings so a DNR can find systems by name. The name-to-address mappings for the paradigms.com domain might be
loki.paradigms.com. IN A
204.241.136.2
surtur.paradigms.com. IN A
204.241.136.3
athena.paradigms.com. IN A
204.241.136.6
ftp.paradigms.com IN CNAME
surtur.paradigms.com.
www.paradigms.com IN CNAME
surtur.paradigms.com.
The IN specifies the class record and stands for internet. The A specifies the host's IP address. After you define a host, you can specify aliases (CNAME records) for it: ftp.paradigms.com and www.paridigms.com are aliases for sutur.paradigms.com. If you point your Web browser to http://www.paradigms.com, DNS will connect you to surtur.paradigms.com at 204.241.136.3. If your ISP's Domain Name Server doesn't contain the records for paradigms.com, it will refer you to another server until it finds the right one. Then DNS goes to that server to resolve the names. Using these records, a server answers queries about hosts.
DNS uses MX records to resolve queries about individual mail recipients. For example, the MX record for the paradigms.com domain might be
paradigms.com. IN MX
10 athena.paradigms.com.
paradigms.com. IN MX
20 mx.smtp.psi.net.
The MX record points to the host running the domain's Simple Mail Transfer Protocol (SMTP) mail service. In the example, the mailer sends mail for users at paradigms.com to the primary mail server, athena.paradigms.com. If the mailer can't find a working SMTP host on athena, it accesses a secondary mail server, mx.smtp.psi.net. If you add other mail servers, the mailer accesses them in descending order according to the number after the MX label. In the example, athena is the Exchange Server, and the PSI entry is an SMTP host on our ISP that can accept mail if athena goes down.
Reverse Lookup Files
Whereas domain files let a DNR use a host address to find a host, some
programs require the reverse--resolving IP addresses into host addresses. You
need one reverse lookup file for each network you administer. Reverse lookup
files refer to domains by reversing the IP address octets; the filenames are
usually similar. The example boot file had entries for the domain paradigms.com,
with hosts in the class C subnet 204.241.136.0. In addition, the boot file has
primary 136.241.204.in-addr.arpa
arpa-204a.rev
This entry shows that the RRs for the domain 136.241.204.in-addr.arpa are in the arpa-204a.rev configuration file:
2 IN PTR loki.paradigms.com
3 IN PTR surtur.paradigms.com
4 IN PTR homer.paradigms.com
5 IN PTR zeus.paradigms.com
6 IN PTR athena.paradigms.com
To read this file, append the domain name to the octet in the first column. The first line specifies that the IP address 204.241.136.2 refers to the host loki.paradigms.com. This information is the reverse of the configuration file paradigms.dom, which states that loki.paradigms.com is at 204.241.136.2. The arpa files give you address-to-name mappings, whereas the regular domain files give you name-to-address mappings. tracert <IP Address> to find a host name queries the reverse arpa tables; ping <host name> to test connectivity queries the regular configuration files. The sample files that come with NT include one reverse arpa file.
Cache File
The cache file resolves names outside the authoritative domain of the
current DNS. If a DNR queries your DNS and the name is not in your server's
zone, DNS refers the query to any server higher in the hierarchy cache file. The
NT sample file is usually sufficient for setting up DNS. Listing 3 shows entries
in the sample file. The cache file includes both name-to-address and
address-to-name mappings for the root servers. The file also contains the Time
to Live (TTL) for this entry. The value of 99999999 indicates a very long time.
Installation
Installing DNS is simple. If you use the NT 3.51 Resource Kit, run
install.bat, which copies the DNS executable to \system32 and configures the
Domain Name Server Registry entries. For NT 4.0, install DNS as a network
protocol. Then edit the configuration files. After you configure the files,
start the DNS service from the Control Panel Services applet or by typing NET
START DNS. Configure each desktop to use the DNS when you set the TCP/IP
protocol properties through the Network applet in the Control Panel. Use ping,
tracert, and nslookup to test the DNS, and make sure you can do name-to-address
and address-to-name resolution for hosts inside and outside your zone.
DNS, Part 2
Next month, I'll explain how DNS and Windows Internet Name Service (WINS)
work together and the DNS GUI administration tool. This tool eliminates the need
for a text editor to edit the DNS database files.
\[Editor's Note: This article is part 1 of a two-part series. Part 1 explains the basic DNS components and settings. Part 2 looks at the relationship between DNS and WINS and how to configure and administer DNS with the GUI tool.\]
| Contact Info |
| Request for Comments (RFC) 1034 and 1035 contain the DNS specifications. You can download these RFCs from http://www.ds.internic.net/rfc. |
