Cisco CNS Network Registrar User's Guide, 5.5
Customizing DNS Zone and Server Parameters
Downloads: This chapterpdf (PDF - 304.0KB) The complete bookPDF (PDF - 5.45MB) | Feedback

Customizing DNS Zone and Server Parameters

Table Of Contents

Customizing DNS Zone and Server Parameters

Setting the Zone's SOA Properties

Viewing the Zone's Domain Name

Setting the SOA Time to Live

Setting the Hostmaster's E-mail Address

Setting the Name of the Primary Server

About SOA Serial Numbers

Setting the Secondary Refresh Time

Setting the Secondary Retry Time

Setting the Secondary Expiration Time

Configuring the Authoritative Name Servers

Configuring Hosts in a Zone

Adding Address, Canonical Name, and Mail Exchanger Records

Removing a Host

Editing a Host

Enabling Zone Transfers

Restricting Zone Transfers

Disabling Zone Transfers

Enabling Dynamic DNS Updates

Allowing Updates from DHCP Servers

Adding Subzones

Choosing a Subzone Name

Specifying a Subzone Name Server

Specifying the Name Server Address

Delegating a Subzone

Removing a Delegated Subzone

Editing a Delegated Subzone

Configuring Resource Records

Adding Resource Records

Removing Resource Records

Removing Dynamic Records

Listing Records

Filtering Records

Deleting Leftover Zone Records After Recreating a Zone

Using NAPTR Records

Setting Advanced Server Properties

Prefetching Glue Records

Reporting Lame Delegation

Enabling Relaxed Dynamic Update

Setting Negative Cache Time

Setting Maximum Cache TTL

Setting Maximum Memory Cache Size

Flushing the DNS Cache

Handling Rogue Address Records and Other Cache Attributes

Setting Local and External Port Numbers

Rebuilding Resource Record Indexes


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 CLI and GUI. Before you proceed with the tasks in this chapter, read Chapter 5, "Configuring DNS Servers," which explains how to set up the basic properties of a primary and secondary DNS server and its zones.

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

Table 6-1 DNS Zone Configuration Topics 

If you want to...
Go to the...

Configure the zones for a primary name server

"Configuring a Primary Name Server" section on page 5-1

Set a zone's Start of Authority (SOA) record properties

"Setting the Zone's SOA Properties" section

Set a zone's authoritative servers

"Configuring the Authoritative Name Servers" section

Add, edit, or remove hosts in a zone

"Configuring Hosts in a Zone" section

Enable, disable, or restrict zone transfers

"Enabling Zone Transfers" section

Enable dynamic DNS updates for DHCP servers

"Enabling Dynamic DNS Updates" section

Add, edit, delegate, or remove subzones

"Adding Subzones" section

Edit a zone's resource records

"Configuring Resource Records" section

Set the more advance server options, such as adjusting cache

"Setting Advanced Server Properties" section



Note 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. A zone can have only one SOA record, which sets the following properties for the primary zone:

Time to live

Hostmaster, or person in charge

Primary server name

Serial number

Secondary refresh time

Secondary retry time

Secondary expire time

Minimum time to live

Using the CLI

Use the zone command for zone configuration, as described in this chapter.

Using the GUI

Adding a primary zone creates an SOA record. You can then edit all its fields except Name and Serial Number. 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 In the Primary Zone dialog box, click the SOA tab (Figure 6-1).

Figure 6-1 SOA Tab (Primary Zone Properties Dialog Box)

Step 2 Make appropriate changes to the editable fields and click OK.

Step 3 Reload the server and observe the results.


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 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 

Using the GUI

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

Setting the SOA Time to Live

The SOA record's time to live (TTL) is usually determined by the zone's default TTL. However, you can explicitly set the SOA TTL, which sets the maximum number of seconds the server can cache the SOA record data. For example, if the SOA TTL is set for 3600 seconds (one hour), an external server must remove the SOA record from its cache after an hour and then 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 CLI

To set the default TTL value, use the zone name set defttl command. Use the zone name addRR SOA command to set the SOA TTL only. If you want to change this for an existing SOA record, you must remove and re-add the record using the zone name removeRR SOA command. 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 86400
nrcmd> zone example.com. addRR @ 172800 IN SOA ns hostmaster 1 10800 3600 604800 86400 
nrcmd> dns reload 

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.

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 CLI

When you create a zone, you must add the person in charge. To find out who this is, use the zone name get person command. To change the name, use the zone name 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> dns reload 

