Table of Contents

Customizing DNS Zone and Server Parameters

This chapter explains how to configure some of the more advanced DNS zone and server parameters using the Network Registrar GUI and CLI. Before you proceed with the tasks in this chapter, read "Configuring DNS Servers," which explains how to set up the basic elements of a primary and secondary DNS server and its zones.

Table 6-1 describes the topics related to customizing DNS zones and servers.

Note   Remember to reload the DNS server after you make any changes to the configuration.

Setting the Zone's SOA Properties

The Start of Authority (SOA) record designates the top of the zone in the DNS inverted-tree namespace. There must 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) modified e-mail address
  
  
• Primary server name
  
  
• Serial number
  
  
• Secondary refresh time
  
  
• Secondary retry time
  
  
• Secondary expire time
  
  
• Minimum time to live
  
  

Using the GUI:

After adding a primary zone, you must first set the SOA record. Once created, you can edit all fields in the SOA except the Name and Serial Number fields. The serial number automatically increases with each server reload or a dynamic DNS update.

Use the following steps for each of the subsequent zone configuration sections:

Step 1   Select the primary zone whose SOA record you want to edit.

Step 2   Open the properties for the zone.

Step 3   In the Primary Zone dialog box, select the SOA tab (Figure 6-1).

Step 4   Make appropriate changes to the editable fields.

Step 5   Click OK.

Step 6   Reload the server.

Step 7   Observe the results.

Using the CLI:

Use the zone command to add or delete hosts from a zone, specify the authoritative servers for the zone, configure zones for dynamic DNS update, and edit individual resource records.

Viewing the Zone's Domain Name

Once you create a zone, its domain name becomes fixed and you cannot edit it unless you delete the zone.

Using the GUI:

In the Primary Zone dialog box, select the SOA tab (Figure 6-1). The Name field displays the name of the zone you specified when you created the zone.

Using the CLI:

Use the zone list command to list the zones administered by Network Registrar, including the zone's domain name and all its attributes. To list just the zone names, use the zone listnames command.

nrcmd> zone list 
nrcmd> zone listnames 
 

Setting the SOA Time to Live

You usually set the time to live (TTL) for the SOA record through the default TTL for the zone. However, you can explicitly set the TTL for the SOA record only, which sets the maximum number of seconds the server can cache the SOA record data. For example, if the TTL is set for 3600 seconds (one hour), an external server must remove the SOA record from its cache after an hour and must query your name server again.

You can set the SOA TTL in the GUI or CLI. You need to use the CLI to set the default TTL. The preset default TTL is 86400 seconds (one day).

Using the GUI:

From the SOA tab of the Primary Zone dialog box, enter an appropriate value, in seconds, in the TTL field (Figure 6-1). The minus sign (the default) indicates to use the default TTL value.

Using the CLI:

To set the default TTL value, use the zone set defttl command. Use the zone addRR SOA command to set the TTL for the SOA record only. If you want to change the TTL value for an existing SOA record, you must remove the SOA record and then add it back. Insert the TTL value before the class value (IN) and re-enter the remaining data, then reload the server.

nrcmd> zone example.com. set defttl=172800 
nrcmd> zone example.com. removeRR @ SOA 
101 Ok, with warnings
Warning: removing SOA record
removing @ IN SOA ns.example.com. hostmaster.example.com. 1 10800 3600 604800 172800
 
nrcmd> zone example.com. addRR @ 172800 IN SOA ns hostmaster 1 10800 3600 604800 86400 
100 Ok
@ 1600 IN SOA ns.example.com. hostmaster.example.com. 1 10800 3600 604800 86400
 
nrcmd> server dns reload 
 

Setting the Hostmaster's E-mail Address

You can use an actual e-mail address or use an alias (such as hostmaster) for the person in charge of the SOA record. In either case, it must be a valid e-mail address for someone who can handle potential problems. The hostmaster does not necessarily have to be in the same network or zone.

Using the GUI:

On the SOA tab, use the Contact email address field to specify the e-mail address of the person in charge of the name server. Remember to use a dot instead of @ as a separator, and to include a backslash before any dots in text that precedes the @ in the usual e-mail address syntax.

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.)"

Using the CLI:

When you create a zone, you must supply the e-mail of the person in charge. To find out who the current person is, use the zone get person command first. To change the name, use the zone set person command.

nrcmd> zone example.com. get person 
100 Ok
person=hostmaster.example.com.
 
