Creating a DNS Server, Part 1
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
As you may have heard, Microsoft Windows 2000 will depend heavily on the Domain Name System (DNS) service. With the currently scheduled Microsoft Windows 2000 release date just around the corner, it makes sense to ensure that you have a DNS server and that it's set up correctly. In this article, we'll explain why you should be running DNS. We'll begin by exploring the various components and functions of a DNS server. In part 2 of this article, we'll show you how to plan and implement a DNS server in your organization.
On This Page
What is DNS?
If you have a small network that's never been tied to the Internet, chances are good that you've never needed a service such as DNS. Normally, on small networks, computers running Microsoft Windows NT have no trouble communicating with each other across the network. Such communications may include browsing and resource sharing. The reason that you can perform such tasks without the aide of external services is that Microsoft Windows NT is designed to allow protocol-independent communications via UNCs (Universal Naming Conventions). This means that no matter which protocol two machines have in common, Microsoft Windows NT can mediate communications between the two machines by passing information in the UNC format. The UNC format includes computer names and resource names. For example, you've probably seen network drives mapped with a command like NET USE \\COMPUTER\RESOURCE. The \\COMPUTER\RESOURCE part of this command is in the UNC format.
UNCs work great as long as everyone on the network is running on a Microsoft Windows platform and the network is small enough that routing isn't required. However, in the real world, this isn't the case.
For example, the Internet is a giant network made up of every type of computer imaginable. Since only a fraction of Web servers are running Microsoft Windows NT, the use of Universal Naming Conventions for Internet surfing is impractical.
As you probably know, each Web site has a corresponding IP address. For a computer on your network to connect to a Web server, which could be anywhere in the world, you must know or be able to determine the server's IP address. Only when the IP address is known can your computer begin the complex routing process of connecting to a Web server halfway around the world.
This is where DNS comes in. DNS is a service that rides on top of Microsoft Windows NT and resolves domain names to IP addresses. For example, if you enter www.techrepublic.com in your Web browser, your browser passes the domain name (techrepublic.com) to the DNS server. The DNS server performs several operations, which we'll explain later, and returns the IP address to your Web browser. Once the Web browser knows the IP address that's registered to the page, it can begin the process of connecting to the Web page.
Why Does Microsoft Windows 2000 Depend On DNS?
Microsoft Windows 2000 is more heavily dependent on DNS than Microsoft Windows NT 4.0. As we mentioned earlier, Microsoft Windows NT has no trouble communicating with other Microsoft Windows-based computers as long as it doesn't have to perform any routing. The NetBEUI protocol that is usually used for small workgroups isn't routable. If you're performing routing, you must use a routable protocol such as TCP/IP. As you may know, Microsoft Windows NT attempts to send computer names across TCP/IP. However, if there is a router between two PCs, Microsoft Windows NT relies on a WINS server to pass the computer name and other NetBIOS information between the two computers.
Microsoft Windows 2000 does away with the WINS service. Instead, it incorporates WINS functionality into a service called Dynamic DNS. This means that even if your network isn't connected to the outside world, you may still have to run the DNS service, just to be able to browse and share resources among computers with routers between them.
The DNS Hierarchy
Originally, all domain name resolution occurred on one computer, which contained a text file called HOSTS.TXT. However, as time went on, the HOSTS.TXT file required update after update. The computer containing this file was also being overrun with name resolution requests.
In response to this situation, DNS was designed in a way that would keep all the domain information from being stored on a single computer. Instead, DNS servers follow a specific hierarchy. At the top of the hierarchy is the root-level DNS. The root-level DNS contains information about all the top-level domains. Top-level domains are the common domain names such as COM, EDU, ORG, and GOV. Below the top-level domains are second-level domains. For example, TECHREPUBLIC is a second-level domain to the COM domain, thus making the TECHREPUBLIC.COM domain name possible.
Second-level domains may also include sub-domains. For example, support.microsoft.com is a sub-domain of the microsoft.com domain.
A DNS server can play several roles. It may cache information that it obtains from the Internet, or it may actively participate in the domain structure. For example, if your organization has a registered domain name, it's probably a second-level domain name. This means that your DNS server would include a list of any sub-domains that you own and a link to the top-level domain that you're linked to. The portion of the domain structure that an individual DNS is responsible for is called the DNS's zone of authority.
You can also have a secondary DNS server. This secondary DNS server can copy domain information across the network from the primary DNS server that has authority over at least one zone. Such an action is called a zone transfer.
Types of DNS Queries
Before you can effectively set up a DNS server, you must truly understand the tasks that the server must perform. A DNS server is capable of performing four different types of tasks.
The simplest type of DNS query is the recursive query. In a recursive query, the server either returns the information that the client is asking for or returns an error message stating that the information doesn't exist. The DNS server doesn't attempt to contact another server to obtain the information.
In an iterative query, the DNS server either resolves the requested name to an IP address or refers the client to another DNS server that may be able to. For example, suppose a client needs to resolve www.techrepublic.com. The DNS will check its zones first. If it doesn't find the requested domain, the DNS will send the request to a root-level domain. The root-level domain will reply to the request with the address of the .COM name server. The local DNS will then send a query for www.techrepublic.com to the .COM name server. The .COM name server will then respond to the DNS with the address of the DNS servicing www.techrepublic.com. Finally, the DNS will contact the DNS responsible for maintaining the techrepublic.com domain. That DNS will pass the IP address of www.techrepublic.com to the local DNS, which in turn passes the address on to the client that requested it.
An inverse query is a query in which a client tries to determine the host name associated with a known IP address. There is no direct searchable way of performing a reverse lookup. Therefore, a special domain called in-addr.arpa was created to handle this task. The in-addr.arpa domain contains nodes named after IP addresses.
As you saw with the iterative query, a DNS may have to perform several queries to obtain a single piece of information. Once that information is obtained, it's stored in a cache so that the DNS doesn't have to look it up again the next time the information is asked for.
Each item in the cache is assigned a TTL (Time To Live) value. This value is set by the Administrator and controls how long a resolved name will remain in the cache. Shorter TTL periods result in more frequent DNS updates, resulting in greater accuracy. Unfortunately, short TTL periods place additional strain on your DNS since it has to search the Internet for name resolutions more frequently.
DNS Configuration Files
A typical DNS server uses four basic types of files: a database, reverse lookup, cache, and boot file. Each of these files stores information related to performing specific DNS tasks. In the sections that follow, we'll describe each file type.
By default, Microsoft Windows NT comes with a file called PLACE.DNS. This file is a template that you can use to build your database file. Microsoft recommends copying this file to another file with a name that matches your domain. For example, we would copy PLACE.DNS to TECHREPUBLIC.COM.DNS.
The database file always begins with a start of authority record, which is responsible for defining the general parameters of the DNS zone.
The database file may also contain name server records. Name server records list additional DNS servers.
Another optional component of a database file is host records. A host record is used to make a static association between a host name and an IP address.
The final component of a database file is a CNAME record. A CNAME record allows you to assign more than one host name to a single IP address. This allows you to use multiple aliases to a single domain.
Reverse Lookup File
The reverse lookup file uses a structure similar to the database file. The main difference is that it deals strictly with the in-addr.arpa zone. Within the reverse lookup file, IP addresses are linked to the in-addr.arpa zone in reverse order. For example, to provide reverse lookups for the network 188.8.131.52, a reverse lookup file is created with a filename of 100.147.in-addr.arpa. This file contains a start of authority record like database files, but it also contains pointer records that make the reverse lookups possible.
The cache file CACHE.DNS contains all the resolutions the name server has performed where the TTLs haven't expired. By default, the CACHE.DNS file also contains records for all the root name servers on the Internet.
The boot file is only used if you plan to make changes to the DNS through the editing of text files and not through the DNS Manager. In such cases, the boot file controls the startup behavior of the DNS.
In this article, we've provided you with information regarding the way that a DNS server functions. In part 2, we'll show you how to plan and implement a DNS server in your organization.
Brien M. Posey is an MCSE and a freelance technical writer. He also works as a network engineer for the Department of Defense. You can contact him via e-mail at Brien_Posey@xpressions.com . (Because of the large volume of e-mail that he receives, it's impossible for him to respond to every message. However, he does read them all.)
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.