Using the GUI

On the SOA tab (Figure 6-1), use the "Contact email address" field to set the e-mail address of the person in charge of the name server. Remember to include a backslash before any dots in text that precede the "at" symbol @ in the usual e-mail address syntax, replace the symbol with a dot, and add a trailing dot.

Setting the Name of the Primary Server

Like the hostmaster, the primary server in the SOA record is informational only. You can use a relative domain name or an FQDN resolvable into an IP address.

Using the CLI

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

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

Using the GUI

On the SOA tab (Figure 6-1), use the "Name of primary server" field to add the primary server name. Enter a hostname (Network Registrar adds the origin domain), or enter the FQDN.

About SOA Serial Numbers

A primary server uses a serial number to indicate when its database changed. Any change to this serial number triggers a zone transfer. Network Registrar increments the serial number every time there is a change to the database. You can edit the serial number, but you cannot decrement it.

Secondary servers assume that a higher serial number is more current. You can use any integer.

Using the CLI

You must create the zone first, then specify the serial number when you supply the zone properties. Use the zone name set serial command.

nrcmd> zone example.com. create primary ns hostmaster 
nrcmd> zone example.com. set serial=1000 
nrcmd> dns reload 

Using the GUI

On the SOA tab (Figure 6-1), enter the SOA record's initial serial number in the "Serial Number" field.

Setting the Secondary Refresh Time

The secondary refresh time is how often a secondary server communicates with its primary regarding an update. A good range is from an hour to a 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 on page 5-22.

Using the CLI

Use the zone name set refresh command to set or change the secondary refresh time. The default is 10800 seconds (three hours).

nrcmd> zone example.com. set refresh=3600 

Using the GUI

On the SOA tab (Figure 6-1), enter a value, in seconds, in the "Secondary refresh time" field.

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. The default is 3600 seconds (one hour).

Using the CLI

Use the zone name set retry command to specify the secondary retry time.

nrcmd> zone example.com. set retry=4800 

Using the GUI

On the SOA tab (Figure 6-1), enter a value, in seconds, in the "Secondary retry time" field.

Setting the Secondary Expiration Time

The secondary expiration time is the longest time a secondary 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. The default is 604800 seconds (seven days).

Using the CLI:

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

nrcmd> zone example.com. set expire=500000 

Using the GUI:

On the SOA tab (Figure 6-1), enter a value, in seconds, in the "Secondary expire time" field.

Configuring 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. These servers become the 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.

Using the CLI

The zone name addRR ns command adds the 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 
nrcmd> dns reload 

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

The zone name removeRR command removes a 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 format.

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

Using the GUI


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

Figure 6-2 Name Servers Tab (DNS Zone Properties Dialog Box)

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

Figure 6-3 Add Name Server Dialog Box (Primary Zone Properties)

Step 3 Enter the server name. You should enter at least the primary name server (or its alias) name that appears on the SOA tab, along with any secondary server names. Be careful to enter just the hostname, 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 (one day).

Step 6 To remove an authoritative server, choose the name, then click Remove.

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

Step 8 Click OK to close the Primary Zone dialog box.


Configuring Hosts in a Zone

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

Adding Address, Canonical Name, and Mail Exchanger Records

Use the following procedure to add A, CNAME, and MX records for your zone.


Tip You cannot create a CNAME record with the same name as another resource record.


Using the CLI

Use the zone name addHost command to add a host to a zone. Specify the hostname and address, and optionally, any aliases (CNAME records). To list the A record, use the zone name listHosts command. To add Mail Exchanger (MX) records, use the zone name addRR MX command.

nrcmd> zone example.com. addHost bethpc 192.169.1.15 bethssystem 
nrcmd> zone example.com. listHosts 
nrcmd> zone example.com. addRR @ MX 300 mailer3.example.com. 

Using the GUI


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

Figure 6-4 Hosts Tab (Primary Zone Dialog Box)

Step 2 In the Add Host dialog box (Figure 5-6 on page 5-8):

a. Enter the required hostname and its addresses.

b. Enter any aliases you might want the host known under, which creates a Canonical Name (CNAME) record for the host. The server tries to resolve an alias to an A record, and if not found, looks for a CNAME record that maps the alias to its canonical (actual) name, then tries to resolve that name. Thus, be sure that any alias name you enter for a host in the Name field is not itself an alias.

c. Enter any Mail Exchanger (MX) records that add mail exchangers, other hosts that process or forward mail for the A record host. Have at least one MX record for every host.