nrcmd> zone example.com. set person=hostmaster2 
100 Ok
person=hostmaster2.example.com.
nrcmd> server dns reload 
 

Setting the Name of the Primary Server

Like the hostmaster information, the primary server you specify in the SOA record is for the benefit of the outside world. You can use a relative domain name or FQDN that is resolvable into an IP address, but you cannot specify an IP address.

Using the GUI:

On the SOA tab (Figure 6-1), use the Name of primary server field to specify the name of the server you are configuring. You can use the host name and Network Registrar adds the rest of the domain specification (the origin), or you can use the FQDN with a trailing dot.

Using the CLI:

You usually set the primary server for the zone when you configure the zone by using the zone create primary command. However, you can change the name by using the zone set ns command.

nrcmd> zone example.com. get ns 
nrcmd> zone example.com. set ns=dnsserv 
nrcmd> server dns reload 
 

About SOA Serial Numbers

A primary server uses a serial number to indicate when its database has changed. Secondary servers check this serial number to determine whether they must update their zone data. You can enter a serial number only the first time you configure a zone. Thereafter, Network Registrar increments the serial number every time there is a change to the database.

You cannot edit an incremented serial number. Also, you cannot decrement a serial number. Secondary servers assume that a higher serial number is more current. You can use any integer, although the current date (omitting any punctuation marks) may be a better indicator.

Using the GUI:

You can indicate a serial number only when you create a new primary zone. On the SOA tab (Figure 6-1), use the Serial Number field to give an initial serial number for the SOA record. For example, you can use the current date (in reverse order) and two-digit number: YYMMDDnn. This value is incremented by one the next time the record is updated, which triggers a zone transfer. You cannot manually update the serial number after you initially create the zone.

Using the CLI:

You must create the zone first, then specify the serial number when you supply the zone properties. Use the zone set serial command. Use the current date as a start. You cannot modify this serial number once you create it. To retrieve the serial number, use the zone get serial command.

nrcmd> zone example.com. create primary ns hostmaster 
nrcmd> zone example.com. set serial=20000707 
nrcmd> server dns reload 
nrcmd> zone example.com. get serial 
serial=20000707
 

Setting the Secondary Refresh Time

The secondary refresh time is how often a secondary name server checks the primary server for an update. A good value is from one hour to one day, depending on how often you expect to change zone data.

If you use NOTIFY, you can set the refresh time to a larger value without causing long delays between transfers, because NOTIFY forces the secondary servers to notice when the primary data changes. For details about NOTIFY, see the "Enabling NOTIFY" section.

Using the GUI:

On the SOA tab (Figure 6-1), use the Secondary refresh time field to specify the amount of time in seconds.

Using the CLI:

Use the zone set refresh command to set or change the secondary refresh time. The default is 10800 seconds.

nrcmd> zone example.com. set refresh=3600 
 

Setting the Secondary Retry Time

The Network Registrar DNS server uses the secondary retry time between successive failures when checking for an update. If the refresh interval expires and an attempt to poll for an update fails, the server continues to retry until it succeeds. A good value is between one-third and one-tenth of the refresh time.

Using the GUI:

On the SOA tab (Figure 6-1), use the Secondary retry time field to specify the value in seconds.

Using the CLI:

Use the zone set retry command to specify the secondary retry time. The default is 3600 seconds.

nrcmd> zone example.com. set retry=4800 
 

Setting the Secondary Expiration Time

The secondary expiration time is the longest amount of time that a secondary name server can claim authority for zone data when responding to queries after it cannot update a zone. Set this to a large number that provides enough time to survive extended primary server failure, such as a week or more. The default is 604800 seconds.

Using the GUI:

On the SOA tab (Figure 6-1), use the Secondary expire time field to specify the value in seconds.

Using the CLI:

Use the zone set expire command to specify the expiration interval.

nrcmd> zone example.com. set expire=500000 
 

Setting the Authoritative Name Servers

The name servers that you enter must match those specified in the parent domain's delegation for this zone. You can configure the servers as primary or secondary, and you can set TTLs for zone transfers. These servers become the Name Server (NS) resource records for the zone. An Address (A) record needs to exist for each NS record as well (see the "Configuring Hosts in a Zone" section).

Follow these procedures to add an authoritative name server for a zone.

Using the GUI:

Step 1   In the Primary Zone dialog box, click the Name Servers tab (Figure 6-2).

Step 2   Click Add. The Add Name Server dialog box appears (Figure 6-3).

