Developer

Using the Windows 2000 DNS service

Windows 2000 includes a full-featured DNS service, and in this Daily Drill Down, Jim Boyce shows you how to set up a DNS server in Windows 2000.


In“Understanding how DNS works, part 1,” I described what DNS is and how it works. Now that you have some background in DNS and name resolution, you’re probably itching to dive into setting up your own DNS servers. In this Daily Drill Down, I’ll show you how DNS functions in Windows 2000.

Getting started
Windows 2000 includes a full-featured DNS service. Not only does it provide the sort of DNS services you’d expect from any other operating system, but it also integrates with the Active Directory (AD) to provide some additional security and management features.

The DNS service might already be installed on your server. To check, select Programs from the Start menu. Next, select Computer Management from the Administrative Tools group. When the Computer Management console starts, expand the Services and Applications container in the console tree. Next, expand the DNS container. If the DNS container doesn’t exist, or it doesn’t contain any servers, then you must install DNS.

If DNS has not already been installed, you can add it easily enough. Just open Add/Remove Programs in Control Panel and then click Add/Remove Windows Components. Double-click Networking Services and select Domain Name System (DNS). Click Next, then follow Setup’s prompts to complete the installation. If you want to take advantage of the AD-integration features for DNS, you’ll also need to install the AD on the server if it isn’t already installed. However, you should install the AD first before installing DNS.

Like most other services in Windows 2000 Server, you manage the DNS service through a Microsoft Management Console (MMC) snap-in. The DNS console provides a graphical interface for setting up a server, managing zones, creating and modifying resource records, and other DNS management tasks. The DNS console is typical, with a tree pane on the left and a contents pane on the right. You’ll find the DNS console in the Administrative Tools folder.

You can use the DNS console to manage the local server or a remote server. The console by default displays the local server, but you can right-click in the left pane and choose Connect To Computer to connect to a different DNS server. Specify the name or IP address of the server and click OK to connect.

Managing a Windows 2000 DNS server
The first step in setting up a DNS server is to run the Configure DNS Server wizard. Open the DNS console, click on the server in the left pane, and select Configure The Server from the Action menu. Use the wizard to define the server either as a root server for your network or as a secondary server if a primary server already exists on the network. The wizard also gives you the option of creating a forward lookup zone, but you can create the zone at any time later.

Creating zones
You can host any number of zones on a given DNS server. If you install the DNS service on a domain controller and configure the server as the first DNS server on the network, Setup automatically creates a zone for the domain controller’s domain. You can begin adding records to the zone right away or create other zones as needed.

You can create one of three types of zones: AD-integrated, standard primary, or standard secondary. AD-integrated zones are stored as objects in the AD and can be created only on DNS servers that also function as domain controllers.

One advantage to AD-integration is additional security that lets you use Access Control Lists (ACLs) to control the users or groups that can manage zones. AD-integrated zones also simplify replication since the zones are replicated to other DCs in the domain. AD-integrated zones also offer options for secure dynamic updates not available for standard zones. I’ll cover dynamic updates a little later in the discussion of Dynamic DNS (DDNS).

A primary standard zone stores its data in the Zone.dns file. You can find Zone.nds in the \%Systemroot%\System32\DNS folder. Zone is the name of the zone. These zone files are text files compatible with the BIND 4 standard file format supported by other platforms, such as UNIX.

A primary zone serves as the main copy of the zone, with standard secondary zones serving as read-only copies. You can create and modify resource records in a primary zone, but not in secondary zones. Changes occur in secondary zones through zone transfers. The zone transfer copies changes from the primary zone to the secondary zone. The frequency of the zone transfer, as you’ll learn a little later, depends on the server’s configuration.