For multiple MX records, you can set their routing preference value in the Preference field next to each Name field. The lower the number, the higher the preference, so that a server with a 100 value takes precedence over one with a 200 value (the range 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 higher preference value, and so on.

d. Check the "Generate reverse mapping records" box if you want Network Registrar to generate reverse mapping records automatically for an existing reverse zone.

Step 3 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.


Removing a Host

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

Using the CLI

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

nrcmd> zone example.com. removeHost bethpc 

Using the GUI

On the Hosts tab (Figure 6-4), choose the hostname that you want to remove. Then click Remove. Network Registrar updates the host list to show the current hosts.

Editing a Host

You can edit individual host data in a zone.

Using the CLI

To change host information, you have to remove the host, using the zone name removeHost command, and re-add it, using the zone name addHost command.

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

Using the GUI

On the Hosts tab (Figure 6-4), choose the hostname you want to edit, and click Edit. In the Edit Hosts dialog box, make the necessary changes to the hostname, address, alias, or MX record. Then, click OK.

When you edit a host, the "Generate reverse mapping records" box is checked if there is a reverse zone for any of the host's addresses. If you click OK, Network Registrar displays a warning dialog box for each address not having a corresponding reverse zone. This is a normal result and not harmful.

Enabling Zone Transfers

A secondary server periodically contacts its primary for changes, called a zone transfer. The interval is defined in the server's SOA record as the secondary refresh time.

Using the CLI

Zone transfers are enabled in the CLI by default unless you restrict them using the zone name enable restrict-xfer command. See the "Restricting Zone Transfers" section. If you want to force a zone transfer, use the zone name forceXfer primary, or zone name forceXfer secondary command.

Using the GUI

Use the options on the Zone Transfers tab (Figure 6-5) to allow zone transfers to all servers requesting zone data, to restrict the servers, or prevent all zone transfers:

Enable zone transfers from any secondary by checking the "Do not restrict zone transfers" box.

Restrict zone transfers by checking the "Restrict zone transfers to the following addresses" box and entering the addresses of the secondary servers allowed to perform zone transfers.

Disable zone transfers entirely by checking the "Restrict zone transfers to the following addresses" box and leaving the list of authorized secondary servers blank. You might want to turn off zone transfers temporarily while you are reconfiguring the site, or if you have no secondary servers.

Figure 6-5 Zone Transfers Tab (Primary Zone Dialog Box)

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 that you will allow to request a copy of the zone data.

Using the CLI

Use the zone name enable restrict-xfer command either for security reasons or to reduce the load on the primary name server. The restrict-xfer option is disabled by default.

nrcmd> zone example.com. enable restrict-xfer 

Use the zone name 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 

Using the GUI

On the Zone Transfers tab (Figure 6-5), check "Restrict zone transfers to the following addresses" box. Then, enter the host or network addresses of the servers that you allowed to perform zone transfers. Finally, click OK.

Disabling Zone Transfers

Disable zone transfers either for security reasons or to reduce the load on the primary name server. The only way to totally disable zone transfers is to restrict them to a null set of addresses.

Using the CLI

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

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

Using the GUI

On the Zone Transfers tab, check "Restrict zone transfers to the following addresses" box. Leave the address list blank, then click OK.

Enabling Dynamic DNS Updates

Dynamic DNS (RFC 2136) integrates DNS and DHCP so that they can work together. Dynamic DNS update automatically records the association between the hosts and their DHCP-assigned addresses. Using DHCP and dynamic DNS update, you can configure a host automatically for network access whenever it attaches to the network. You can locate and access the host using its unique DNS hostname.

Dynamic DNS update is described more fully in Chapter 9, "Configuring Dynamic DNS Update." For dynamic DNS update to function properly, you must configure the corresponding DHCP scope.

Allowing Updates from DHCP Servers

You can allow DNS updates from certain DHCP servers.

Using the CLI:

Use the zone name enable dynamic command to enable dynamic updates to the zone. The dynamic property is enabled by default. Then use the zone name set dynupdate-set command to specify the (comma-separated) list of IP addresses from which dynamic updates will be accepted.

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

Using the GUI


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

Figure 6-6 DHCP Tab (Primary Zone Dialog Box)

Step 2 Check the "Enable dynamic DNS updates" 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.


Adding Subzones

As the zone grows, you might want to divide it into smaller pieces called subzones. You can 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. Involve the people responsible for the subzone in deciding the names, and try to maintain a consistent naming scheme.

The following suggestions can help you avoid subzone naming problems:

Consider not naming a subzone by its organizational name. In a changing business environment, organizations merge and are renamed. Naming a subzone after an organization could result in a name that is no longer meaningful over time.

Consider not using geographical names that indicate the subzone location. Geographical names are meaningless to people outside your organization.

Do not use cryptic names; make them obvious.

Do not use existing or reserved top-level domain names as subzones. Using existing names can result in routing problems.

Specifying a Subzone Name Server

After you choose a subzone name, specify its name servers, or what the parent domain's name servers use when queried about the subzone. To ensure that the subzone is always reachable, you should specify two name servers. They must be authoritative for this zone as either primary or secondary, or this causes lame delegation. See the "Reporting Lame Delegation" section.

Specifying the Name Server Address

Whenever a subzone's name server changes its name or address, the subzone administrator must inform its parent zone so that the latter's administrator can change the subzone's name server and glue records. A glue record is an A record with the address of a subzone's authoritative name server. If the subzone's administrator fails to inform its parent, the glue records are invalid. The common symptom is that a host cannot reach a host in another domain by its name, only by its address.

Delegating a Subzone

If the name server for the subzone is in the parent domain, add an NS record. If the server is in the subzone being delegated, add an NS record and a glue A record so that the domain can find it.

Using the CLI

Use the zone name addRR NS, and zone name addRR A commands to delegate a subzone.

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

Using the GUI


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

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

Figure 6-7 Subzones Tab (Primary Zone Dialog Box)

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

Figure 6-8 Add Subzone Dialog Box (from Subzones Tab)

Step 4 In the Add Subzone dialog box, enter the name of the subzone.

Step 5 Click Add Name Server.

Step 6 In the Add Name Server dialog box, enter the FQDNs of the name servers for this subzone.

Step 7 Click OK.

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

Step 9 In the Edit Glue Record dialog box, enter the IP address for the name server in Step 6. If you specified several name servers that require glue records, choose 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, click the Resource Records tab and look for the NS record for the subzone and the A record for the glue record.


Removing a Delegated Subzone

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

Using the CLI

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

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

Using the GUI

On the Subzones tab (Figure 6-7), choose the subzone delegation that you want to remove. Click Remove, then OK to return to the Server Manager window.

Editing a Delegated Subzone

You can edit the subzone's resource records.

Using the CLI

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

nrcmd> zone example.com. removeRR @ NS ns.example.com. 
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 

Using the GUI


Step 1 On the Subzones tab (Figure 6-7), choose the subzone delegation that you want to edit.

Step 2 Click Edit.

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

Step 4 Click OK.

Step 5 To see the changes, click the Resource Records tab (Figure 6-9).


Configuring Resource Records

Resource records comprise the data within a DNS zone. Although there is no fixed limit to the number of resource records a zone may own, in general, a zone may own one or more resource records of a given type, or none. There are some exceptions depending on the types involved.

All resource records have the following required entries:

Name—Name (host) that owns the record, such as example.com.

Class (not required for all formats)—DNS supports only the IN (Internet) class of record.

TTL (time to live)—Amount of time to store the record in cache, in seconds. If you do not include a TTL, Network Registrar uses the zone default TTL, defined in the SOA resource record.

Type—Type of the record, such as A, NS, SOA, and MX. There are many types that various RFCs define, although ten or fewer are in common use.

Record data—Data types whose format and meaning varies with record type.

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

Adding Resource Records

Unlike the Hosts tab (Figure 6-4), edits you make on the Resource Records tab (Figure 6-9) affect only the resource record you are modifying. If you delete an A record, Network Registrar does not delete any of the corresponding CNAME, MX, or PTR records. See Appendix A, "Resource Records" for a list of resource records that Network Registrar supports.

Using the CLI

Use the zone name addRR command to add a resource record of a certain type. 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 "at" symbol).

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