Step 3   Enter the server name. It is recommended that you enter at least the primary name server (or its alias) entered on the SOA tab, along with any secondary servers. Be careful to enter just the host name (without a trailing dot) or the FQDN (with the trailing dot).

Step 4   Click OK.

Step 5   In the Primary Zone dialog box, set the TTL for the servers. The TTL is the shortest time to live for all the NS records in the authoritative server list. If you change it, you change the TTL value for all the NS records in the authoritative server list. The default is a dash (-), which indicates that the Minimum TTL for the zone's SOA record is used, whose default is 86400 seconds.

Step 6   Click OK.

Step 7   To remove an authoritative server, select the name, then click the Remove button.

Step 8   You must add an Address (A) record for each of these servers. Go the "Configuring Hosts in a Zone" section to read about adding a host in the zone for the name server.

Using the CLI:

The zone addRR ns command adds the Name Server (NS) resource record for each authoritative name server. Be sure to reload the server. The following example includes the TTL specification for the NS record.

nrcmd> zone example.com. addRR @ 86400 ns ns1.example.com 
 

(See the "Configuring Hosts in a Zone" section for adding a host record for each of these NS records.)

The zone removeRR command removes the specified static resource record. You can specify a resource record by name; name and type; or name, type, and data (in which the specified data is in BIND-style format).

nrcmd> zone example.com. removeRR @ ns ns1.example.com 
 

Configuring Hosts in a Zone

Configuring hosts adds Address (A) resource records for the servers and hosts in the zone. As indicated in the "Setting the Authoritative Name Servers" section, you must create an A record for each NS record in the zone.

Adding Address Records

Use the following procedure to add A records for your zone.

Using the GUI:

Step 1   In the Primary Zone dialog box, click the Hosts tab (Figure 6-4).

Step 2   Click the Add button.

Step 3   In the Add Host dialog box (Figure 6-5), enter the required host name and its addresses, any alias names you might want the host known under, any Mail Exchanger (MX) records, and whether you want to have Network Registrar automatically generate reverse mapping records for an existing reverse zone.

If you add an alias for the A record host, this creates a Canonical Name (CNAME) record for the host. When presented with a host with an alias name, the name tries to resolve that name as an A record, and if not found, checks whether there is a CNAME record that maps the alias to its canonical ("actual") name, then tries to resolve that name. Consequently, be sure that any alias name you enter in the Aliases field for a host in the Name field is not itself an alias.

The MX records are for adding mail exchangers, other hosts that process or forward mail for the A record host. It is a good idea to have at least one MX record for every host. To set the routing priority of any mail forwarding, you can set a preference value for each of multiple MX records for the A host. You can set this in the Preference field to the right of each MX record Name field. The lower the number, the higher the preference, so that a value of 100 takes precedence over an MX assigned the number 200 (the numbers can be from 0 to 65535). After the mailer tries to contact the MX host with the lowest number and fails, it tries the MX host with the next highest preference value, and so on.

Step 4   Click OK to add this host, or click Apply to continue adding hosts.

After you click OK, Network Registrar returns to the Hosts tab of the Primary Zone dialog box and displays the new host or hosts.

Using the CLI:

Use the zone addHost command to add a host to a zone. Specify the host name and address, and optionally, any aliases (CNAME records). The alias in this example is bethssytem.

nrcmd> zone example.com. addHost bethpc 192.169.1.15 bethssystem 
 

To list the A record at this point, use the zone listHosts command.

nrcmd> zone example.com. listHosts 
 

The Mail Exchanger (MX) record specification for each host available using the GUI is not available from the zone addHost command. You must use the zone addRR MX command.

nrcmd> zone example.com. addRR @ MX 300 mailer3.example.com. 
 

Removing a Host

Removing a host removes all records associated with the host; these include aliases (CNAME), MX records, and if selected, reverse (PTR) records removed from the in-addr.arpa zone.

Using the GUI:

Step 1   On the Hosts tab (Figure 6-4), select the host name you want to remove.

Step 2   Click Remove. Network Registrar updates the host list to show the current hosts.

Using the CLI:

Use the zone removeHost command to remove a host from a zone.

nrcmd> zone example.com. removeHost bethpc 
 

Editing a Host

You can edit individual host data in a zone.

Using the GUI:

Step 1   On the Hosts tab (Figure 6-4), select the host name you want to edit.

Step 2   Click Edit.

Step 3   In the Edit Hosts dialog box, make the necessary changes to the host name, address, alias, or MX record.

Step 4   Click OK to effect the changes.

When you edit a host, the Generate reverse mapping records check box is selected if there is a reverse zone for any of the addresses associated with that host. In other words, if some addresses have corresponding reverse zones and others do not, the check box is selected.

If you click OK, Network Registrar displays a warning dialog box for each of the addresses that do not have a corresponding reverse zone. This is a normal result. Clicking OK to close these warning dialog boxes is not harmful and results in Network Registrar generating reverse mapping records only for those addresses for which corresponding reverse zones exist.

Using the CLI:

To change host information, remove the host and add a new one. Use the zone removeHost command to delete the host, then the zone addHost command to add a new one.

nrcmd> zone example.com. removeHost bethpc 
nrcmd> zone example.com. addHost bethpc 192.169.1.20 
 

Enabling Zone Transfers

A secondary server periodically contacts the name servers from which it gets updates and obtains the zone data, if it changed. This action is called a zone transfer. The interval is defined in the server's SOA record as the secondary refresh time.

Note   You might want to turn off zone transfers temporarily while you are reconfiguring the site, or if you have no secondary servers.

Using the GUI:

Use the options on the Zone Transfers tab (Figure 6-6) to allow zone transfers to any server that requests zone data, restrict the servers you will allow to perform zone transfers, or prevent all zone transfers.

• To enable zone transfers from any secondary server, select the Do not restrict zone transfers check box.
  
  
• To restrict zone transfers, select the Restrict zone transfers to the following addresses check box, then enter the IP addresses of the secondary servers allowed to perform zone transfers.
  
  
• To disable zone transfers, select the Restrict zone transfers to the following addresses check box and leave the list of authorized secondary servers blank.
  
  

Restricting Zone Transfers

Use the restrict zone transfers feature either for security reasons or to reduce the load on the primary name server by restricting the servers you will allow to request a copy of the zone data.

Using the GUI:

Step 1   On the Zone Transfers tab (Figure 6-6), click Restrict zone transfers to the following addresses.

Step 2   Enter the addresses (host or network) of the servers that you allowed to perform zone transfers.

Step 3   Click OK.

Using the CLI:

Use the zone enable restrict-xfer command either for security reasons or to reduce the load on the primary name server by restricting the servers you will allow to request a copy of the zone data. The restrict-xfer option is disabled by default.

nrcmd> zone example.com. enable restrict-xfer 
 

Use the zone set restricted-set command to specify the (comma-separated) zones that can request zone transfers.

nrcmd> zone example.com. set restricted-set=198.162.1.30,192.168.1.20 
 

Disabling Zone Transfers

Use the disable zone transfers feature either for security reasons or to reduce the load on your primary name server by preventing servers from requesting a copy of your zone data. The only way to totally disable zone transfers is to restrict them to a null set of addresses.

Using the GUI:

Step 1   On the Zone Transfers tab, click Restrict zone transfers to the following addresses.

Step 2   Leave the address list blank.

Step 3   Click OK.

Using the CLI:

Use the zone disable restrict-xfer command either for security reasons or to reduce the load on your primary name server by preventing servers from requesting a copy of your zone data.

Use the zone enable restrict-xfer command to disable zone transfers, then use the zone set restricted-set command, setting it to a blank value.

nrcmd> zone example.com. enable restrict-xfer 
nrcmd> zone example.com. set restricted-set= 
 

Enabling Dynamic DNS Updates

Dynamic DNS (RFC 2136) allows the integration of DNS and DHCP so that they can work together. DHCP centralizes and automates the configuration of IP hosts, including IP addresses, while dynamic DNS update automatically records the association between the IP hosts and their DHCP-assigned addresses.

Using DHCP and dynamic DNS update, a host is automatically configured for network access whenever it attaches to the IP network. The host can be located and accessed using its permanent, unique DNS host name. Hosts configured using DHCP can move freely on a network without end user or administrator intervention.

Note   For dynamic DNS update to function properly, you must configure the corresponding DHCP scope. For details, see the "Configuring Dynamic DNS for a Scope" section.

Allowing Updates from DHCP Servers

You can allow updates from the DHCP servers.

Using the GUI:

Step 1   In the Primary Zone dialog box, click the DHCP tab (Figure 6-7).

Step 2   Select the Enable dynamic DNS updates check box.

Step 3   Enter the addresses of the DHCP servers from which DNS allows updates to this zone.

If you do not list a DHCP server, the update does not occur. You must do this for both the forward and reverse zones.

Step 4   Click OK.

Using the CLI:

Use the zone enable dynamic command to enable dynamic updates to the zone. The dynamic property is enabled by default.

nrcmd> zone example.com. enable dynamic 
 

Use the zone set dynupdate-set command to specify the (comma-separated) list of IP addresses from which dynamic updates will be accepted.

nrcmd> zone example.com. set dynupdate-set=192.168.1.1,127.0.0.1 
 

Adding Subzones

As the zone grows, you might want to divide it into smaller pieces called subzones. You might want to delegate administrative authority for these subzones, and have them managed by people within those zones or served by separate servers. This partitioning is called subzone delegation. Establish subzone delegation by performing the following tasks:

• Choose a subzone name
  
  
• Specify a name server name
  
  
• Specify a name server address
  
  

Choosing a Subzone Name

After you decide to divide the zone into subzones, you must create names for them. You should involve the people responsible for the subzone in the naming, and you should try to maintain a consistent naming scheme that makes sense to people outside your organization.

The following are some suggestions for how to avoid naming problems:

• Consider not naming a subzone based on its organizational name, because in a changing business environment, organizations merge and are renamed. Naming a subzone after an organization could result in a name that over time is no longer meaningful.
  
  
• Consider not using geographical names that indicate the subzone location. Names based on geographical location are meaningless to people outside your organization.
  
  
• Do not use cryptic names. Do not choose two-letter names for convenience. Make names obvious.
  
  
• Do not use existing or reserved top-level domain names as subzones. Using existing names can possibly result in incorrect routing problems.
  
  

In choosing a name, keep in mind how often people must remember the name, and how often they use it. Select a name that is easy to remember and easy to spell.

Specifying a Subzone Name Server

After you choose a name for the subzone, you must specify the hosts that are the subzone's name servers. The information you specify here is what the parent domain's name servers use when queried about the subzone. If you want to ensure that the subzone is always reachable, you should specify two name servers.

These name servers must be configured to be authoritative for this zone as either primary or secondary, otherwise you will have lame delegation. Lame delegation occurs when DNS servers listed in the parent's delegation of a zone do not know they are authoritative for the zone.

Specifying the Name Server Address

Whenever a name server for a subzone changes its name or IP address, the subzone administrator must inform its parent zone so that the zone administrator can change the name server and glue records for the subzone. A glue record is an A record that gives the address of a subzone's authoritative name server. If the subzone's administrator neglects to inform its parent, the glue records are invalid. The common symptom of an invalid glue record is that a host cannot reach a host in a different domain by its domain name while being able to reach it by its IP address.

Delegating a Subzone

If the name server for the subzone is in the parent domain, add a Name Server (NS) record. If the name server is within the subzone being delegated, you must add a NS record and a glue A record so that the domain can find the name server.

Using the GUI:

Step 1   In the Server Manager window, select the zone that you want to subdelegate and click Show Properties.

Step 2   In the Primary Zone dialog box, click the Subzones tab (Figure 6-8).

Step 3   Click Add. The Add Subzones dialog box appears (Figure 6-9).

Step 4   In the Add Subzone dialog box, enter the name of the subzone, for example, enter north.example.com. if the zone name is example.com.

Step 5   Click Add Name Server.

Step 6   In the Add Name Server dialog box, enter the fully qualified domain name (FQDN) of the name servers for this subzone.

Step 7   Click OK.

Step 8   If the name server is with the subzone, click the Add glue record button.

Step 9   In the Edit Glue Record dialog box, enter the IP address for the selected name server listed in step 6.

If you specified several name servers that require glue records, select each one individually and then specify its corresponding glue record.

Step 10   Click OK.

Step 11   Click OK again. To see the delegation records for the subzone you created, go to the Resource Records tab and look for the NS record for the subzone and the A record for the glue record.

Using the CLI:

Use the zone addRR NS and zone addRR A commands to delegate a subzone and add NS and A records.

nrcmd> zone example.com. addRR eng NS north.example.com. 
nrcmd> zone example.com. addRR north A 192.168.1.5 
 

Removing a Delegated Subzone

If you remove a subzone, remember to remove any associated glue records.

Using the GUI:

Step 1   On the Subzones tab (Figure 6-8), select the delegation you want to delete.

Step 2   Click Remove.

Step 3   Click OK to return to the Server Manager window.

Using the CLI:

Use the zone removeRR NS and zone removeRR A commands to remove the subzone's NS and A records.

nrcmd> zone example.com. removeRR @ NS 
nrcmd> zone example.com. removeRR north A 
 

Editing a Delegated Subzone

You can edit the subzone's resource records to change the subzone's information.

Using the GUI:

Step 1   On the Subzones tab (Figure 6-8), select the delegation you want to edit.

Step 2   Click Edit.

Step 3   In the Edit Name Server dialog box, click any name server or glue record button and make the necessary changes.

Step 4   Click OK.

Step 5   Click OK.

Step 6   To see the changes you made, click the Resource Records tab (Figure 6-10).

Using the CLI:

Use the zone removeRR command to delete the subzone, then use the zone addRR command to add the new one.

nrcmd> zone example.com. removeRR @ NS 
nrcmd> zone example.com. removeRR north A 
nrcmd> zone example.com. addRR ns.cs-eng ns cs-eng.example.com. 
nrcmd> zone example.com. addRR ns.cs-eng A 5.6.7.8 
 

Configuring Resource Records

This section describes how to add, remove, edit, and filter resource records.

Adding Resource Records

If the domain name you specify in the resource records does not have a trailing dot, Network Registrar considers the data to be relative to the current domain. Because Network Registrar stores all names as fully qualified domain names, it will append the current domain name to this name. Remember to specify a trailing dot if you specify the FQDN. (See "Resource Records.")

Using the GUI:

Unlike the Hosts tab (Figure 6-4), edits that you make on the Resource Records tab (Figure 6-10) affect only the resource record you are modifying and not any associated records. For example, If you delete an A record, Network Registrar does not delete any of the corresponding CNAME, MX, or PTR records.

Step 1   In the Server Manager window, select the zone to which you want to add resource records.

Step 2   Click the Show Properties toolbar button.

Step 3   In the Primary Zone dialog box, click the Resource Records tab (Figure 6-10).

Step 4   Click Add. This opens the Add Resource Record dialog box.

Step 5   Click the appropriate resource record tab: Generic, A, CNAME, MX, NS, or PTR. If you select Generic, you must select the resource record type in the Type field.

Step 6   Enter the name, optional TTL value, and the remaining data appropriate to the resource record type. For example, for an MX record, enter the preference and mail host name.

Step 7   Click Apply to continue to add resource records, or click OK to finish.

Using the CLI:

Use the zone addRR command to add a resource record of the type you specify. You can specify the name as either the relative name (if the server is within the same domain), as an absolute name (by supplying the FQDN), or the same name as the zone name (by using the @ symbol).

nrcmd> zone example.com. addRR ftp CNAME green.example.com. 
nrcmd> zone example.com. addRR @ NS ns.example.com. 
 

Removing Resource Records

You can remove resource records for a zone.

Using the GUI:

Step 1   On the Resource Records tab (Figure 6-10), click the name of the record you want to remove.

Step 2   Click Remove.

Using the CLI:

Use zone removeRR command to remove all specified static resource records. You can specify resource records by name, name and type, or name, type, and data (in which the specified data is in BIND-style format). Use the zone removeRR command to clear the list of servers so that you can specify new servers.

nrcmd> zone example.com. removeRR @ ns 

Caution   If you omit the data part of the resource record, Network Registrar removes all records of the specified type for the specified name.

Removing Dynamic Records

The DNS server must be running to remove dynamic records. Changes take effect immediately; you do not need to reload the server. You can remove specified dynamic records only by using the CLI.

Using the CLI:

Use the zone RemoveDynRR command to remove all specified dynamic resource records. You can specify resource records just by name, or by name and type. To determine whether dynamic DNS is working and what dynamic entries are in the system, see the "Filtering Records" section.

nrcmd> zone example.com. removeDynRR bob A 
 

Listing Records

You can display all of the resource records, or just the static or the dynamic ones. You can only use the CLI to do this.

Using the CLI:

The zone listRR command displays resource records in the named zone.

nrcmd> zone QuickExample.com. listRR 
 

Filtering Records

You may want to filter records to display only one type of record, such as an A record or a PTR record.

Using the GUI:

Step 1   On the Resource Records tab (Figure 6-10), select the record type you want to display from the Display only list box.

Step 2   Click the Filter records button.

Using the CLI:

You can use the following switches to filter records. This helps you determine whether dynamic DNS is working and what dynamic entries are in the system.

• All—Displays all records (this is the default)
  
  
• Static—Displays only static records
  
  
• Dynamic—Displays only dynamic records
  
  

The following example displays only dynamic records.

nrcmd> zone example.com. listRR dynamic 
 

Removing Zone Records After Deleting a Zone

You can delete leftover zone records after you delete a zone. You can do so only by using the CLI.

Using the CLI:

Use the zone cleanRR command if you periodically delete and re-import zones, which can cause your database to grow It uses the DNS server's historical zone data to determine what part of this data can be removed.

nrcmd> zone example.com. cleanRR 
 

The cleanRR command does not print out a list of records to be deleted or prompt you for confirmation. You can safely run it at any time.

Setting Advanced Server Options

You can set the following advanced server options:

• Prefetch glue records
  
  
• Report lame delegation
  
  
• Enable relaxed dynamic update
  
  
• Set cache time limits and size
  
  
• Set local and external port numbers
  
  
• Set debug
  
  
• Rebuild resource record indexes
  
  

All of the steps in the following subsections require you to be on the Advanced tab of the DNS Server Properties dialog box (Figure 6-11).

Prefetching Glue Records

A glue record is a DNS A (address) record that specifies the address of a subdomain's authoritative name server. They are informational records that are included in a response to a query. For example, most answers include NS records, which then cause the inclusion of A records to resolve the NS record name into an address. These A records are the glue records. Selecting the Prefetch glue records option tells the server to find records it would not normally find, so it can include them in answers to subsequent queries.

Using the GUI:

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), be sure the Prefetch glue records check box is selected. This option is enabled by default.

Using the CLI:

Use the dns disable no-fetch-glue command to enable prefetching glue records (the default).

nrcmd> dns disable no-fetch-glue 
 

Reporting Lame Delegation

Lame delegation occurs when a DNS server listed in the parent's delegation of a zone does not know that it is authoritative for the zone. The server can detect and report this when, in the process of tracking down an answer, it is referred to a server that in turn refers it to another server for a domain closer to the root (actually farther from the answer).

Note   Lame delegation does not indicate a problem with the DNS configuration, but with the configuration at the DNS server you are querying. You cannot do anything to correct lame delegation at other domains.

Using the GUI:

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), be sure the Report lame delegation check box is selected (the default).

Using the CLI:

Use the dns enable lame-deleg-notify command to enable lame delegation notification (the default).

nrcmd> dns enable lame-deleg-notify 
 

Enabling Relaxed Dynamic Update

You can choose to enable relaxing of the RFC 2136 restriction on the dynamic update zone name record. This feature allows the name to be any name within an authoritative zone.

Using the GUI:

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), select the Enable relaxed dynamic update check box to enable this property (it is deselected by default).

Using the CLI:

Use the dns enable update-relax-zone-name command to enable relaxing the dynamic update name restriction (the default is disable).

nrcmd> dns enable update-relax-zone-name 
 

Setting Negative Cache Time

To ensure a quick response to repeated requests for the same information, the DNS server maintains a cache of information it learns from other DNS servers on behalf of its DNS clients. It also remembers negative information, such as "no such name" or "no such data," that it learns in the same way. It is important to discard this information at some point to accommodate changes that may occur at the authoritative source. Positive information the server learns is always accompanied by a TTL parameter indicating how long it may be considered valid. This is not the case with negative information.

The value of the negative cache time represents the length of time negative information is considered valid. The negative cache time should be relatively short. In this way, the server can respond to creating new data at the authoritative source. However, the cache time should be long enough to serve some value to other clients looking for the same nonexistent information, or retries from a single client. The default negative cache time value is 600 seconds (10 minutes).

Using the GUI:

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), enter the Negative cache time value, in seconds.

Using the CLI:

Use the dns set neg-cache-ttl command to set the negative cache time (the default is 10 minutes).

nrcmd> dns set neg-cache-ttl=5m 
 

Setting Maximum Cache TTL

The Maximum Cache TTL option lets you specify the maximum amount of time you want Network Registrar to retain cached information. TTL is the amount of time that any name server is allowed to cache data learned from other name servers. Each record added to the cache arrives with some TTL value. When the TTL period expires, the name server must discard the cached data and get new data from the authoritative name servers the next time information is queried. This parameter limits the lifetime of records in the cache whose TTL values are very large. The default value is 7 days (604800 seconds).