Creating a zone is easy. Just right-click the Forward Lookup branch in the DNS console and choose New Zone to start the New Zone Wizard. The wizard prompts for the following information:
  • Zone Type: Choose either Forward Lookup or Reverse Lookup, depending on the type of zone you need to create.
  • Zone Name: Specify the fully qualified zone name, such as techrepublic.com. If you’re creating a zone for a subdomain, make sure you’ve created the parent zone first. For example, prior to creating support.techrepublic.com, make sure you’ve created the techrepublic.com zone on its target server.
  • DNS Zone File: The console automatically defaults to using the zone name with a .dns extension. If you create the zone techrepublic.com, for example, the default filename is techrepublic.com.dns. You can accept the default or specify a different name, or specify an existing file to import its records.

After you create a forward lookup zone, you should make sure you have the appropriate reverse lookup zone to accommodate it, based on the IP addresses of the records you’ll create in the forward lookup zone. This ensures that when you create resource records in the forward lookup zone, the DNS console can create PTR records in the reverse lookup zone for you as needed.

You create a reverse lookup zone using much the same process as for a forward lookup zone. Right-click Reverse Lookup Zones, choose New Zone, specify the zone type, and click Next. The wizard lets you specify either the subnet of the zone or the zone name. The easiest method is to enter the subnet and let the wizard automatically convert it to the appropriate zone name in the in-addr.arpa domain. Specify the subnet in forward order, and the wizard will automatically reverse it to create the necessary reverse lookup zone.

Now you’re ready to start creating resource records. Windows 2000 automatically creates the SOA and NS records when you create a zone, and you can leave these as is or modify them. To create new records, open the DNS console, expand the Forward Lookup Zones branch, right-click the zone, and choose the type of record you want to create (or choose Other New Records to select from a complete list). The information you provide depends on the type of resource record you’re creating. If you’re not sure what the purpose of a parameter is, just click the question mark button and click on the field in the dialog box for a pop-up explanation. If you’re creating a host record, be sure to select the option Create Associated Pointer (PTR) Record if you want the PTR record created automatically. Deselect this option if you want to create the record manually (or don’t want a PTR record).

When you create a host record, you specify the hostname (www, ftp, mail, etc.) and the IP address of the host. The hostname can’t contain periods. If you need to create a dotted host, first create the subdomain, then create the host in the subdomain.

Alias or CNAME resource records map an alias name to an existing fully qualified domain name (FQDN). Assume you’re setting up the zone for techrepublic.com and the name of the server on which you’ll host the Web site is server3. The zone should have a host record for server3 that points to the appropriate IP address, as well as a CNAME for www that points to the same IP address (or possibly a different address if the server has multiple IP addresses bound to it). When you create a CNAME, you specify the alias and the FQDN of the host being aliased. The host name can’t contain periods, but the FQDN will because it specifies the fully qualified path to the host, complete with domain and subdomain if applicable.

If you’re creating a mail exchange (MX) record—which enables e-mail to be routed through or to a domain—you specify the single-part name for the mail host in the Host Or Domain field. You can leave this field blank if the mail exchanger name is the same as the parent domain name. Specify the FQDN of the server that will function as the mail exchanger in the Mail Server field. The FQDN you specify must resolve to an existing host record in the domain, so make sure you create the A record for the mail exchanger as well as the MX record. Finally, specify the preference number for the mail exchanger in the Mail Server Priority field. The higher the number, the lower the priority.

Another common type of record you might need to create is the Service Location Record, or SRV. These records are particularly useful in domains where multiple servers offer specific services, such as multiple HTTP servers in a single domain. You can use the SRV records to move a service from one host to another with minimal reconfiguration, and also to designate certain servers as primary for a service and others as secondary. For SRV records to be useful, the client resolver must support the use of SRV records. The DNS server responds to the request with a list of all servers in the domain that offer the requested service, and the client uses that list to determine which server to use.