Using the GUI

You can add resource records for a zone.


Step 1 In the Server Manager window, choose the zone and click Show Properties on the toolbar.

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

Figure 6-9 Resource Records Tab (Primary Zone Dialog Box)

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

Step 4 Click the appropriate resource record tab—Generic, A, CNAME, MX, NS, or PTR. If you choose Generic, you must choose the resource record type in the Type field.

Step 5 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 hostname.

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


Removing Resource Records

You can remove resource records from a zone.

Using the CLI

Use zone name 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 name 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. Similarly, if you omit the type, Network Registrar removes all records for the specified name.

Using the GUI

On the Resource Records tab (Figure 6-9), click the name of the record that you want to remove, then click Remove.

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 name 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 the resource records, or just the static or the dynamic ones. You can only use the CLI to do this. The DNS server must be operating.

Using the CLI

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

nrcmd> zone example.com. listRR 

Filtering Records

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

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 (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 

Using the GUI

On the Resource Records tab (Figure 6-9), choose the record type you want to display from the "Display only" list box, then click Filter records.

Deleting Leftover Zone Records After Recreating a Zone

You can delete leftover zone records after you delete a zone and then recreate it.

Using the CLI

Use the zone name cleanRR command if you periodically delete and re-import zones, which can cause your database to grow. This command uses the DNS server's historical zone data to determine what part to remove. It does not print a list of records to be deleted or prompt you for confirmation. You can safely run it any time.

nrcmd> zone example.com. cleanRR 

Using NAPTR Records

Network Registrar supports Naming Authority Pointer (NAPTR) resource records. These records help with name resolution in a particular namespace and are processed to get to a resolution service. Since NAPTR records are a proposed standard, RFC 2915, Network Registrar only validates their numeric record fields. However, the proposed standard requires a value for each field, even if it is null (""), and there are no default values. See Appendix A, "Resource Records" for the syntax of NAPTR records.

When using a NAPTR record to locate a Session Initiation Protocol (SIP) proxy, see the proposed standard, RFC 2916, or the SIP standard, RFC 2543. In RFC 2916, the ENUM working group of the Internet Engineering Task Force specifies NAPTR records to map E.164 addresses to Universal Resource Identifiers (URIs). Using the NAPTR record resolves a name in the E.164 international public telecommunication namespace to a URI, instead of providing the name of a service to use as a resolver. The U flag was added to the NAPTR record for this purpose.

For example, to specify a SIP proxy for the phone number +4689761234, add a NAPTR record at the name "4.3.2.1.6.7.9.8.6.4.e164.arpa." with the following content.

100 10 "u" "sip+E2U" "/^.*$/sip:info@tele2.se/" .

This sets the following fields of the NAPTR record:

order = 100 
preference = 10 
flags = "u" 
service = "sip+E2U" 
regexp = "/^.*$/sip:info@tele2.se/" 
replacement = . 

After you configure these fields, the DNS client dealing with phone number +4689761234 can now find an SIP service URI by replacing the number with the "sip:info@tele2.se" string. The E.164 zone mostly uses the NAPTR record for wholesale replacement of the "input" telephone number. Section 3.2.3 of RFC 2916 includes an example of one transformation to a Lightweight Directory Access Protocol (LDAP) query that preserves some of the digits. The E.164 zone does not map to server (SRV) records is that it wants to obtain a SIP URL that is more humanly readable to the left of the "at" (@) symbol.

Using the CLI

Use the zone name addRR command. Then, reload the server.

nrcmd> zone 8.6.4.e164.arpa addRR 4.3.2.1.6.7.9 naptr 100 10 u sip+E2U 
       /^.*$/sip:info@tele2.se/ . 
nrcmd> dns reload 

Using the GUI

Select the zone requiring the NAPTR record, open the Add Resource Record dialog box, and click the Generic tab. Add the owner of the NAPTR record, select NAPTR in the type field, and enter the six-field value—order, preference, flag, service, regular expression, and replacement string, separated by spaces—in the Data field. Then, reload the DNS server.

Setting Advanced Server Properties

You can set the following advanced server properties:

Prefetch glue records

Report lame delegation

Enable relaxed dynamic update

Set cache time limits and size

Set local and external port numbers

Handle rogue A record queries

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

Prefetching Glue Records

A glue record is a DNS A record that specifies the address of a subdomain's authoritative name server. It is an informational record in a query response. 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. Choosing the "Prefetch glue records" option tells the server to find records that it would not normally find, so that it can include them in answers to subsequent queries.

Using the CLI

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

nrcmd> dns disable no-fetch-glue 

Using the GUI

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-10), ensure that the "Prefetch glue records" box is checked (the default).

Figure 6-10 Advanced Tab (DNS Server Properties Dialog Box)

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 to another server for a domain closer to the root (actually farther from the answer). 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, unless you happen to be authoritative for the domain as well.

Using the CLI

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

nrcmd> dns enable lame-deleg-notify 

Using the GUI

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-10), ensure that the "Report lame delegation" box is checked (the default).

Enabling Relaxed Dynamic Update

You can choose to enable relaxing the RFC 2136 restriction on the dynamic update zone name record. This property allows the name to be any name in an authoritative zone. For details, see the "Configuring Dynamic DNS for a Scope" section on page 9-3.

Setting Negative Cache Time

To ensure a quick response to repeated requests for the same information, the DNS server maintains a cache of data it learns from other servers on behalf of its 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 CLI

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

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

Using the GUI

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

Setting Maximum Cache TTL

The Maximum Cache TTL property specifies the maximum time that 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 server must discard the cached data and get new data from the authoritative name servers the next time it sends a query. This parameter limits the lifetime of records in the cache whose TTL values are very large. The default value is seven days (604800 seconds).

Using the CLI

Use the dns set max-cache-ttl command to set the maximum cache TTL value.

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

Using the GUI

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

Setting Maximum Memory Cache Size

The maximum memory cache size property specifies how much memory space you want to reserve for the DNS memory cache. The more memory that you allocate for the cache, the less frequently the server uses disk cache. The default is 200 KB. One entry is approximately 100 bytes.

