NDS and DNS: Configuring DNS Services in NetWare 5
Articles and Tips:
01 Feb 1999
As a NetWare administrator, you may wonder why TCP/IP needs Domain Naming System (DNS), which makes it possible to call computers by name instead of by their numbers. After all, IPX does not require a labor-intensive naming service. On an IPX network, you simply configure a server, and names just happen.
Unfortunately, the protocols that make IPX networks so easy to manage, Service Advertising Protocol (SAP) and Routing Information Protocol (RIP), were designed with LANs in mind. Confined to a LAN, the chatty natures of SAP and RIP don't have a major impact on performance. If you use SAP and RIP on a limited-bandwidth WAN, however, you begin to begrudge the existence of every unnecessary packet.
TCP/IP, on the other hand, was designed with large WANs in mind. Chatty protocols were out of the question. As a result, DNS is highly scalable and efficient. Unfortunately, DNS is not especially easy to manage. (You may also have heard of Service Location Protocol, or SLP, which is new to NetWare 5. SLP provides a low-bandwidth, automated naming service for TCP/IP networks. SLP is a new protocol, however, and is far from supplanting DNS for the majority of TCP/IP services.)
NetWare 5 includes DNS and Dynamic Host Configuration Protocol (DHCP) services that integrate neatly with the NetWare environment. These services store their data in Novell Directory Services (NDS). NDS integration gives the DNS and DHCP services some unique advantages.
Because DNS and DHCP are not self-configuring, you must set up these services from the ground up. Although the configuration procedures aren't particularly difficult, they do require that you thoroughly understand the services. This article is the first in a series of articles that explains how to set up and manage the DNS and DHCP services in NetWare 5. This article focuses on DNS: It explains DNS basics and then describes how to set up DNS on a NetWare 5 server. (In this article, I assume you are familiar with IP addressing. If you need information about IP addressing, see "Choosing IP Addresses for Your Network," NetWare Connection, Feb. 1997, pp. 20-26. You can download this article from http://www.nwconnection.com/feb.97/ipadd27.)
WHY DOES TCP/IP NEED DNS?
As you know, networks don't use computer names to deliver data. When a packet is sent to a particular destination, the destination is identified by numbers. Every computer is identified by a combination of a network number and a computer number that must be unique throughout the network. The following example shows how addresses and server names are associated on an IPX network.
Suppose a computer named FOO wants to send a message to a computer named PHU. Does FOO stuff the name PHU in a packet and send it? No, using the name won't work. FOO has to learn the network number and the computer number of PHU. On an IPX network, FOO issues SAP or NDS queries to obtain this information. (FOO may also need to send a RIP query to learn the address of a router that can reach PHU.) Once FOO has the required addresses and routing information, FOO can stuff a packet with the addresses and send it to PHU. The process of using a computer's name to learn its numeric addresses is called name resolution.
A similar process occurs on TCP/IP networks, but TCP/IP networks provide a special service specifically to support name resolution. Computers that need to determine the IP address of a host send a name resolution request to DNS. (Network devices on a TCP/IP network are typically called hosts.)
THE ARCHITECTURE OF DNS
DNS was designed to handle computer names on the Internet. The Internet's DNS database, referred to as the DNS name space, is probably the largest, most widely accessed database in the world. Thousands of new domain names are registered daily, and millions of DNS queries originate hourly from every point on the planet.
For all of that size and activity, DNS must be easy to use, responsive, robust, and manageable. The design of DNS reflects these demanding requirements. To illustrate how DNS works, the following sections describe some characteristics of DNS.
The DNS Name Space Structure
The DNS name space is hierarchical. You should be familiar with at least two computer-based hierarchies: computer file systems and NDS. Hierarchies are highly structured, making it easy to place data into categories. Hierarchies are also easy to extend, so there is maximum capacity to the DNS name space. (Hierarchies are often referred to as trees, reflecting their branch-like structures.)
The categories of the DNS hierarchy are called domains. Domains correspond to directories in file systems or to container objects in NDS. Figure 2 shows part of the Internet's domain hierarchy. As you can see, domains can contain other domains, just as directories can contain subdirectories.
Figure 2: The Internet's DNS name space is hierarchical.
You can refer to domains that contain other domains in several ways: You can call them domains and subdomains, or you can call them parent domains and child domains. There are no limits to the number of child domains that can be spawned by a parent domain. DNS is, at least in theory, infinitely extensible.
DNS domains are organized in levels. At the top of the DNS hierarchy is a single root domain, just as NDS has a single [Root] object. Below the root domain are top-level, or first-level, domains. For example, the Internet contains first-level domains such as COM, NET, EDU, ORG, MIL, and GOV. The Internet also contains first-level domain names for countries, each of which has a two-letter name such as US for United States and IT for Italy.
As you might expect, child domains of first-level domains are called second-level domains. For example, pseudo-corp.com is a second-level domain. Not surprisingly, child domains of second-level domains are called third-level domains--foo.pseudo-corp.com, for example. The list can go on, almost without limit although most DNS server implementations impose a maximum number of levels to the DNS hierarchy. Still, the maximum number of levels is very high, and you would almost never want to create DNS trees with as many levels as a DNS server can support.
A domain can also contain resource records, which store the actual DNS data. Resource records correspond to files in directories or to leaf objects in NDS. Resource records describe domain characteristics, the names of computers in the domain, or other domain-related data.
The most common resource record is the Address record, which maps a computer's DNS name to its IP address. For example, suppose you create an Address resource record in the pseudo-corp.com domain and this record specifies that the IP address of a computer named www is 192.168.35.80. When a user requests a connection to www.pseudo-corp.com, the user's browser queries DNS for the IP address of the requested computer. DNS locates the Address resource record and informs the user's browser that the IP address of www.pseudo-corp.com is 192.168.35.80, enabling the browser to establish a connection.
In NDS, an object's complete, or distinguished, name consists of the object name joined in order with the names of all the container objects between the object and the [Root] object. For example, an NDS object may have the distinguished name of .CN=CHARLY.OU=SALES.OU=CHICAGO.O=PSEUDOCORP, which can be expressed without the container designations as .CHARLY.SALES.CHICAGO.PSEUDOCORP.
Similarly, a computer's complete DNS name is the computer name (also called host name) joined in order with the names of all the domains between the computer's Address resource record and the root domain. For example, the host foo in the domain pseudo-corp.com has the complete DNS name of foo.pseudo-corp.com. This complete DNS name is the host's fully qualified domain name (often referred to as its FQDN).
Host names and domain names can consist of letters, hyphens, and the digits 0 to 9 and are not case sensitive. The period is restricted for use as the separator character. Other than the hyphen and period, you cannot use punctuation marks.
Delegation of Authority
Imagine what would happen if the designers of DNS had tried to store the entire Internet name space on one computer. How could one computer store all of that data and respond to the millions of name queries that are generated each hour by Internet users? Moreover, what sort of bureaucracy would be required if all host names on the Internet had to be tracked and updated at one central location? The designers of DNS knew that a decentralized, highly scalable architecture was required if DNS was to keep up with future growth.
DNS is scalable and manageable because it incorporates a distributed database. Parts of the Internet's DNS name space are stored on thousands of DNS servers located throughout the world. In theory, each domain can be serviced by its own DNS server. No matter how many DNS servers exist, however, DNS easily navigates these servers to resolve name queries quickly and efficiently.
A DNS server is responsible for the names in one or more zones. (A zone consists of one or more domains.) A DNS server is said to have authority for a zone or to be authoritative for a zone. Through a system of DNS server resource records, the numerous DNS servers coordinate their efforts to provide name services for the Internet's DNS name space.
The large number of DNS servers solves two problems of scale: First, name queries are distributed. Instead of relying on one supercomputer, the Internet relies on many, more modest computers, often no more than simple microcomputers that are authoritative for the subdomains and resource records of individual companies.
Second, DNS data are distributed across many DNS servers. As a result, management is distributed as well. For example, suppose you are the network administrator of Pseudo Corp, and you have registered the domain pseudo-corp.com. Also suppose that you operate a DNS server that is authoritative for pseudo-corp.com and stores the resource records in pseudo-corp.com.
If you need to update resource records, you make the changes at a local computer, just as thousands of DNS administrators may be doing at any given time. You do not have to submit a request to a central DNS administrator, who may schedule the request for service in a few days. Because DNS management is distributed, management even of the Internet is scalable.
If the Internet name space is distributed over thousands of DNS servers, each of which understands only a piece of the overall picture, how do all of the pieces fit back together? Upper-level DNS servers delegate authority to lower-level DNS servers. Examining a DNS query illustrates how this delegation of authority works.
Suppose that user Buster on computer buster.malaprop.com needs to access www.pseudo-corp.com. (See Figure 3.) To make a connection, Buster's browser needs to know the IP address of www.pseudo-corp.com, so the browser issues a DNS query. Because Buster's computer is configured to use dns1.malaprop.com, a local DNS server, Buster's browser directs a name query to dns1.malaprop.com.
Figure 3: If a DNS server cannot resolve a name query, this server sends the query to another DNS server that may be able to provide a response.
In response to the query, dns1.malaprop.com must do one of two things: It must respond with the IP address of www.pseudo-corp.com, or it must return an error message stating that the host cannot be found. (DNS servers maintain a cache of recently resolved names. If dns1.malaprop.com has the IP address for www.pseudo-corp.com in cache, dns1.malaprop.com can respond to Buster's query immediately without querying other DNS servers.)
Suppose dns1.malaprop.com doesn't know the IP address of www.pseudo-corp.com and doesn't know how to contact a DNS server that is authoritative for pseudo-corp.com. Since dns1.malaprop.com cannot resolve the name, it must initiate a search for the name, starting from the root domain. Every DNS server knows the IP addresses of DNS servers that are authoritative for the root domain, so dns1.malaprop.com sends a query to one of these servers.
Unfortunately, the root DNS server isn't authoritative for pseudo-corp.com. However, the root DNS server can return the IP address of a DNS server that is authoritative for the first-level domain COM.
Next, dns1.malaprop.com contacts the DNS server that is authoritative for COM. Although this DNS server cannot respond to the name query, it knows the IP address of a DNS server that is authoritative for the second-level domain pseudo-corp.com and sends this IP address to dns1.malaprop.com. Finally, dns1.malaprop.com contacts a DNS server that can respond to the query.
The original query from Buster's browser was directed through four DNS servers before dns1.malaprop.com found a DNS server that could provide the correct IP address. Each DNS server knew only a piece of the overall name space, but all of the servers worked together to resolve the query one step at a time.
Forward and Reverse Naming
The DNS tree shown in Figure 1 is called a forward-naming tree. DNS servers use forward-naming trees to determine the IP address associated with a host name.
DNS also supports reverse-naming trees. DNS servers use reverse-naming trees to determine the host name associated with an IP address. Because some TCP/IP services depend on reverse naming, you should configure DNS servers to support both forward and reverse naming.
Figure 4 shows the part of the Internet's DNS name space that is used for reverse naming. The first- and second-level domains are named ARPA and IN-ADDR respectively. (Because of these domain names, the reverse-naming database is often referred to as the IN-ADDR.ARPA name space.) Below these domains, each domain is associated with an octet of the host IP addresses.
Figure 4: The IN-ADDR.ARPA name space enables DNS to search for Pointer resource records that map an IP address to a particular host's fully qualified domain name.
The following example shows how DNS conducts a reverse-naming lookup to identify the host name associated with the IP address 192.168.80.53.
The search really starts at the third level below the root domain, which contains 256 domains, one for each of the 256 values that are available for the first octet of an IP address. In this example, the DNS query locates domain 192, which corresponds to the first octet of IP address 192.168.80.53.
The search then proceeds to the fourth level, which also contains 256 domains. The DNS query locates domain 168, which corresponds to the second octet of IP address 192.168.80.53.
The search continues at the fifth level, which also contains 256 domains. The DNS query locates domain 80, which corresponds to the third octet of IP address 192.168.80.53. In domain 80, the DNS query finds a Pointer resource record that maps address 53 (the last octet of IP address 192.168.80.53) to host name drew.pseudo-corp.com.
As you can see, the DNS query uses reverse-naming to search down the IN-ADDR.ARPA name space for each successive octet in the requested IP address. With a Class C address (such as 192.168.80.53), the DNS query must search to the fifth level of the IN-ADDR.ARPA name space. A Class B address can be resolved at the fourth level, and a Class A address can be resolved at the third level.
REGISTERING A PRIVATE DNS SERVICE WITH THE INTERNET
To establish a presence on the Internet, your company needs to obtain a block of IP addresses and a domain name. Under current Internet policies, most companies obtain a block of IP addresses from their Internet service provider (ISP). Only large companies obtain IP addresses directly from the Internet address authority. (For more information about the Internet address authority, visit http://www.iana.org/ip-addresses.html.)
You must register your company's domain names through a central authority, thereby establishing the domain name in the Internet name hierarchy. After your domain is registered, the appropriate first-level DNS servers will be aware of the IP addresses for your company's DNS servers. These first-level DNS servers can then refer queries for your company's domain to your company's DNS servers.
If you want to register a domain name under the first-level domains COM, NET, ORG, and GOV, you use the InterNIC Registration Services, which are currently provided by Network Solutions Inc. You can find forms for registering and modifying domains names at http://www.internic.net.
If you want to register a domain name under another first-level domain, such as EDU or MIL, you must contact the appropriate central registration authority. To find the authorities for other first-level domains, visit http://www.iana.org, which is operated by the Internet Assigned Numbers Authority (IANA).
Because approximately 20,000 Internet domain names are registered each day, you may have to do a lot of research to identify a domain name that isn't in use. The primary research tool is WHOIS, which is available at http://www.internic.net.
After you identify the domain name that you would like to use, you should identify the IP addresses of at least two DNS servers that will have authority for this domain. When you apply for the domain name, you must supply the IP addresses of these DNS servers.
The DNS servers can be hosted by an ISP, or they can be located on your company's network. If an ISP hosts your company's domain, you must submit name changes to the ISP and wait for the ISP to process the request. ISPs typically update their domain databases overnight, so you may have to wait 24 hours before a change shows up in the online DNS database.
If your company operates its own DNS servers, name changes can be implemented more expeditiously. If you use the DNS services included in NetWare 5, name changes can be posted almost immediately.
You will receive an additional benefit if you use the NetWare 5 DHCP service to assign IP addresses to computers on your company's network. As the DHCP service updates IP address assignments, it can notify the DNS service of these changes so that new address resources records can be posted immediately in the DNS name space. This capability, called Dynamic DNS (DDNS), is available only if you use the DNS and DHCP services in NetWare 5.
Primary and Secondary DNS Servers
As mentioned earlier, when you register a domain, you must provide the IP addresses of at least two DNS servers. As far as the Internet is concerned, additional DNS servers provide fault tolerance. If the primary DNS server fails, secondary DNS servers can resolve names for the zone. Secondary servers can also offload some of the processing for their zone. Users can resolve a host name by sending a DNS query to any of the DNS servers that are authoritative for the requested host's domain.
With most DNS implementations (such as the Berkeley Internet Name Domain or BIND), you configure one primary DNS server and one or more secondary DNS servers for each zone. (BIND is the most popular type of DNS server on the Internet.) The primary DNS server stores the master copy of the zone database. If you need to make changes to the zone, you must make these changes on the primary DNS server.
Each secondary DNS server periodically performs a zone transfer: It copies the zone database from the primary DNS server or from another secondary server. The source DNS server for the zone transfer is called the DNS master server.
A TCP/IP client should be configured with the IP addresses of at least two DNS servers, enabling the client to find another DNS server if the first DNS server is unavailable. Secondary DNS servers retain a copy of the zone database both in memory and in a local database file. Secondary DNS servers can use their local database file if they need to restart while the primary DNS server is unavailable. If the primary DNS server is unavailable, however, no changes can be made to the zone database.
DNS AND NDS
Novell has added a twist to the traditional DNS architecture. In NetWare 5, DNS database entries are stored as NDS objects. As you know, NDS is a distributed database, making these database entries available to every server on the network. Because DNS database entries are stored in NDS, you do not have to set up a primary DNS server that stores the master copy of the zone database.
With the DNS service in NetWare 5 , all DNS servers act as primary DNS servers. To change the DNS database, you make changes to NDS objects, and these changes are immediately available to all DNS servers that are authoritative for a given zone.
There is one exception to this configuration, however. You may need to configure the NetWare 5 DNS servers to coexist in an environment that includes other types of DNS servers, such as BIND. If a BIND DNS server is the primary DNS server for a zone and you want NetWare 5 DNS servers to be authoritative for this zone, you must configure one NetWare 5 DNS server as a secondary DNS server for the zone. (See Figure 5.)
Figure 5: You can configure a NetWare 5 DNS server as a secondary server if the zone's primary server is not a NetWare 5 server.
The secondary NetWare 5 DNS server initiates zone transfers to obtain the zone data from the BIND DNS server. The NetWare 5 DNS server then populates NDS with the appropriate objects. If you have other NetWare 5 DNS servers in the same zone, they obtain the zone data from NDS.
NDS Objects for the DNS Service
Although DNS data are stored as NDS objects, you do not use Novell's NetWare Administrator (NWADMIN) utility to manage these objects. Instead you use the new DNS/DHCP Management Console (which is, incidentally, a Java-based console). As you manipulate DNS and DHCP objects in the DNS/DHCP Management Console, the console creates, modifies, and deletes the NDS objects as required.
DNS data are stored in the following objects, which the NetWare 5 DNS service adds to the NDS schema:
DNS Server Object. You create a DNS Server object for each DNS server. A DNS server can be authoritative for one or more zones.
Zone Object. You create a Zone object for each zone. A zone can contain one or more Resource Record Set objects that define the hosts in that zone.
Resource Record Set Object. The DNS/DHCP Management console creates Resource Record Set (RRSet) objects as required to store the resource records you define. All resource records for a host are associated with the host's RRSet object.
Resource records are not stored as distinct NDS objects. Instead, resource records are stored as attributes of RRSet objects. Because resource records are not NDS objects, you can view them only in the DNS/DHCP Management Console.
Zone objects are container objects, and RRSet objects are always stored in Zone objects. However, DNS Server objects are leaf objects. The relationships between Zone objects and DNS Server objects are stored in the attributes of the Zone objects themselves, not in the NDS tree structure.
Extending the NDS Schema
Before you can do any work with the DNS or DHCP services, you must install these services on the NetWare 5 server and extend the NDS schema. The DNS and DHCP software components are automatically installed when you install NetWare 5. (This explains why the Novell DNS/DHCP services option shows a size of 0 MB in the INSTALL utility's Additional Products and Services screen.) You can extend the NDS schema during or after the NetWare 5 installation.
To extend the NDS schema during the installation of NetWare 5, you select the Novell DNS/DHCP Services option in the Additional Products and Services dialog box. If you select this option, the NDS schema extensions will be installed during the installation process. You will then see a dialog box that prompts you to specify the location where the DNS and DHCP objects should be placed.
However, because Novell recommends that you place the DNS and DHCP objects in their own container objects, I recommend that you don't extend the NDS schema during the NetWare 5 installation. Instead, you should complete the NetWare 5 installation, create the container objects that will hold the DNS and DHCP objects, and then extend the NDS schema.
After installing NetWare 5, you can add and remove the schema extensions by using the DNIPINST utility at the server console. To add the schema extensions to NDS, you enter LOAD DNIPINST at the server console. To remove the extensions, you enter LOAD DNIPINST -R at the server console.
In addition to the schema extensions, several objects are added to NDS. You can place these objects anywhere in the NDS tree, but you should create container objects for DNS and DHCP objects so that you can restrict administrative access to the objects. You may want to create separate container objects for the DNS and DHCP services. You may even want to create multiple container objects for each service if you have more than one group of network administrators.
The following objects are created when you extend the NDS schema:
DNS/DHCP Locator Object . This object contains global default values, DHCP options, lists of DNS and DHCP servers, DHCP subnets, and DNS zones. You can place this object in any container object. I suggest you place the DNS/DHCP Locator object in one of the container objects you created for DNS or DHCP objects.
DNS/DHCP Group Object. DNS and DHCP objects use this object to gain rights to the DNS and DHCP data stored in NDS. When the DNS/DHCP Management Console creates DNS Server objects or DHCP Server objects, they become members of the DNS/DHCP Group object and are given the rights required to access data. Again, you can place the DNS/DHCP Group object in any container object. I recommend you place the DNS/DHCP Group object in the same container in which the DNS/DHCP Locator object resides.
RootSrvrInfo Zone Object. This object contains a list of the DNS servers that have authority for the Internet's root domain, enabling your company's DNS servers to refer queries to DNS servers on the Internet. You should place the RootSrvrInfo Zone object in the container object that holds other DNS objects.
Note: As we go to press, NetWare 5 Service Pack 1 is in beta testing, and Novell expects to finalize this service pack soon. If you are running the NetWare 5 DNS service, Novell recommends that you install NetWare 5 Service Pack 1, which corrects some minor problems with the DNS service. Check Novell's Support Connection web site (http://support.novell.com) for NetWare 5 Service Pack 1.
The DNS/DHCP Management Console
After installing the DNS/DHCP services on a NetWare 5 server, you install the DNS/DHCP Management Console on a Windows NT, 98, or 95 workstation by executing the SETUP.EXE file. This file is located in the SYS:\PUBLIC\DNSDHCP directory on the server running the DNS and DHCP services.
The DNS/DHCP Management Console has two tabs, which you use to configure the DNS and the DHCP services. The screen for both services is divided into four areas. (See Figure 6.)
Figure 6: You use the DNS/DHCP Management Console to manage the DNS and DHCP services in NetWare 5.
A toolbar appears at the top of the screen. You initiate all operations from the toolbar; there are no menus. When you move the cursor over a toolbar button, a help balloon pops up, displaying the button's name.
The left-hand pane displays the tree that contains all of the objects that have been defined for the service you selected. This tree also shows the hierarchical relationships among the objects.
The right-hand pane displays detailed information about the object that is selected in the tree.
At the bottom of the screen, an icon appears for each server that has been defined for the selected service. These icons show the status of the service, indicating whether it is running, stopped, or paused.
The rest of this article explains how to create and manage DNS objects. I recommend that you set up a test environment so you can try out the procedures and see how the objects are created and managed.
CREATING AND MANAGING DNS SERVER OBJECTS
The best way to start configuring your DNS server is to create a DNS Server object for each NetWare 5 server that will run the DNS service (NAMED.NLM). You should define at least two DNS Server objects to provide fault tolerance and offload processing.
You must have the Create right for the container object in which you want to create an NDS object. When creating most DNS objects, you can specify the container object in which the object will be created. DNS Server objects, however, are always created in the container object that holds the NetWare 5 Server object. After you create the DNS Server object, you can use the NWADMIN utility to move the DNS Server object to another container object.
You complete the following steps to create a DNS Server object:
Select the DNS tab in the DNS/DHCP Management Console.
Click the Create button in the toolbar. You click the Create button to create all types of DNS objects. To create some objects, you must select a parent object in the DNS tree before you click the Create button. For example, you must select a Zone object before you can create a resource record. However, you can create a DNS Server object regardless of the object that is selected in the DNS tree.
After you click the Create button, a menu appears, listing the types of objects you can create. Select the DNS Server option.
The Create DNS Server dialog box appears, containing the following fields:
Select Server Object. In this field, specify the NetWare 5 server that will run the DNS service. Enter the full (distinguished) NDS name of the NetWare 5 server, or click the NDS Browse button to select a server from the NDS tree.
Host Name. In this field, enter the DNS host name for the server. This host name may or may not be the same as the server's NetWare name.
Domain. In this field, specify the DNS domain in which the DNS server resides. For a server with the DNS fully qualified domain name of pseudo1.pseudo-corp.com, you would enter pseudo-corp.com in this field.
Define Additional Properties. If this box is checked, the DNS/DHCP Management Console displays detailed information about the DNS Server object after it is created. You can then review or modify the properties of the object you created.
Click the Create button in the dialog box to create the DNS Server object.
After the DNS Server object is created, a server icon appears at the bottom of the DNS/DHCP Management Console screen. At first the server icon has a slash through it, indicating that the DNS server is either inactive or unable to communicate with the DNS/DHCP Management Console. (The process of activating the DNS server is explained later in this article.)
Figure 7 shows a DNS Server object and its detail parameters, which include the zones for which the DNS server has authority. You assign DNS servers to zones in the Zone object's detail parameters. You can't modify these assignments in the DNS Server object's detail parameters.
Figure 7: If you select a DNS Server object in the left-hand pane of the DNS/DHCP Management Console, you can view a list of zones over which the DNS server has authority.
CREATING AND MANAGING PRIMARY ZONE OBJECTS
Each Zone object defines a DNS zone, which stores the DNS data for one or more domains. Typically, a separate zone is created for each domain, but child domains can be included in the zone that supports their parent domain. However, this article focuses on zones that are authoritative for one domain. This article also focuses on primary zones since secondary zones are required only if the primary DNS server for a domain is not a NetWare 5 DNS server.
Creating a Forward-Naming Zone Object
You must create a Zone object for each DNS zone that your DNS servers have authority for. You should first create a forward-naming Zone object by completing the following steps:
Select the DNS tab in the DNS/DHCP Management Console.
Click the Create button in the tool-bar, and select Zone from the menu that appears.
The Create Zone dialog box appears, containing several fields. (See Figure 8.)
Figure 8: In the Create Zone dialog box, you can create forward-naming zones and reverse-naming zones.
Create New Zone. Select this radio button to create a forward-naming zone. The fields you see in the Create Zone dialog box change, depending on the radio button you select.
NDS Context. In this field, specify the container object in which the Zone object will be created. You can also click the Browse button to select the container object from the NDS tree.
Zone Domain Name. In this field, enter the full DNS name for the domain that will be associated with this zone.
Primary. Select this radio button to create a primary zone.
Assign Authoritative DNS Server. If DNS Server objects have been created, you can select one in this field. You can specify additional DNS Server objects later. If you specify a DNS Server object that has been defined, the Host Name and Domain fields will be completed for you.
Host Name. In this field, you enter the DNS host name for the server. The host name may or may not be the same as the server's NetWare name.
Domain. In this field, you specify the DNS domain in which the DNS Server resides.
Define Additional Properties. If this box is checked, the DNS/DHCP Management Console displays detailed information about the DNS Server object after it is created. You can then review or modify the properties of the object you have created.
After the Zone object is created, its icon appears in the tree displayed in the left-hand pane of the DNS/DHCP Management Console screen. If you expand the Zone object, an RRSet object with the name @ appears. In DNS jargon, @ is shorthand for "this zone," so the @ RRSet object contains resource records that are associated with the domain for which you created the Zone object. The DNS/DHCP Management Console creates RRSet objects as needed to contain resource records.
Under the @ RRSet object is a Name Server resource record. As mentioned earlier, resource records are stored as attributes of RRSet objects.
Creating a Primary Reverse-Naming Zone Object
Although reverse-naming isn't essential, some operations depend on it. For example, an application can use reverse-naming to learn a user's DNS name for authentication purposes. If possible, you should create an IN-ADDR.ARPA reverse-naming zone for each IP address range on your network. For example, if your company is assigned the Class C addresses 192.168.5.0 and 192.168.17.0, you should create two IN-ADDR.ARPA zones, one for each Class C address range.
You should be aware of a restriction that is derived from the way IN-ADDR.ARPA zones are configured. The domains in the IN-ADDR.ARPA name space don't include subnet address information and are always organized on even 8-bit IP address boundaries. This restriction does not affect you if your company has been assigned a class A, B, or C IP address range or if your company subnets a Class A or B address range on an even 8-bit boundary.
Increasingly, however, Internet addresses are assigned based on a system called Classless Inter-Domain Routing (CIDR). With CIDR, address ranges don't necessarily fall on 8-bit boundaries.
If your company's IP address range does not fall on 8-bit boundaries, your company cannot host its own IN-ADDR.ARPA zone. Instead, you must work with your company's ISP, which owns the entire address class that contains your address range. Your ISP can add your company's IP addresses to the IN-ADDR.ARPA zones on the ISP's DNS servers. Unfortunately, you will not be able to use NetWare 5's Dynamic DNS to update these IN-ADDR.ARPA zones. This is a limitation of the DNS technology at this time.
If your company's IP address range falls on an even 8-bit boundary, you can create an IN-ADDR.ARPA zone. Creating an IN-ADDR.ARPA zone is similar to creating a forward-naming zone, except that you select the Create IN-ADDR.ARPA radio button in the Create Zone dialog box, which changes to display fields used to define a reverse-naming zone.
One of the fields that change is the Zone Domain Name field. For an IN-ADDR.ARPA zone, you specify your company's IP address range. For example, you may enter the Class C address 192.168.5.0 as the zone name.
When you enter the IP address range, the DNS/DHCP Management Console constructs the actual Zone object name in the blank below the IP address fields. Like all domain names, the names of IN-ADDR.ARPA zones are constructed by starting with the lowest domain in the hierarchy and joining together all of the domain names between the lowest-level domain and the root domain.
For example, the IN-ADDR.ARPA zone for the IP network 192.168.5.0 is 5.168.192.IN-ADDR.ARPA. If you enter 192.168.5.0 in the IP address fields, the DNS/DHCP Management Console displays 5.168.192.IN-ADDR.ARPA in the blank space below the IP address fields. This name identifies the IN-ADDR.ARPA Zone object you are creating.
Managing Zone Objects
To manage a Zone object, you select the Zone object in the left-hand pane of the DNS/DHCP Management Console screen. The details pane displays two tabs: Attributes and SOA Information. The Attributes tab contains the following fields:
Zone Type. This field has two radio buttons, Primary and Secondary, which enable you to change the zone type at any time. If you change the zone to a secondary zone, you must specify the IP address of a zone master server.
Available DNS Servers. This field lists the DNS servers for which you have created DNS Server objects. None of these servers are authoritative for the zone. You can assign zone authority to a DNS server by selecting it from this list and clicking the Add button.
Authoritative DNS Servers. This field lists DNS servers that are authoritative for the zone. You can revoke a DNS server's authority for the zone by selecting the DNS server in this list and clicking the Remove button.
Dynamic DNS Server. If you have enabled Dynamic DNS, you must configure one of the DNS servers that is authoritative for the zone as the zone's Dynamic DNS server.
Comments. Like many NDS objects, Zone objects have a Comments field in which you can add descriptive text. This field is a good place to record the Zone object's history.
The SOA Information tab for a Zone object contains Start of Authority (SOA) information, which includes some descriptive data for the zone and several operational parameters for the zone. On most DNS servers, SOA information is stored in an SOA resource record, but on a NetWare 5 DNS server, SOA information is stored as attributes of a Zone object. The SOA Information tab contains the following fields:
Zone Master. This field is informational only and does not have any effect on the operation of the NetWare 5 DNS service. On other DNS systems, this field identifies the DNS name of the primary DNS server for a zone, but this distinction does not apply to NetWare 5 DNS servers. Simply specify the DNS name of one of your DNS servers, so that users who query the zone for its SOA records can receive this information.
E-mail Address. This field should contain the e-mail address of a person who is the administrative contact for the domain. Because @ is a special character in DNS (meaning "this zone"), it cannot appear in the e-mail address. As a result, you would enter the e-mail address drew@pseudo-corp.com as drew.pseudo-corp.com.
Serial Number. A serial number is maintained for the zone. The serial number actually consists of four fields: Year, Month, Date, and Revision Number. The serial number is automatically incremented each time zone data change. If the serial number is not incremented, DNS servers will not update themselves from the zone records in NDS.
Refresh. This field specifies the interval in minutes at which a secondary DNS server checks its source DNS server to determine whether a zone transfer is required. The secondary DNS server uses the serial number to determine whether zone data have changed. The default refresh interval is 180 minutes. On a dynamic network, you may want to consider a shorter refresh interval such as 60 minutes.
Retry. This field specifies the time in minutes that a secondary DNS server waits after a failed zone transfer before this server retries the zone transfer. The default retry interval is 60 minutes. If you shorten the refresh interval, you should also shorten the retry interval. For example, if the refresh interval is 60 minutes, consider a retry interval of 20 minutes.
Expire. This field determines the maximum number of hours that a secondary DNS server continues to retry a zone transfer. If the secondary DNS server can't perform a successful zone transfer before this time expires, this DNS server discards data for the zone. The default expiration interval is 168 hours.
Minimum TTL. When a DNS server responds to a DNS query for data in its zone, the DNS server includes this value in the response. The Minimum TTL informs the recipient of the response the minimum time in hours that the data should be retained in the recipient's local DNS cache.
When you change an object's parameters, you must commit the changes to NDS. You can save the changes immediately by clicking the Save Data to NDS button in the toolbar, or you will be prompted to save your changes when you select another object in the DNS/DHCP Management Console screen.
CREATING AND MANAGING RESOURCE RECORDS
The rest of this article explains how to create and maintain three types of resource records. Each type of resource record has a conventional abbreviation, which you will want to recognize:
Address (A) resource records map host names to IP addresses. There is an Address resource record for every host with a name that can be queried in DNS.
Pointer (PTR) resource records map IP addresses to host names and appear in IN-ADDR.ARPA zones. If you implement IN-ADDR.ARPA zones, a Pointer resource record is created for each host identified in an Address resource record.
Name Server (NS) resource records identify which computers function as DNS servers for a zone. A zone may have several Name Server resource records.
Creating Address Resource Records
The majority of the resource records that you create will be Address resource records. They are the primary reason DNS exists in the first place, for without them names cannot be resolved to addresses. NetWare 5 provides a streamlined process for creating an Address resource record:
Select the DNS tab in the DNS/DHCP Management Console's screen.
Select the Zone object under which you will create the Address resource record.
Click the Create button in the toolbar.
Select Resource Record in the Create New DNS Record menu.
The Create Resource Record dialog box appears. Because Address resource records are created so frequently, the A radio button is selected by default.
Enter the host's name in the Host Name field. By default, the Domain field contains the name of the domain that is associated with the zone. Ordinarily, you will not edit this field.
In the IP Address field, enter the IP address of the host.
Click Create.
After you create the first Address resource record, search the DNS tree until you find this record. Expand the tree under the Zone object and look for an object with the host's name. This object will be the RRSet object for the host. Under the RRSet object, you will find another object that is named according to the host's IP address. This object is the resource record that you just defined.
You do not directly create RRSet objects. The DNS/DHCP Management Console automatically creates, manages, and destroys RRSet objects as needed.
Creating Pointer Resource Records
If you have created an IN-ADDR.ARPA zone, the DNS/DHCP Management Console creates a Pointer record to match each Address record that you create. Unfortunately, the DNS/DHCP Management Console does not automatically delete a Pointer record when you delete the corresponding Address record. You must remember to manually delete the Pointer resource record.
If Pointer resource records are being created for you by the DNS/DHCP Management Console, you may never need to create them manually. However, Address and Pointer resource records do get out of sync, so you'd better be prepared to do the job manually. To create a Pointer resource record, you complete the following steps:
Select the DNS tab in the DNS/DHCP Management Console's screen.
Select the IN-ADDR.ARPA Zone object under which you will create the Pointer resource record.
Click the Create button in the toolbar.
Select Resource Record in the Create New DNS Record menu.
The Create Resource Record dialog box for an IN-ADDR.ARPA zone appears. Select the PTR radio button.
The network address portion of the IP Address field is completed based on the definition of the IN-ADDR.ARPA zone. You must complete only the host ID portion of the IP address.
In the Host Name field, enter the host's name.
In the Domain field, enter the name of the host's domain.
Click Create.
After creating the first Pointer resource record, locate it in the IN-ADDR.ARPA zone. The resource record is created under an RRSet object. In an IN-ADDR.ARPA zone, the RRSet object takes its name from the host ID portion of the host's IP address. For example, an RRSet object with the name 45 in the zone 1.168.192.IN-ADDR.ARPA is associated with the host that has the IP address 192.168.1.45.
Creating Name Server Resource Records
Name Server resource records are required for both forward-naming and IN-ADDR.ARPA zones. Unless at least one Name Server resource record is placed in a zone, no DNS server is authoritative for the zone, and the zone is nonfunctional.
Ordinarily, you don't manually create Name Server resource records. Instead, you select a Zone object and add DNS servers to the Authoritative Name Servers list. The DNS/DHCP Management Console creates and destroys Name Server resource records as you add or remove DNS servers in this list.
Although the DNS/DHCP Management Console creates Name Server resource records, it does not create the Address records for a DNS server. In addition to having a Name Server resource record, each DNS server must be defined by an Address record that corresponds to the server's DNS name. A DNS server is defined by a Name Server resource record in each zone over which the server has authority and an Address resource record in the server's own domain. (See Figure 6.)
Modifying Resource Records
Actually, that was a trick heading because once a resource record is defined, you can make few changes to it. If you select a resource record and examine its detail parameters, you will find that most (probably all--I haven't checked every type of resource record) parameter fields cannot be edited. Either the fields are grey, indicating that they cannot be modified, or they are white but refuse to accept changes. In other words, to modify a resource record, you must delete the resource record and recreate it with the new settings.
However, the RRSet object contains two fields that can be modified:
Associated NDS Object. In this field, you can specify an existing NDS object that corresponds to a host. This field is informational only. It doesn't affect the operation of the DNS service.
Comments. You can enter a comment for each RRSet object.
You cannot modify the name of an RRSet object. To change the name, you delete the RRSet object and recreate it.
STARTING AND STOPPING THE DNS SERVER SERVICE
After you have defined a DNS Server object and at least one zone for which the DNS server has authority, you can activate the DNS service on the NetWare 5 server. Simply load NAMED.NLM on the NetWare 5 server. (NAMED stands for Name Daemon. A daemon is a background process that runs on a UNIX computer, and NAMED is the command that starts the DNS service on most Unix DNS servers.) The DNS Server process runs in the background and activates a status screen that you can access by pressing the Ctrl-Escape keys or the Alt-Escape keys.
By default, verbose messaging is turned off. You can enable verbose messaging by loading NAMED.NLM with the -V option. The -Q option turns off verbose messaging. Verbose messaging reports DNS server activity in detail and can negatively affect server performance. You should use the -V option only when troubleshooting .
The NAMED.NLM has several other options, and you can load NAMED.NLM re-entrantly with different options to make changes to the configuration of the DNS service. Some options enable you to import zone data from BIND database files, a topic that is beyond the scope of this article. The -S option displays a status report for the DNS service. The VI zone option forces the DNS service to update its records for a zone. (Zone specifies the name of a zone.) The -H option displays the command syntax for NAMED.NLM along with a complete list of options.
You can unload NAMED.NLM to stop the DNS service. You can also pause and resume the service by selecting a DNS Server icon in the DNS/DHCP Management Console and clicking the Start/Stop Service button in the toolbar. The Start/Stop Service button does not unload and reload NAMED.NLM. This button simply pauses the DNS service or causes it to resume operation. When the DNS Server service resumes, it reinitializes itself from the appropriate zone databases.
CONFIGURING NETWORK CLIENTS TO USE DNS
Finally, you must also configure network clients with the IP addresses of one or more DNS servers. The easiest way to configure clients is to use DHCP, but you can also configure clients by using static parameters.
To configure a Windows NT, 98, or 95 client on a TCP/IP network to use DNS, open the Network dialog box in the Control Panel. Then complete the steps for the operating system you are using:
If you are using Windows 98 or 95, select the TCP/IP protocol that binds to your network adapter, and click Properties.
If you are using Windows NT, select the Protocols tab. Next, select TCP/IP and click Properties. Then select the DNS tab.
For Windows NT, 98, or 95, configure the following fields on the DNS tab:
Enable DNS. Select this radio button. Host. In this field, enter the client's DNS host name.
Host. In this field, enter the client's DNS host name.
Domain. In this field, enter the client's DNS domain name.
DNS Server Search Order. In this field, add the IP addresses of the DNS servers the client should use. You must add the DNS servers in order of priority. You cannot adjust the order after the addresses are entered.
Domain Suffix Search Order. In this field, add the names of any domains that the client should search to resolve a name. For example, suppose this field contains the entry pseudo-corp.com and the client attempts to resolve the name charly. If the client cannot resolve charly, the client will attempt to resolve the name charly.pseudo-corp.com.
To configure a DOS client on a NetWare 5 network to use TCP/IP, you search for the RESOLV.CFG file, which resembles the following:
domain pseudo-corp.com
nameserver 192.168.1.1 You then edit this file as required to specify the host's domain and DNS server.
CONCLUSION
You now know how to implement a basic but functional DNS server using the DNS services in NetWare 5. If you are managing a small network, the information in this article may be all you require. If you are managing a complex network, you probably need to go beyond the basics.
The next article in this series will go beyond the basics. It will describe a few more types of resource records and explain how to extend the scope of a DNS service to support large and geographically distributed organizations. The next article will also explain how to support name spaces that include child zones and will provide some diagnostic techniques that you can use to troubleshoot a DNS service.
Drew Heywood is a network administrator who spends most of his time writing books and articles about networking. He is the author of several books including Novell's Guide to TCP/IP and intraNetWare, which is published by Novell Press.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.