To create an SRV record, right-click the zone and choose Other New Records. Select Service Location from the list and click Create Record. In the New Resource Record dialog box, specify the following information:
  • Service: Select one of the predefined service types from the Service drop-down list.
  • Protocol: Select either tcp or udp, depending on the requirements of the service.
  • Priority: This value, an integer between 0 and 65535, specifies the preference order of the service in much the same way the preference number for an MX record specifies the priority of the mail exchanger. The lower the number, the higher the priority. The client attempts to connect to the server with the highest priority first. If that fails, the client attempts to connect to servers with decreasing priority. You can specify the same priority for multiple records.
  • Weight: This integer value between 0 and 65535 allocates a weight to the server to provide for load balancing. The weight parameter acts as a secondary priority indicator when multiple servers have the same priority number. Hosts with a higher weight (lower integer value) are returned to the resolver first. You can assign a weight of 0 to turn off weighting if load balancing isn’t a consideration, which also has the side effect of increasing performance for SRV queries.
  • Port Number: Specify the integer value of the tcp or udp port used by the service.
  • Host Offering This Service: Specify the FQDN of the server offering the service. This FQDN must resolve to an existing host record in the server’s domain.

Setting zone properties and behavior
A zone’s properties determine how it functions in several respects, such as how often zone transfers take place, how resource records age, and so on. After creating a zone and its resource records, you should take the time to review and modify the zone’s properties if needed. Open the DNS console, right-click the zone, and choose Properties. The zone’s General tab lets you configure the following properties:
  • Status: Shows the current status of the zone. Click Pause to pause a running zone or click Start to start a paused zone. Use Pause when you need to take a zone offline while making extensive changes to it.
  • Type: Indicates the current zone type. Click Change to change it to any of the supported types (AD-integrated, standard primary, or standard secondary).
  • Zone File Name: Specifies the zone file in which the zone is stored, or indicates Active Directory for AD-integrated zones.
  • Allow Dynamic Updates: Allow or deny dynamic updates of host and PTR records in the zone by clients and DHCP servers on behalf of their clients. You can allow unsecured updates, allow only secured updates, or deny updates. You’ll learn more about Dynamic DNS later.
  • Aging: Specifies record aging and scavenging properties for the zone. You’ll learn more about scavenging later.

You use the Start of Authority (SOA) tab to configure the zone’s SOA record. You’ll find the following properties:
  • Serial Number: This value specifies the zone’s version number. The DNS service increments this number by 1 each time a zone transfer occurs. Other servers use this value to determine when a zone transfer is required. You generally don’t need to modify this value but can increment the value to force a zone transfer if needed.
  • Primary Server: This is the hostname of the primary master for the selected zone. You can change the server manually or click Browse to browse the network for the server. If you specify the name manually, be sure to include a trailing period.
  • Responsible Person: You use this property to define the e-mail address of the person responsible for managing the zone. Enter the name as an FQDN, replacing the @ sign with a period. For administrator@techrepublic.com, for example, you enter administrator.techrepublic.com.
  • Refresh Interval: This value specifies how often servers that host secondary copies of the zone should check the currency of their zone data against the primary zone data. The default is 15 minutes.
  • Retry Interval: This value specifies the amount of time that must elapse before a server hosting a secondary copy of the zone retries a connection to the primary zone if a previous connection attempt failed. This value should usually be less than the Refresh interval and defaults to 10 minutes.
  • Expires After: Specifies the period of time a server hosting a secondary copy of the zone can wait before discarding its secondary data if its zone data hasn’t been refreshed. This prevents the secondary servers from serving potentially stale data to client requests. The default is 24 hours.
  • Minimum (Default) TTL: This value specifies the amount of time that querying servers can cache results returned from this zone. When this period expires, the remote server removes the record from its cache. The default is 1 hour.
  • TTL For This Record: This value specifies the time-to-live for the SOA record itself. The default is 1 hour.

Use the Name Servers tab to add or modify name servers for the zone. Although you could simply add or modify records manually, using the Name Servers page lets you view all the name servers in a single list. If you modify the hostname of a name server record, be sure to include a trailing period.