Using the CLI

Use the dns set mem-cache-size command to set the maximum memory cache size, in kilobytes.

nrcmd> dns set mem-cache-size=100 

Using the GUI

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

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 shrink the file because of the nature of the database, but does create free space in it. Because the memory cache is unaffected by this operation, recently used cache entries are not lost, and performance is not significantly affected.

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


Tip If you want to look for a host using a query tool such as nslookup, you also need to flush the in-memory cache by reloading and restarting the server.


Using the CLI

Use the dns flushCache command to stop the disk cache file from growing.

nrcmd> dns flushCache 

Using the GUI

On the Advanced tab of the DNS Server Properties dialog box (Figure 6-10), click Flush now to stop the disk cache from growing. Then click OK. To completely clear a cache that has grown too large, stop the server, then click Flush now.

Handling Rogue Address Records and Other Cache Attributes

You may become victim of a suspicious quality-of-service attack where a rogue host targets Address resource record queries to a caching DNS server. These A record queries contain names that resemble IP addresses. To avoid overloading the DNS server's cache.db file with negative responses from the root, the server no longer tries to resolve these queries. The fake-ip-name-response DNS attribute is enabled by default to effect this. When the server receives a query for a nonauthoritative name, it consults its memory cache and, if it cannot resolve the query there, queries its cache.db file. If the server cannot resolve the A record type query in either place, it parses the record value and, if the value resembles an IP address (four decimals each separated by a dot with no trailing or preceding characters), does not forward the query. Instead, the server responds with a NXDOMAIN status and does not include the negative respond in its caches.

The server acts on the save-negative-cache-entries and cache-write-ttl-threshold attributes when it evicts entries from its memory cache to the cache.db file. It typically evicts positive and negative query responses from in-memory cache when the cache is full and the server needs to inserts a new entry. The server evicts the least-recently-used entry. If you disable save-negative-cache-entries, the server does not store evicted negative entries in the cache.db file, but simply discards them. If the cache-write-ttl-threshold value is non-zero (it is zero by default), the server only persists entries from the in-memory cache to the cache.db file if the entry's TTLs are greater than this value. Otherwise, the server discards the (soon to be, but not yet expired) resource record.

Using the CLI

You can set the fake IP name response attribute and adjust the cache attributes to handle rogue A records.

nrcmd> dns enable fake-ip-name-response 
nrcmd> dns disable save-negative-cache-entries 

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 asking for remote data. The local port and external port settings control the TCP and UDP ports on which 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. If you change these values during normal operation, the server will appear to be unavailable.

Using the CLI

Use the dns set local-port-num, and dns set remote-port-num commands to set the ports.

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

Using the GUI

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

Rebuilding Resource Record Indexes

You may need to rebuild the resource record indexes if there are resource records that appear inconsistent or are missing. Rebuilding the resource records corrects any inconsistencies between what is cached in the user interface and the database. It has no effect on the database.

Using the CLI:

Use the dns rebuildRR-Indexes command to rebuild the resource record indexes.

nrcmd> dns rebuildRR-Indexes 
nrcmd> dns reload 

Using the GUI


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

Step 2 Click Refresh Resource Record Indexes.

Step 3 Ensure that the "Rebuild indexes for all zones now" option is checked.

Step 4 Click OK.