Using the GUI:

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), enter the Max. cache TTL value, in seconds.

Using the CLI:

Use the dns set max-cache-ttl command to set the maximum cache TTL value (the default is 7 days).

nrcmd> dns set max-cache-ttl=5d 
 

Setting Maximum Memory Cache Size

The Maximum Memory Cache Size option lets you specify how much memory space you want to reserve for the DNS name cache. The more memory allocated for the cache, the less frequently the server uses disk cache. The default is 200 KB. One entry is approximately 100 bytes.

Using the GUI:

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), enter the Max. memory cache size value, in kilobytes.

Using the CLI:

Use the dns set mem-cache-size command to set the maximum memory cache size. The default is 200 kilobytes.

nrcmd> dns set mem-cache-size=100 
 

Flushing the DNS Cache

The Network Registrar cache flushing function lets you stop the disk cache file from growing. However, the actual behavior depends on whether the DNS server is running or stopped.

If you flush the cache while the server is running, Network Registrar clears all expendable entries from the cache database file. Flushing the cache does not cause the file to shrink in size because of the nature of the database, but does create free space within it. Because the memory cache is unaffected by this operation, recently used cache entries are not lost, and performance is not significantly affected.

If you flush the cache when the server is stopped, Network Registrar interprets the request to flush all entries, and removes the cache database file. Network Registrar re-initializes the database when you restart the server.

Note   If you added a host and want to look for it by using a query tool, such as nslookup, you may need to flush the cache on the other servers (but not on the server where it was added or on a secondary for the zone) to clear previously cached negative information.

Using the GUI:

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), click the Flush now button to stop the disk cache from growing. The actual behavior depends on whether your DNS server is running or stopped. To completely clear a cache that has grown too large, stop the server, and then click Flush now.

Using the CLI:

Use the dns flushCache command to stop the disk cache file from growing (the actual behavior depends on whether your DNS server is running or stopped).

nrcmd> dns flushCache 
 

Setting Local and External Port Numbers

If you experimented with a new group of name servers, you might want to use nonstandard ports for answering requests and for asking for remote information. The local port and external port settings control on which TCP and UDP port the server listens for name resolution requests, and to which port it connects when making requests to other name servers. The standard value for both is port 53.

In normal operation, if you change these values, the server will appear to be unavailable.

Using the GUI:

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), enter the Local port and External port values.

Using the CLI:

Use the dns set local-port-num and dns set remote-port-num commands to set the local and remote (external) port (the default is 53 for both).

nrcmd> dns set local-port-num=45 
nrcmd> dns set remote-port-num=40 
 

Enabling Debugging

The Debug option lets you collect debugging information about the DNS server. You should only need to set debug settings if you were instructed to do so by the Cisco Technical Assistance Center.

Note   Network Registrar disables debugging each time you reboot the DNS server. You must enable the debug setting again.

Using the GUI:

Step 1   On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), click the Debug settings button.

Step 2   In the Debug Settings dialog box, select the Enable Debug check box.

Step 3   Enter the category number as supplied by the Cisco Technical Assistance Center.

Step 4   Check the output destination:

• Console sends the output to the server console
  
  
• MLOG sends the output to the Network Registrar logging facility (the recommended choice)
  
  

Step 5   Click OK.

Using the CLI:

Use the server setDebug command to specify the debugging level. The following example provides extensive DNS logging.

nrcmd> server ns.example.com. setDebug D=5 
 

To turn off debugging without reloading your server, use the server unsetDebug command.

nrcmd> server ns.example.com. unsetDebug 
 

Rebuilding Resource Record Indexes

You may need to rebuild the resource record indexes if you observe resource or host list data that appears inconsistent or if data appears to be missing. Rebuilding the resource records should correct any inconsistencies.

Using the GUI:

Step 1   On the Advanced tab of the DNS Server Properties dialog box (Figure 6-11), click the Debug settings button.

Step 2   Click the Refresh Resource Record Indexes button.

Step 3   Be sure the Rebuild indexes for all zones now option is selected.

Step 4   Click OK.

Using the CLI:

Use the dns rebuildRR-Indexes command to rebuild the resource record indexes. Note that this removes any duplicate resource records it finds in the database. A subsequent reload may produce a diagnostic message that you can safely ignore.

nrcmd> dns rebuildRR-Indexes 
nrcmd> server dns reload 
101 OK, with warnings
Error Protocol Error removing record for name ...
while loading config changes.