The WINS tab defines whether or not the DNS service attempts to resolve names through WINS that it can’t resolve on its own. The settings on the WINS tab include the following:
  • Use WINS Forward Lookup: Allows the DNS service to query WINS for forward lookup names it can’t resolve on its own through DNS.
  • Do Not Replicate This Record: Prevents the DNS server from replicating WINS-specific data to other DNS servers during zone transfers. Select this option if you’re performing zone transfers to servers that don’t support WINS.
  • IP Address: Specifies the IP addresses of WINS servers to query.
  • Time-To-Live: Specifies the TTL value for this record.
  • Advanced: Sets the cache timeout, which defines the period of time other servers can cache results returned through a WINS lookup. Also use this option to set the lookup timeout property, which determines how long the server waits for a response from the WINS server before generating a Name Not Found error.

The Zone Transfers tab controls zone transfers from the server. You can allow transfers to all servers or restrict to those servers listed on the Name Servers tab or to a user-defined list of servers. You can also click Notify to configure the server to automatically notify other servers when zone data has changed so they can initiate a zone transfer.

The Security tab is included on the properties sheet for an AD-integrated zone. You can use the Security tab options to configure permissions on the zone, allowing or denying various permission levels to users and groups to control the types of changes, if any, those users can make in the zone.

Configuring subdomains and delegation
In a small network, you probably won’t have to worry about subdomains or delegation. If yours is a large network or you manage domains for others, however, subdomains and delegation are probably of some interest to you. Many larger organizations break up the organization’s name space into subdomains for administrative or even geographical reasons.

A subdomain is nothing more than a child domain of another domain. For example, support.techrepublic.com is a subdomain of techrepublic.com, and techrepublic.com is its parent domain. Subdomains provide for decentralized management of the DNS name space when the subdomains are hosted on another server, but you can also use subdomains on the same server as the parent domain. In this situation, the subdomains still enable decentralized administration of sorts, enabling the administrator to assign permissions to each subdomain separately from the parent domain.

To create a subdomain, you must first create the parent domain. If you’re going to be hosting the subdomains on the same server as the parent domain, you simply create the parent domain, then create the subdomains. If you’re delegating one or more subdomains, you create the parent domain on the primary server and then create the subdomains on the other servers as required.

If you’re creating the subdomains on the same server as the parent domain, open the DNS console and expand the parent zone. Right-click the zone and choose New Domain. Specify the first-part domain name, such as support. DNS creates the subdomain within the parent branch. As when working with any other zone, make sure you have the necessary reverse lookup zone in place to handle the subdomain’s records. Then, start populating the subdomain with resource records as required by the domain.

If you’re delegating a subdomain to another server, the process is a little different. First, on the subdomain’s server, open the DNS console and create the subdomain’s zone. You don’t create a parent domain first, just create the subdomain. On the DNS server hosting the parent domain, open the DNS console, then open the parent zone. Right-click the zone and choose New Delegation. Click Next when the New Delegation Wizard starts, then specify the delegated domain’s first-part name. If delegating support.techrepublic.com, for example, you’d enter support as the domain name. The wizard automatically appends the parent domain to assemble the FQDN. Click Next.

At this point, click Add in the Name Servers window to add the FQDN and IP addresses of the name servers to which the subdomain is delegated. These are the servers on which the subdomain’s records are hosted. Finally, click Next, then click Finish.

You’ll find that a delegated subdomain’s icon is different from a local subdomain’s icon in the DNS console. You’ll also find that you can create resource records in the local subdomain but not in the delegated subdomain. You need to create resource records for a delegated subdomain on the server where the subdomain’s zone is hosted. You can do so remotely, however, by connecting the DNS console to the remote server.

Conclusion
If you want to use AD on your network, you’ll have to get used to Microsoft’s DNS server. Fortunately, Microsoft has eased the administration of DNS within the Microsoft Management Console. In this Daily Drill Down, I showed you how to set up a DNS server in Windows 2000.

Jim Boyce is a former contributing editor and monthly columnist for WINDOWS Magazine. Jim has authored and coauthored over 40 books about computer software and hardware. He has been involved with computers since the late 1970s as a programmer and systems manager in a variety of capacities. He has a wide range of experience in the MS-DOS, Windows, Windows NT, Windows 2000, and UNIX environments. In addition to a full-time writing career, Jim is a founding partner and vice president of Minnesota Webworks, a Midwest-based Web development firm

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox