Table of Contents

Configuring DNS Servers

The Domain Name System (DNS) is a distributed database for objects in a computer network. By using a name server approach, the network consists of a hierarchy of autonomous domains and zones. The name space is organized as a tree that often resembles the organizations that are responsible for the administration boundaries.

The basic function of DNS name servers is to provide information about network objects by answering queries. You can configure the Network Registrar DNS server and zones by accepting the system defaults or changing them through the Network Registrar GUI or CLI.

This chapter assumes that you already installed your software by following the instructions in the Network Registrar Installation Guide. It describes the basics of configuring the Network Registrar DNS servers and their primary and secondary zones. "Configuring DHCP Scopes and Leases," describes how to set some of the more advanced zone and server properties.

Table 5-1 lists the topics and sections you need to configure Network Registrar DNS servers.

Configuring a Primary Name Server

You do not need to create a loopback zone because Network Registrar automatically creates one. A loopback zone is a reverse zone that enables a host to resolve the loopback address (127.0.0.1) to the name localhost. The host uses the loopback zone so that it can direct network traffic to itself. The reverse loopback zone is called 127.in-addr.arpa. (If you inadvertently delete the loopback zone, see "Restoring a Loopback Zone," for how to recreate it.)

Adding a Primary Forward Zone

This section explains how to configure a primary name server with a primary forward zone. When you are done with this procedure, follow the procedure in the "Adding a Primary Reverse Zone for the Server" section to configure a reverse zone for each network you are using.

Creating the Zone Name

The first thing to do in creating a forward zone is to create a name for the zone.

Using the GUI:

Step 1   From the Server Manager window (Figure 3-11), select the DNS server you want to configure as the primary name server for the zone. If you are configuring the server on your local host to be the primary name server, select the DNS@localhost object.

Step 2   Click the Add toolbar button to display the Add Zone dialog box (Figure 5-1).

Step 3   In the Name field, enter the full domain name of the primary zone. End the name with a trailing dot, because it is a fully qualified domain name (FQDN).

---

Note   You must end fully qualified domain names (FQDNs) with a trailing dot, or they are interpreted as relative to the current domain.

---

Step 4   Select Primary as the type of zone to add.

Step 5   At this point, you may want to import an existing primary zone from a Berkeley Internet Name Domain (BIND) format zone file. There are many existing DNS servers that comply with the BIND protocol. To import a BIND format zone file, enter the name of the file in the Import from BIND file field, or click the Browse button to locate the BIND zone file in your directories. If you do not want to import the zone file, leave the Import from BIND file field blank. For details on importing a zone file, see the "Importing and Exporting Zone Data" section.

Step 6   Click OK. This opens the Add Primary DNS Zone dialog box.

Using the CLI:

Use the zone create primary command to create a primary zone.

The following example adds the example.com zone, specifying that it is a primary zone and that the name server is nameserver and the person in charge is hostmaster.

nrcmd> zone example.com. create primary nameserver hostmaster 
 

If you want to import an existing Berkeley Internet Name Domain (BIND) format zone file, use the zone create primary command with the file property.

nrcmd> zone example.com. create primary file=hosts.local 

 

For details on importing a zone file, see the "Importing and Exporting Zone Data" section.

Importing and Exporting Zone Data

The easiest and quickest way to create a primary zone is to import an existing Berkeley Internet Name Domain (BIND) format zone file. Many existing DNS servers comply with the BIND protocol. Network Registrar also provides the capability to export these same kinds of files to another server.

Importing Using the GUI

Network Registrar can import DNS zone data in BIND file format, as defined in RFC 1035. To import an existing BIND file from the GUI, specify the BIND filename when you are adding a zone.

Step 1   When entering the primary zone data in the Add Zone dialog box, enter the name of the BIND file or click the Browse button to locate the file. Using the Browse button opens a file selection dialog box.

Step 2   Navigate to the zone configuration file location and select the file. The filename should reflect the zone you are importing. The file often ends with a .txt or .config file extension.

Step 3   Click OK. You should get a series of progress messages in the status bar. Corrupt or unreadable BIND files generate errors. Keep track of any errors you get so that you can modify the BIND files accordingly.

Step 4   Reload the DNS server.

Importing Using the CLI

Network Registrar can import DNS zone data in BIND file format, as defined in RFC 1035. To import an existing BIND file from the CLI, use the zone create primary command.

nrcmd> zone example.com. create primary file=hosts.local 

 

Network Registrar can also read a BIND named.boot file and import all the zone files identified in the named.boot file. To import a named.boot file, use the import named.boot command and specify the name of the file. You cannot import BIND 8 named.conf files.

nrcmd> import named.boot /etc/named.boot 
 

Exporting Zone Data Using the CLI

Network Registrar can also export DNS zone data in BIND file format. Exported data can include static or dynamic addresses (those assigned by DHCP) or both. When exporting dynamic addresses, Network Registrar includes the MAC address of the host in a text (TXT) resource record. To export a DNS zone, use the export zone command and specify the type of addresses (static, dynamic, or both) and the name of the output file.

Example 5-1 shows the partial file output from the export zone cisco.com command. Because host STANLEY is a DHCP client, the MAC address (the client-id from the DHCPREQUEST packet) appears in a TXT record.

$ORIGIN cisco.com.
moose IN CNAME moosehorn.cisco.com.
moosehorn IN A 172.16.75.57
STANLEY 1200 IN A 172.16.75.216
STANLEY 1200 IN TXT "01:00:60:97:3f:ce:f0"

Tip You can also export the names of all the zones of the DNS server. Use the export zonenames command and specify the type of zones you want (forward, reverse, or all) and the output file.

Exporting UNIX Hosts Files Using the CLI

Network Registrar can export DNS data in UNIX /etc/hosts file format. Network Registrar combines information from the A and CNAME records for a host. To export all the zones in the server in host file format, use the export hostfile command and specify the name of the output file.

Example 5-2 shows selections from a hosts format export of the cisco.com zone.

172.16.75.57 moosehorn.cisco.com moosehorn moose
172.16.75.216 stanley.cisco.com	
 

Primary Zone Properties in the GUI

The Primary DNS Zone dialog box of the GUI (Figure 5-2) has a number of tabs that relate to the primary zone configuration. These tabs are:

• SOA—Configures the Start of Authority record for the zone
  
  
• Name Servers—Configures the authoritative name servers for the zone
  
  
• Hosts—Configures the host name-to-address mappings for the zone
  
  
• Zone Transfers—Disallows, allows, and limits zone transfers from the zone
  
  
• DHCP—Allows dynamic DNS updates from all or specified addresses
  
  
• Subzones—Delegates subzones to other servers
  
  
• Resource Records—Controls the zone's resource records
  
  

Setting the Zone's Start of Authority

The Start of Authority (SOA) resource record designates the top of the zone in the DNS inverted-tree namespace. There can be only one SOA record per zone. Setting the SOA record includes setting the following properties for the primary zone:

• Time to live
  
  
• Hostmaster (person in charge) name
  
  
• Primary server name
  
  
• Serial number
  
  
• Secondary refresh time
  
  
• Secondary retry time
  
  
• Secondary expire time
  
  
• Minimum time to live
  
  

For now, you will be adding just the hostmaster and primary server information, the minimum needed to create a zone. For details on the other SOA record properties, see the "Setting the Zone's SOA Properties" section.

Using the GUI:

Step 1   When you open the Add Primary DNS Zone dialog box for the first time, the SOA (Start of Authority) tab is selected (Figure 5-3). The name of the zone appears in the Name field.

Step 2   Skip the TTL field for now. This is described in the "Setting the SOA Time to Live" section.

Step 3   In the Contact email address field, enter the e-mail address of the zone's hostmaster (person in charge or administrator of the zone).

Note   Substitute a dot (.) for the at symbol (@) that is normally part of the e-mail address, and end the address with a trailing dot ("tom@ns.example.com." becomes "tom.ns.example.com."). Also, use a backslash before any dot that precedes the @ in the original address (if the address is "tom.marketing@example.com." you enter "tom\.marketing.example.com.)"

Step 4   In the Name of primary server field, enter the name of the primary server.

Enter either just the host name, such as ns, or the fully qualified domain name, ns.example.com. If you enter the FQDN, be sure to end it with a trailing dot.

Step 5   Accept the defaults in the remaining fields. These are more advanced settings, which are described in the "Setting the Zone's SOA Properties" section.

Using the CLI:

You used the zone create command in the previous section to create the primary zone, specify the name server, and set its hostmaster. Now use the zone set command to set the remaining SOA values for the zone. You can accept the defaults or set the remaining values: expiration time, minimum TTL, default TTL, refresh time, retry time, and serial number. Here are their default values:

nrcmd> zone example.com. set expire=604800 
nrcmd> zone example.com. set minttl=86400 
nrcmd> zone example.com. set defttl=86400 
nrcmd> zone example.com. set refresh=10800 
nrcmd> zone example.com. set retry=3600 
nrcmd> zone example.com. set serial=1 
 

For details on these SOA records, see the "Setting the Zone's SOA Properties" section.

Adding an Authoritative Server for the Zone

Authoritative name servers are responsible for the validity of the data in their zones. Both primary and secondary servers can be authoritative. The crucial difference between them is the location from which they get their zone data. A primary server reads its data from local configuration information, while a secondary server loads its data from another name server.

A zone must have at least one name server. (In fact, Network Registrar does not consider the zone information to be complete unless you add at least one name server.) The name servers you list here should be the name servers that you want people outside your organization to query when requesting resolution of names within your zone.

You should add the name of the primary server you indicated for the zone as the authoritative server. This creates a Name Server (NS) record for this server in the zone database. You must also add a host address for the server, which is described in the "Adding a Host Address for the Primary Server" section.

Using the GUI:

Step 1   On the SOA tab, copy the name of the primary server for the zone in the Name of primary server field.

Step 2   Click the Name Servers tab (Figure 5-4).

Step 3   Click the Add button. This opens the Add Name Server dialog box.

Step 4   Paste the name you copied from the SOA tab into the Name field of the Add Name Server dialog box. (Be sure the name ends with the trailing dot if it is a FQDN.)

Step 5   Click OK to add the name to the Name field of the Add Primary DNS Zone dialog box.

For details on how to add more authoritative servers, see "Setting the Authoritative Name Servers" section. You must specify a host address for this and any additional name server you add. Adding a host address is described in the "Adding a Host Address for the Primary Server" section. If you remove a name server using the Remove button, also remove the host address for it.

Using the CLI:

Use the zone addRR NS command to add the Name Server (NS) resource record for the primary DNS server for the zone.

nrcmd> zone example.com. addRR @ NS ns.example.com. 
 

See the "Adding a Host Address for the Primary Server" section for adding a host address record for this NS record.

If you want to remove an NS record, use the zone removeRR NS command. Be sure also to remove the name server's host address record.

Adding a Host Address for the Primary Server

Using Network Registrar, you can add, edit, or remove hosts from a primary zone on a DNS server. You can establish or change the permanent name-to-IP-address associations for the zone. You can also add hosts to reverse zones, and keep the host information up-to-date as you add and remove hosts. However, you cannot add hosts to secondary zones.

Configuring hosts adds Address (A) resource records for the zone. In this section, you will add an A record for the authoritative server you entered in the previous section—you must create an A record for each Name Server (NS) record in the zone.

Using the GUI:

Step 1   In the Add Primary DNS Zone dialog box, click the Hosts tab (Figure 5-5).

Step 2   Click the Add button. This opens the Add Host dialog box (Figure 5-6).

Step 3   Copy the same primary server name that you copied into the Name Servers tab into the Name field of the Add Host dialog box, remembering the trailing dot rule.

Step 4   In the Addresses field, enter the IP address of the primary name server.

Leave the Aliases and MX records fields blank for now. They are described in the "Configuring Hosts in a Zone" section. Also, do not select the Generate reverse mapping records option.

Step 5   Click OK to add the name and address to the Add Primary DNS Zone dialog box.

Using the CLI:

Use the zone addHost command to add the server host and address.

nrcmd> zone example.com. addHost ns 192.168.40.2 
 

If you want to remove the host, use the zone removeHost command. Also be sure to remove the NS record if the host is a name server, as described in the "Adding an Authoritative Server for the Zone" section.

Confirming Your Settings and Reloading the Server

You can confirm your current primary zone configuration by looking at the resource records you created in the process. Once assured that the configuration is correct, reload the DNS server with the information.

Using the GUI:

Step 1   Click the Resource Records tab (Figure 5-7) to verify your zone configuration. Review the resource records created so far. You should see an SOA record for the zone, and an NS and A record for its authoritative name server.

Step 2   Once you are satisfied with the configuration, click the Close button.

Step 3   Reload the DNS server:

Step 4   To confirm that the server is running, check the Status Monitor. If the Status Monitor window is not visible, open it from the View menu. If the server traffic signal is not included in the window, right-click the server icon and click Add to status monitor. The server traffic signal should show a green light.

Adding a Primary Reverse Zone for the Server

To have a correct DNS configuration, you must create a reverse zone for each network you are using. A reverse zone is a primary zone that allows DNS servers to convert IP addresses back to host names. Reverse zones are all in the special domain, in-addr.arpa.

You can create a reverse zone manually or you can import it from an existing BIND reverse zone file.

Using the GUI:

Step 1   Open the Add Zone dialog box for the same DNS server you selected for the forward zone configuration. (See the "Adding a Primary Forward Zone" section for the initial steps to the procedure.)

Step 2   Enter the reverse zone name in the Name field. This is the reverse of your zone's network number, added to the special in-addr.arpa domain. Omit any trailing zeroes in the conversion. For example, if your network number is 1.2.3.0, your reverse zone is 3.2.1.in-addr.arpa; if the network number is 1.2.0.0, the reverse zone is 2.1.in-addr.arpa.

Step 3   Select Primary as the zone type. (To import a reverse zone file, see the "Importing and Exporting Zone Data" section.) Then click OK to open the Add Primary DNS Zone dialog box.

Step 4   Enter the same hostmaster and primary server name you entered for the forward zone. Do not enter them as reverse addresses. (Remember to end any FQDNs with a trailing dot and use the proper hostmaster syntax.) Leave the other fields as they are for now.

Step 5   Click the Name Servers tab.

Step 6   Enter the same authoritative server as for the forward zone. (See the "Adding an Authoritative Server for the Zone" section for the procedure.)

---

Note   There is no Host tab for a reverse zone. After you create the reverse zone, Network Registrar automatically creates all the appropriate host address-to-name entries as you add hosts to the forward zone. Just be sure when adding the hosts that the Generate reverse mapping records option is selected.

---

Step 7   Check your configuration on the Resource Records tab. You should have an NS record and an SOA record for the reverse zone.

Step 8   Click Apply.

Step 9   Reload the DNS server and check the Status Monitor window.

Step 10   Check the Resource Records tab for the reverse zone again. You should now see three records: an SOA, NS, and a new reverse address, or pointer (PTR), record for the address of the server host. Notice that the PTR record name does not end with a dot since it is relative to the reverse zone domain name.

If you go to the Host tab for the primary zone (example.com), notice that when you edit the server host, the Generate reverse mapping records option is now selected. This caused the PTR record to be created.

Step 11   Click OK.

Using the CLI:

Use the zone create primary and zone addRR NS commands, as in creating the forward zone and adding the name server for it.

nrcmd> zone 40.168.192.in-addr.arpa. create primary NS hostmaster 
nrcmd> zone 40.168.192.in-addr.arpa. addRR @ NS ns.example.com. 
 

Import an existing BIND reverse zone the same way you would a forward zone, by using the file property of the zone create primary command.

Configuring the Server as a Secondary for a Zone

When you configure a zone, you should choose a primary name server and at least one secondary server. If you have only one secondary server, remove it geographically from the primary server. It should not be on the same network segment as the primary server. If you have only one name server and it goes down, there is nothing to look up names. A secondary name server splits the load with the primary name server or handles the whole load if the primary name server is unavailable.

Before you add a secondary name server, understand that the crucial difference between a primary and secondary name server is where it gets its data. A primary server reads its data from files. A secondary name server loads its data over the network from the primary. When a secondary server starts up, it contacts the primary and pulls the zone data over. This is known as a zone transfer.

Network Registrar lets you configure the DNS server with a secondary zone, which makes the server a secondary server for that zone. In configuring the secondary zone, you also need to indicate the address of the primary server from which to perform zone transfers.

You also have to add this primary server in Network Registrar, or at least let Network Registrar know about it. If you add the new primary server in Network Registrar, you need to add as a primary zone the one you configure as a secondary zone in this section.

This section describes how to add a secondary zone and make the local server a secondary DNS server for it.

Adding a Secondary Forward Zone

Remember that adding a secondary zone for a server makes the server act as a secondary (backup) for that zone.

Using the GUI:

Step 1   In the Server Manager window, select the DNS server to configure as a secondary server for a zone.

Step 2   Click the Add toolbar button to display the Add Zone dialog box (Figure 5-8).

Step 3   Enter the name of the secondary zone in the Name field. This zone can be a subdomain of the domain name you entered for the primary zone, or it can be in a different domain.

Step 4   Select Secondary as the type of zone to add. (You cannot import a secondary zone for a server. However, you can import that same zone as a primary when you configure the primary server.)

Step 5   Click OK. This opens the Add Secondary DNS Zone dialog box with the Secondary Zone Configuration tab selected (Figure 5-9).

Step 6   Enter the IP address of the primary server from which the zone transfer should occur. This address can be on the same or a different network segment.

Step 7   Click the Zone Transfers tab (Figure 5-10). The Do not restrict zone transfers is selected by default. You can choose to restrict zone transfers to specified addresses only by selecting Restrict zone transfers to the following addresses. Then enter the restricted IP addresses in the fields.

Notice that there is no Resource Records tab for a secondary zone since this data is not stored for it. The resource records "belong" to the primary zone on the primary server from the which the zone transfer occurs.

Step 8   Click OK.

Step 9   Reload the DNS server and check the results.

Notice that the secondary forward zone appears under the server with a distinguishing icon so that you can differentiate it from the primary zones for the server.

Using the CLI:

Use the zone create secondary command to create a secondary zone. The IP address you include is the address of the primary name server for zone transfers.

nrcmd> zone secondary.example.com. create secondary 192.168.41.1 
 

To restrict zone transfers to particular addresses only, use the zone enable restrict-xfer command, then use the zone set restricted-set command to specify the addresses, separating them with a comma.

nrcmd> zone secondary.example.com. enable restrict-xfer 
nrcmd> zone secondary.example.com. set restricted-set=192.168.1.1,192.168.1.20 
 

Adding a Secondary Reverse Zone

Add the secondary reverse zone associated with the secondary forward zone. Use the same method as adding a primary reverse zone (see the "Adding a Primary Reverse Zone for the Server" section), except set the zone type to Secondary. Then translate the secondary zone's domain name into an in-addr.arpa reverse domain (ending it with a trailing dot). Finally, add the same primary server address as for the secondary forward zone and specify any zone transfer address restrictions, as in the "Adding a Secondary Forward Zone" section.

Be sure to reload the DNS server and check its status.

Configuring a Caching-Only Server

Although all servers are caching servers, because they save the information received until the data expires, you can create a caching-only server that is not authoritative for any zone. The caching-only name server's only function is to answer queries by storing in memory data from authoritative servers. The caching-only server can then "learn" or cache the information (for a specified update frequency) for answering subsequent queries. This can avoid the system overhead and reduce the traffic of zone transfers. (Setting the cache update frequency is described in the "Setting Maximum Cache TTL" section.)

When you first install Network Registrar on a system connected to the Internet, the DNS server automatically becomes a nonauthoritative, caching-only server until you configure zones for it. If you keep the DNS server as a caching-only server, you must have another primary or secondary DNS server somewhere that is authoritative and to which the caching-only server can refer. A caching-only server is never registered on the Internet. In fact, it should never be set up as an authoritative name server for any zone, because this can cause lame delegation. Lame delegation occurs when a zone is delegated to a server that is not authoritative for the zone.

A caching-only server must be set up to respond to recursive queries. A recursive query is where a server keeps trying to get to an authoritative server so that it can update its cache with the address resolution data. Because Network Registrar sets up servers as recursive by default, you should just verify that this option is set.

Using the GUI:

Step 1   In the Server Manager window, select the DNS server to designate as caching-only.

Step 2   Click the Show Properties toolbar button to display the DNS Server Properties dialog box.

Step 3   Click the Options tab (Figure 5-11) and confirm that Enable recursive queries is selected. If not, select it.

Step 4   Click OK.

Step 5   Reload the server to save the changes, if necessary.

Using the CLI:

Use the dns get no-recurse command to check that no-recursion is disabled (that is, recursion is enabled).

nrcmd> dns get no-recurse 
100 Ok
no-recurse=disabled
 

If the no-recurse property is not disabled, use the dns disable no-recurse command to do so.

nrcmd> dns disable no-recurse 
100 Ok
no-recurse=disabled
 

Setting Basic DNS Server Properties

You can set properties for the DNS server itself, in addition to those you already set for its zones. For this, Network Registrar provides a Server Properties dialog box, which is divided into the following tabs (see Figure 5-12):

• General—Provides the server name, its cluster name, and the DNS software version
  
  
• Forwarders—Sets up forwarders so that the server becomes a forwarding server
  
  
• Root Name Servers—Identifies the root name servers to which the server refers
  
  
• Exceptions—Identifies domains you want resolved by special servers other than root servers
  
  
• Options—Enables and disables options such as recursive and round-robin querying
  
  
• Advanced—Sets the caching interval and other more advanced properties
  
  

This section describes the general server properties through the option properties. The advanced properties are described in the "Setting Advanced Server Options" section.

Setting General Server Properties

You can display DNS general server properties, such as the name of the cluster or host machine to which this server belongs, and the version number of the Network Registrar DNS server software.

You can change the internal name of the DNS server by deleting the current name and entering a new one. This name is used for notation, and does not reflect the server's official name. Network Registrar uses the server's IP address for official name lookups and for dynamic DNS (RFC 2136) updating purposes.

Using the GUI:

Use the General tab in the DNS Server Properties dialog box to display the cluster name and the version number (Figure 5-12). Change the server name if you wish, then click Apply.

Using the CLI:

Use the dns show command to display the DNS server's properties.

nrcmd> dns show 
100 Ok
DNS@localhost:
    hide-subzones = disabled
    ixfr-enable = enabled
    ixfr-expire-interval = 7d
    lame-deleg-notify = enabled
    ...
 

Defining Forwarders for the Servers

Sites that must limit their network traffic for security reasons, because they pay by the packet or the network connection is a slow link, can designate one or more servers to be forwarders for the current server. These servers handle all off-site requests before the local server searches for the answer through the Internet. Over time, the forwarders build up a rich cache of data that can satisfy most requests.

Forwarders are useful in the following situations:

• To reduce the load on the Internet connection—Forwarders build up a cache and thus reduce the number of requests sent to external name servers, and improve DNS performance.
  
  
• To improve DNS response to repeated queries—The forwarder's cache can answer most queries.
  
  
• To handle firewalls—Hosts that do not have access to root name servers can send requests to the forwarder that does.
  
  

---

Note   You may want to restrict the name server even more by stopping it from even attempting to contact an off-site server. A slave server uses forwarders exclusively. It answers queries from its authoritative and cache data, but it relies completely on the forwarders for data not in its cache. If the forwarders do not provide an answer, it does not try to contact other servers to find information.

---

You can specify multiple forwarders. If the first forwarder does not respond after eight seconds, Network Registrar asks each remaining forwarder in sequence until it receives an answer or it gets to the end of the list. If the DNS server does not get an answer, the next step depends on whether you have slave mode on or off.

• If slave mode is on, the DNS server stops searching and responds that it cannot find the answer.
  
  
• If slave mode is off, the DNS server sends the query to the domain's designated name servers as if there were no forwarders listed.
  
  

Using the GUI:

Step 1   In the DNS Server Properties dialog box, click the Forwarders tab (Figure 5-13).

Step 2   Enter the address or addresses of the forwarder or forwarders you want to add. You can replace or delete any entries.

Step 3   If you want to make the server a slave server, select the Slave mode check box. Do this if you want the server to rely on its cache and forwarders only.

Step 4   Click OK.

Using the CLI:

Use the dns addForwarder command to specify the address or (space-separated) addresses of name servers you want your Network Registrar DNS server to use as forwarders.

nrcmd> dns addForwarder 192.168.40.111 
 

Use the dns enable slave-mode command to designate the server as a slave server.

nrcmd> dns enable slave-mode 
 

To edit your forwarder list, you must delete any offending forwarder and re-enter another one. To delete a forwarder or list of forwarders, use the dns removeForwarder command.

nrcmd> dns removeForwarder 192.168.40.111 
 

To list the current forwarders, use the dns listForwarders command.

nrcmd> dns listForwarders 
 

Defining Root Name Servers

Root name servers know the addresses of the authoritative name servers for all the top-level domains. When you first start a newly installed Network Registrar DNS server, it uses a set of pre-configured root servers (sometimes called root hints) as authorities to ask for the current root name servers.

When Network Registrar gets a response to a root server query, it caches and refers to the root server list. When the cache expires, it repeats the process. Because Network Registrar has a persistent cache, it does not need to requery this data when it restarts.

You can also define internal root servers for your network. If you have a large name space, adding one or more internal root servers is a good solution, even better than using forwarders.

The time to live (TTL) on the official root-server records is currently six days, so Network Registrar will requery every six days, unless you specified a lower Maximum Cache TTL value (see the "Setting Maximum Cache TTL" section).

The root hints list is updated about every six months. You can FTP to ftp.rs.internic.net to get the latest version of the list, or you can run the nslookup or dig tool.

Adding a Root Name Server

You can add as many root server names and addresses as you want. It is important to configure only valid root name servers for proper operation. Network Registrar checks that you are entering a valid name and address, and displays an error message if the information is incorrect.

Using the GUI:

The Root Name Servers tab of the DNS Server Properties dialog box contains a set of hints about root name servers.

Step 1   In the DNS Server Properties dialog box, click the Root Name Servers tab (Figure 5-14).

Step 2   Enter the name and address of the root hint server. You can, for example, add an internal root server to the list. (Just be careful not to remove any existing ones.)

Step 3   Click OK.

Using the CLI:

Use the dns addRootHint command to add root name servers. Specify both the name and address of the server. Do this only if the server was inadvertently removed from the list or if there was an update to the list since the last version.

nrcmd> dns addRootHint a.root-servers.net. 198.41.0.4 
 

Updating the Root Name Servers List

Be careful in removing any root servers from the list. If you accidentally remove the IP address for one of the roots, or you know that it might have changed, use the nslookup tool to recall or check the address.

nslookup a.root-server.net 
Name: a.root-servers.net
Address: 198.41.0.4
 

To edit either the name or address of a root entry in the DNS Server Properties dialog box, select it in either column and enter or overtype it. Use the CLI command dns removeRootHint (carefully) and add the correct entry using the dns addRootHint command.

You can also use the dig tool, if you have it installed as part of the BIND distribution, to update the roots list.

dig @a.root-servers.net . ns > db.cache 
 

Finally, you can FTP to the ftp.rs.internic.net site to get the latest roots list.

ftp ftp.rs.internic.net 
<login>
ls domain 
<roots list>
 

Specifying the Exception List

If you do not want the DNS servers to use the standard resolution method of querying the root name server for certain names outside its domain, use resolution exception. This method bypasses the root name servers and targets the address of the server that should handle name resolution for a particular domain. This is done through a Network Registrar facility called Resolution Exception or Intranet Builder.

For example, a company, QuickExample, has four subsidiaries: Red, Blue, Yellow, and Green. Each subsidiary has its own domain under the .com domain. When users at Red want to use resources at Blue, their DNS server knows that it is not authoritative for Blue and appeals to the root name servers. These queries cause unnecessary traffic, and in some cases fail because internal resources are often barred from external queries or sites that use unreachable private networks whose addresses are not unique. The Network Registrar resolution exception handling solves these problems.

To use resolution exception handling, the administrator at Red lists all the domains that users might want to reach, and at least one corresponding name server. In this case, the administrator lists the three other domains for the QuickExample company. Now when a user at Red wants to reach a server at Blue, the Red server queries the specified Blue name server instead of querying the root.

Adding an Exception

Resolution exception handling is a DNS server property that you can assign.

Using the GUI:

Step 1   In the DNS Server Properties dialog box for a selected server, click the Exception tab (Figure 5-15).

Step 2   Click the Add domain name button.

Step 3   Enter the name of the domain you want to add as a resolution exception (Figure 5-16).

Step 4   Click OK.

Step 5   Enter the address of a name server for that domain (Figure 5-17). You can enter multiple name server addresses for each exception domain, each separated by a comma.

Step 6   Click OK after adding each address.

Using the CLI:

Use the dns addException command to add the exception domains and servers, separated by a comma.

nrcmd> dns addException blue.com. 192.168.1.4,192.168.1.7 
 

Use the dns listExceptions command to list the available exceptions.

Editing and Removing an Exception

You can edit and remove exception properties from a server.

Using the GUI:

• You can edit both the domain and the server address on the Exception tab of the DNS Server Properties dialog box by selecting it and clicking the appropriate button (Edit domain name or Edit address).
  
  
• To remove a domain name, select it, then click the Remove domain name button.
  
  
• To remove an address, select it, then click the Remove address button. If you select the last remaining address for the domain and try to remove it, clicking OK in a confirmation dialog box removes both it and the domain; if you click Cancel, you can edit the address or add another one before removing it.
  
  

Using the CLI:

Use the dns removeException command to remove the exception server.

nrcmd> dns removeException blue.com. 
 

Setting DNS Server Options

You can enable or disable the following DNS server options:

• Recursive and iterative queries
  
  
• Round-robin
  
  
• Hiding subzones
  
  
• Subnet sorting
  
  
• Incremental transfer (IXFR)
  
  
• NOTIFY
  
  

Enabling Recursive Queries

There are two types of queries—recursive and iterative (nonrecursive). DNS clients typically generate recursive queries. When the query is recursive, the name server asks other DNS servers for any nonauthoritative data not in its own cache. When the query is iterative, the name server answers the query if it is authoritative for the zone, has the answer in its cache, or tells the client which name server to ask next.

Recursion is like saying "Here's all I know, but I'll talk to Bob and get back to you with the rest." Iteration is like saying "Here's all I know, but Bob can tell you more."

Using the GUI:

Step 1   In the DNS Server Properties dialog box, click the Options tab (Figure 5-18).

Step 2   The Enable recursive queries check box is selected by default. If you want to make queries iterative, deselect the check box. For example, you might want to make a root server iterative.

Using the CLI:

In the CLI, recursion is set by default. To set iterative queries, enable the no-recurse property.

nrcmd> dns enable no-recurse 
 

Enabling Round-Robin

A query may return multiple A records for a name server. To compensate for the fact that most DNS clients start with (and most limit their use to) the first record in the list, you can enable round-robin to share the load. Enabling round-robin ensures successive clients resolving the same name will connect to different addresses on a revolving basis. This operation causes the Network Registrar DNS server to re-arrange the order of the records each time it is queried. It is a method of load sharing rather than load balancing (which is based on the actual load on the server). You can adjust the rate of switch over from one server to another through the TTL property of the server's A record.

Using the GUI:

Step 1   In the DNS Server Properties dialog box, click the Options tab (Figure 5-18).

Step 2   Select the Enable round-robin check box to enable round-robin.

Using the CLI:

Use the dns enable round-robin command to set the round-robin property. By default, round-robin is enabled.

nrcmd> dns enable round-robin 
 

Hiding Subzones

Hiding subzones hides the zone's internal infrastructure from outside the zone. When enabled, it must include the top-level domain. You can enable or disable hiding the subzones using the CLI only.

Using the CLI:

Use the dns enable hide-subzones command to configure a server to hide information about the subzone hierarchy for all zones delegated from this server. This feature collapses a portion of the domain namespace into one virtual zone.

nrcmd> dns enable hide-subzones 
 

To disable hiding subzones, use the dns disable hide-subzone command. This is the default setting.

Enabling Subnet Sorting

If you enable subnet sorting (as implemented in BIND 4.9.7), the Network Registrar DNS server checks the network address of the client before responding to a query. If the client, DNS server, and target of the query are on the same subnet, and the target has multiple A records, the server tries to reorder the A records in the response by putting the target's closest address first in the response packet. DNS servers always return all of a target's addresses, but most clients use the first address and ignore the others.

If you enable both round-robin and subnet sorting, Network Registrar first applies round-robin sorting and then applies subnet sorting. The result is that if you have a local answer, it remains at the top of the list, and if you have multiple local A records, Network Registrar cycles through them.

Using the GUI:

On the Options tab of the DNS Server Properties dialog box, click the Enable subnet sorting check box to enable subnet sorting.

Using the CLI:

Use the dns enable subnet-sorting or dns disable subnet-sorting command. By default, subnet sorting is disabled.

nrcmd> dns enable subnet-sorting 
 

Enabling Incremental Zone Transfers (IXFR)

Incremental zone transfer (IXFR, described in RFC 1995) controls whether secondary zones can request incremental transfers from their primary zone. An incremental zone transfer does not transfer all the zone data, but just that part of it that changed. IXFR works together with NOTIFY (see the "Enabling NOTIFY" section), which enables the primary zone to inform its secondary zones of modifications, to ensure more efficient zone updates.

Use IXFR and NOTIFY in environments where the namespace is relatively dynamic.

Using the GUI:

On the Options tab of the DNS Server Properties dialog box, select the Enable incremental transfer (IXFR) check box to enable incremental transfer.

Using the CLI:

Use the dns enable ixfr-enable command to enable incremental transfer for all zones for which you have not configured specific behavior. By default, the ixfr-enable property is enabled.

nrcmd> dns enable ixfr-enable 
 

Use the following commands to fine tune IXFR:

• zone disable ixfr—Disables incremental transfer for a single zone if you do not want to use the global value from the dns disable ixfr-enable command, unless you override it.
  
  

nrcmd> zone example.com. disable ixfr 
 

• remote-dns create and disable—Allows only some servers to perform incremental zone transfers.
  
  

nrcmd> remote-dns 192.169.1.15 create 

nrcmd> remote-dns 192.169.1.15 disable ixfr 
 

• dns set ixfr-expire-interval—Changes the incremental transfer interval (in seconds).
  
  

nrcmd> dns set ixfr-expire-interval=7000 
 

• dns enable relax-ixfr-query-validation—When BIND 8.2.2p5 responds to an IXFR query, it erroneously responds with the value AXFR (full zone transfer). By default, Network Registrar adheres to RFC 1995, so it expects the value IXFR in that field and, therefore, rejects the BIND 8.2.2p5 response of AXFR. You can relax the IXFR query validation check by enabling this feature.
  
  

nrcmd> dns enable relax-ixfr-query-validation 
 

Enabling NOTIFY

NOTIFY (described in RFC 1996) enables the Network Registrar DNS primary server to inform its secondary servers that changes occurred to its zones. The changes are not indicated in the NOTIFY packet, just that changes were made. The secondary server then initiates a zone transfer request in response to the NOTIFY packet.

Because a master server for a zone does not know specifically which secondary server transfers from it, Network Registrar notifies all registered name servers for the zone (NS records) when the zone changes. The sole exception to this policy is that Network Registrar does not notify the server named in the SOA primary master field.

Use IXFR and NOTIFY in environments where the namespace is relatively dynamic.

Using the GUI:

On the Options tab of the DNS Server Properties dialog box, select the Enable NOTIFY check box to enable NOTIFY.

Using the CLI:

Use the dns enable notify command to send notification for all zones for which you have not configured specific behavior. By default, notify is enabled.

nrcmd> dns enable notify 
 

NOTIFY also notifies the servers you specify in the notify-set list. Use the zone set notify-set command to specify an optional comma-separated list of servers to notify.

nrcmd> zone example.com. set notify-set=1.1.1.1,2.2.2.2 
 

To see a list of servers that were set for notification, use the zone get notify-set command.

nrcmd> zone example.com. get notify-set