Windows IT Pro is the authoritative and independent resource for windows nt, windows 2000, windows 2003, windows xp. Features a collection of resources and magazines for windows IT professionals.
  
  
  Advanced Search 


August 1996

Configuring and Administering DNS


RSS
Subscribe to Windows IT Pro | See More Domain Name System (DNS) Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!

Microsoft borrows a page from the Unix playbook

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 (spyros@paradigms.com, frank@microsoft.com) 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 spyros@paradigms.com, 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.

   Previous  [1]  2  Next 


Reader Comments
Just Learning about DNS for WIN NT. Found your info direct and useful

Sheldon Quinton April 20, 2004


You must log on before posting a comment.

If you don't have a username & password, please register now.




Top Viewed ArticlesView all articles
Command Prompt Tricks

One reader shares his tip for setting up the command prompt to reflect a remote path. ...

Microsoft Touts Xbox 360 'Black Friday' Success

Microsoft this week revealed that its Xbox 360 video game console outsold its Sony PlayStation 3 rival 3-to-1 on "Black Friday," which curiously describes the three day weekend after Thanksgiving, a period that unofficially kicks off the holiday selling ...

How can I stop and start services from the command line?

...


Related Articles Integrating and Administering DNS

Security Whitepapers The Impact of Messaging and Web Threats

Why SaaS is the Right Solution for Log Management

Protecting (You and) Your Data with Exchange Server 2007

Related Events How IE7 & The New Extended Validation SSL Certificates Impact Your Site

Tracking Changes in the Modern Windows-centric Regulatory Environment

Top 10 Email Security Challenges and Solutions

Check out our list of Free Email Newsletters!

Security eBooks Spam Fighting and Email Security for the 21st Century

Understanding and Leveraging Code Signing Technologies

A Guide to Windows Certification and Public Keys

Related Security Resources Become a VIP member of the Windows IT Pro community!
Get it all with the VIP CD and VIP access. A $500+ value for only $279!

Subscribe to Windows IT Pro!
Solve your toughest technical problems with our experts and access 10,000 + articles online. 30% off

Monthly Online Pass - Only $5.95!
Get instant access to 10,000+ articles from Windows IT Pro Magazine!

TechNet Virtual Labs
Evaluate and test Microsoft's newest products.


Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro Windows Dev Pro IT Job Hound ITTV
IT Library Technology Resource Directory Connected Home Windows Excavator Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 Copyright © 2008 Penton Media, Inc., All rights reserved. Terms and Use | Privacy Statement | Reprints and Licensing