Cisco CNS Network Registrar User's Guide, 6.0
Configuring Dynamic DNS Update
Downloads: This chapterpdf (PDF - 388.0KB) The complete bookPDF (PDF - 7.06MB) | Feedback

Configuring Dynamic DNS Update

Table Of Contents

Configuring Dynamic DNS Update

Dynamic DNS Update Process

Confirming Dynamic Records

Changesets and Checkpointing

Configuring Dynamic DNS for a Scope

Configuring DNS Updates for Windows 2000 Clients

Settings in the Windows 2000 Client

Settings in the DHCP Server

Dual Zone Updates for Windows 2000 Clients

Enabling Dynamic Update on the DNS Server

Setting Advanced Dynamic DNS Update Properties

Setting the Number of DNS Packets

Setting the DNS Packet Size

Setting the Number of DNS Retries

Setting the Number of DNS Renaming Retries

Setting the DNS Request Timeout

Setting the Maximum DNS Record Time to Live

Scavenging Dynamic Records

Setting Transaction Security

Generating Random Keys

Guidelines for Generating Your Own Keys

Adding Keys

Configuring DHCP for Transaction Security

Creating Access Control Lists

Configuring the DNS Server or Zone for ACLs

Restrictions to TSIG Keys and ACLs

Troubleshooting Dynamic DNS Update


Configuring Dynamic DNS Update


Dynamic DNS update integrates DNS with DHCP. The two protocols are complementary—DHCP centralizes and automates IP address allocation, while dynamic DNS update automatically records the association between assigned addresses and hostnames. When you use DHCP and dynamic DNS update, this configures a host automatically for network access whenever it attaches to the IP network. You can locate and reach the host using its permanent, unique DNS host name. Mobile hosts, for example, can move freely without user or administrator intervention.

This chapter explains how to use dynamic DNS update with Cisco CNS Network Registrar servers using both the GUI and the CLI. Table 9-1 lists the dynamic DNS update configuration topics explained in this chapter and their associated sections. The Network Registrar Web UI Guide explains how to accomplish these tasks using the Web-based interface.

Table 9-1 Dynamic DNS Update Configuration Topics

If you want to...
See...

Know more about why you would configure dynamic DNS update

"Dynamic DNS Update Process" section

Configure dynamic DNS update for a scope

"Configuring Dynamic DNS for a Scope" section

Configure host name updates for Windows 2000 clients

"Configuring DNS Updates for Windows 2000 Clients" section

Enable dynamic DNS updates from hostnames

"Enabling Dynamic Update on the DNS Server" section

Change system defaults for advanced parameters

"Setting Advanced Dynamic DNS Update Properties" section

Setting TSIG transaction security

"Setting Transaction Security" section

Troubleshoot dynamic DNS update

"Troubleshooting Dynamic DNS Update" section


Dynamic DNS Update Process

To configure dynamic DNS update, you need to configure both a DHCP scope and a primary DNS zone, and supply hostnames. You can request that Network Registrar generate hostnames, or you can supply them. You can update only a primary DNS server that supports dynamic DNS update.

This is the process to configure dynamic DNS update:

1. Configure the DHCP scope for dynamic DNS update.

2. Configure the DNS zones to accept dynamic DNS updates.

3. Define advanced dynamic DNS update support. (You rarely need to modify the system defaults for the advanced parameters. However, they are described in the "Setting Advanced Dynamic DNS Update Properties" section for your reference.)

4. Reload the servers.

The remainder of this chapter describes each step in more detail.

Confirming Dynamic Records

Using the Web UI


Step 1 On the Primary Navigation bar, click the Zone tab. See the Network Registrar Web UI Guide for details.

Step 2 On the Secondary Navigation bar, click the Zones tab to open the List/Add Zones page.

Step 3 Click the View icon () in the Active Server RRs column to open the List/Add DNS Server Resource Records for Zone page.

Step 4 View the dynamic records.

Step 5 Click Return to Zone List.


Using the CLI

Dynamic DNS resource records do not appear in the GUI. If you want to confirm that the DNS update is working, enter the complete list of dynamic updates.

nrcmd> zone example.com. listRR dynamic 
100 Ok
Dynamic Resource Records

The Network Registrar DHCP server stores all pending DNS update data on disk. If DHCP cannot communicate with a particular DNS server, it periodically tests for re-established communication and submits all pending updates. This test typically occurs every 40 seconds.

Changesets and Checkpointing

Using the Web UI

This function is not currently available in the Web UI.

Using the CLI

Network Registrar maintains a changeset database to capture any dynamic changes to resource records in zones in a performance-enhanced way. It calls the changeset database when a server responds to external dynamic updates, full or incremental zone transfers, zone checkpointing, stale record scavenging, or incremental or full configuration database reloads. For scavenging, see the "Scavenging Dynamic Records" section. The changeset database is backed up during the usual mcdshadow backup (see the "Backing up CNRDB Data" section).

A changeset can range from a single resource record to many records. Dynamic DNS updates or incremental zone changes first go to a changeset update buffer that the server manages. Every ten-millisecond transaction interval (or 50000 changesets), the data is flushed from this buffer to a transaction log in the database. The changesets accumulate in the transaction log until they are committed to the database history file, every 20-second checkpoint interval. Each log file can be up to 10 MB in size and the files are trimmed every ten minutes after being committed.

The database file has one history list for each of the server's zones, and each entry in the list represents a change for that zone. (In the case of a full zone transfer, the history records only that the transfer occurred.) This committed data becomes the building blocks for outgoing incremental zone transfers. Every 30 seconds the database checks a certain small percent of the history for possible trimming in case it gets too big. As soon as the history reaches 2000 changesets, a zone checkpointing occurs, and the database trims the remaining history, except a maximum 400 changesets that it always keeps.


Note These property values are modifiable, under guidance. See the "Troubleshooting Dynamic DNS Update" section.


A zone checkpoint is different from the changeset checkpoint described earlier. Zone checkpointing saves a snapshot of the auth.db file to a flat data file and updates it with the newest changesets. In addition to occurring every 2000 changesets, a zone checkpoint occurs by default every three hours. You can adjust this interval, from between one and 168 hours, using the zone name set checkpoint-interval command. You would increase the zone checkpoint interval to incur less runtime overhead, at the expense of the changeset database retaining more history records. You can force zone checkpointing using the zone name chkpt command, and dump a more humanly readable form of the zone checkpoint file using the zone name dumpchkpt command.

Configuring Dynamic DNS for a Scope

This section describes how to configure dynamic DNS for a DHCP scope.

For dynamic DNS update, DHCP uses the host name passed to the server in the host-name DHCP option. With Microsoft clients, the name appears in the Control Panel/Network/Identification dialog box, not the Control Panel/Network/Protocols/Microsoft TCPIP Properties/DNS dialog box. The name is set on the client's computer. For security purposes, Network Registrar's dynamic DNS update process does not modify or delete a name an administrator manually entered in the DNS database.


Caution If you enable dynamic DNS update for large deployments, divide primary DNS and DHCP servers across multiple clusters. Dynamic DNS update generates an additional load on the servers.


Tip If you do not want the DHCP server to determine the host name from the host-name option (12), because the client may be sending unexpected or junk characters, use the dhcp disable use-host-name command.


Using the Web UI


Step 1 Create a scope, as described in the "Creating Scopes" section.

Step 2 Click the name of the scope on the List/Add DHCP Scopes page to open the Edit DHCP Scope page.

Step 3 Enable or set these attributes:

Enable dynamic-dns.

Set dns-zone-name to the zone to which a DHCP client's host name should be added (A record).

Set dns-reverse-zone-name to the reverse (in.addr.arpa) zone that is updated with PTR and TXT records.

Set dns-rev-server-addr to the address of the primary DNS server for the zone into which the server should add PTR records.

If necessary, enable update-relax-zone-name (see the "Using the CLI" sections).

If necessary, set the synthetic-name-stem value and enable synthesize-name (see the "Using the CLI" sections).

If necessary, enable use-dns-update-prereqs for the DHCP server, under the Dynamic DNS attribute category (see the "Using the CLI" sections).

Step 4 Click Modify Scope. See the Network Registrar Web UI Guide for details.


Using the CLI

Use scope name enable and scope name set commands to enable and set up dynamic DNS update properties for the DHCP scope.


Step 1 Use the scope name enable dynamic-dns command to enable dynamic updates for a scope.

nrcmd> scope examplescope1 enable dynamic-dns 
100 Ok
dynamic-dns=enabled

Step 2 Use separate scope name set commands to set the:

Name of the zone to which a DHCP client's host name should be added and its server address.

nrcmd> scope examplescope1 set dns-zone-name=example.com dns-server-addr=192.168.1.2 
100 Ok
dns-zone-name=example.com
dns-server-addr=192.168.1.2

Name of the reverse (in.addr.arpa) zone that is updated with PTR and TXT records.

nrcmd> scope examplescope1 set dns-reverse-zone-name=1.168.192.in-addr.arpa 
100 Ok
dns-reverse-zone-name=1.168.192.in-addr.arpa

IP address of the reverse zone's primary server.

nrcmd> scope examplescope1 set dns-rev-server-addr=192.168.1.2 
100 Ok
dns-rev-server-addr=192.168.1.2

You can choose to relax the restriction imposed by RFC 2136 on the dynamic update zone name record that requires it to be an actual zone name. You may want to do this to construct host names so that each scope generates names with different prefixes, but where those prefixes are not necessarily all configured as independent zones. With the restriction normally in effect (the default), the server has no way of identifying which actual zones these addresses are in and would create a packet that the DNS server considers invalid.

With the restriction removed, the name can then be any name in an authoritative zone. For example, DNS has a forward zone configured as example.com. You then create three scopes (net1, net2, and net3) and identify their forward zones as net1.example.com, net2.example.com, and net3.example.com.

To relax the restriction, use the dns enable update-relax-zone-name command.

nrcmd> dns enable update-relax-zone-name 
100 Ok
update-relax-zone-name=enabled

Step 3 You can set the stem of the default host name to use if clients do not supply hostnames by using the scope name set synthetic-name-stem command. The default synthetic name stem is dhcp. You can then use the scope name enable synthesize-name command to trigger the DHCP server to synthesize unique names for clients based on the value of the synthetic-name-stem attribute.

nrcmd> scope examplescope1 set synthetic-name-stem=dhcp 
100 Ok
synthetic-name-stem=dhcp
nrcmd> scope examplescope1 enable synthesize-name 
100 Ok
synthesize-name=enabled

Step 4 By default, the DHCP server uses prerequisites in its DNS update messages when it performs DNS updates on behalf of clients. You can use the dhcp disable use-dns-update-prereqs command to change this behavior, in which case the server does not include prerequisites when performing updates for leases from this scope. Without them, the server associates the last client who uses a given domain name with that name, even if another client was already associated with the name. It is best to maintain the default behavior for this attribute.

nrcmd> dhcp enable use-dns-update-prereqs 
100 Ok
use-dns-update-prereqs=true

Step 5 Reload the DHCP server.

nrcmd> dhcp reload 
100 Ok


Using the GUI


Step 1 In the Server Manager window, double-click the DHCP scope and click the DNS tab of the Scope Properties dialog box.

Step 2 Check the Perform dynamic DNS updates box.

Step 3 In the Forward field, enter the domain name of the forward DNS zone. This is the name of the DNS zone to which to add a DHCP client's host name, which will constitute its DNS Address (A) record.

You should use an existing, preconfigured zone name. However, you can choose to relax the restriction imposed by RFC 2136 on the dynamic update zone name record that requires it to be an actual zone name. You may want to do this to construct host names so that each scope generates names with different prefixes, but where those prefixes are not necessarily all configured as independent zones. The name can then be any name in an authoritative zone. Because this restriction applies by default, the server normally has no way of identifying which actual zones these addresses are in and would create a packet that the DNS server considers invalid.

For example, DNS has a forward zone configured as example.com. You then create three scopes (net1, net2, and net3) and identify their forward zones as net1.example.com, net2.example.com, and net3.example.com.

You have to relax the RFC 2136 restriction for the DNS server, not for the scope. Go to the DNS Server Properties dialog box and click the Advanced tab. On the Advanced tab, check the Enable relaxed dynamic update box.

Step 4 In the Server IP address field next to it, enter the IP address of the DNS server for the forward zone.

Step 5 In the Reverse field, enter the domain name of the reverse DNS zone. This is the in.addr.arpa zone updated with the pointer (PTR) and text (TXT) records.

Step 6 In the Server IP address field next to it, enter the IP address of the reverse DNS server.

The Number of host bytes field shows the number of address octets in the host name of the reverse DNS zone as opposed to the actual zone name. This is a noneditable field and the number is derived from the network number of the reverse zone.

Step 7 Choose whether to update the DNS records before or after the DHCP server responds to the client with a lease. The default is After responding to client.

Step 8 If you want Network Registrar to create names for hosts that do not supply names, check the Create hostnames for hosts that do not supply one box. Network Registrar creates a unique host name by prepending characters (dhcp by default) to the server's ID within the cluster followed by an incremented number, starting with dhcp-1-1 by default.

If you want Network Registrar to use a specific host name prefix other than dhcp, enter the prefix in the Create hostname starting with field.

Step 9 Click OK.

Step 10 Reload the DHCP server. The server can start giving out leases again.


Configuring DNS Updates for Windows 2000 Clients

Windows 2000 clients can directly update DNS servers with address record changes, or they can have the DHCP server do it. These clients can send their A record updates to DNS servers or request that the DHCP server send them. Only the DHCP server can update pointer (PTR) records to the DNS server. For the client to send A record updates directly to the DNS server, two conditions must apply:

The Windows 2000 client must have the Register this connection's addresses in DNS box checked on the DNS tab of its TCP/IP control panel settings.

The DHCP policy must enable direct updating (Network Registrar policies do so by default).

The Windows 2000 client notifies the DHCP server of its intention to update the A record to the DNS server by sending the client-fqdn DHCP option (81) in a DHCPREQUEST packet. By indicating the fully qualified domain name, the option states unambiguously the client's location in the domain namespace. Along with the FQDN itself, the client or server can send one of these possible flags in option 81:

0—Client should register its A record directly with the DNS server, and the DHCP server registers the PTR record (done through the policy name enable allow-client-a-record-update command).

1—Client wants the DHCP server to register its A and PTR records with the DNS server.

3—DHCP server registers the A and PTR records with the DNS server regardless of the client's request (done through the policy name disable allow-client-a-record-update command, which is the default). Only the DHCP server can set this flag.

The DHCP server returns its own option 81 response to the client in a DHCPACK based on whether dynamic DNS update is enabled. However, if the allow-client-a-record-update property is enabled for the policy, enabling or disabling dynamic DNS update is irrelevant, because the client can still send its updates to DNS servers. See Table 9-2 for the actions taken based on how various properties are set.

Table 9-2 Windows 2000 Client DNS Update Options 

DHCP Client Action
Dynamic DNS
DHCP Server Action

Checks Register this connection's addresses in DNS and sends option 81, and the DHCP server has allow-
client-a-record-update
enabled

Enabled
or disabled

Responds with option 81 that it allows the client to update its A record at the DNS server directly (sets flag 0). Meanwhile, the DHCP server updates the PTR record at the DNS server.

Checks Register this connection's addresses in DNS and sends option 81, but the DHCP server has allow-
client-a-record-update
disabled

Enabled

Responds with option 81 that it does not allow the client to update the DNS server directly (sets flag 3). The DHCP server updates the A and PTR records at the DNS server.

 

Disabled

Does not respond with option 81 and does not update the DNS server.

Unchecks Register this connection's addresses in DNS and sends option 81

Enabled

Responds with option 81 that it is updating the A and PTR records at the DNS server.

 

Disabled

Does not respond with option 81and does not update the DNS server.

Does not send option 81

Enabled

Does not respond with option 81, but updates the A and PTR records at the DNS server.

 

Disabled

Does not respond with option 81 and does not update the DNS server.


A Windows 2000 RC3 DHCP server can set the client-fqdn option (81) to ignore the client's request. To enable this in Network Registrar, create a policy for Windows 2000 clients and use the policy w2kpolicyname disable allow-client-a-record-update command.

These settings, related to client address registration in the DNS server, are enabled by default:

The use-client-fqdn-first attribute on the Edit DHCP Server page of the Web UI, or the dhcp enable use-client-fqdn-first command in the CLI—DHCP server examines option 81 on incoming packets from the client before examining the host-name option (12). If option 81 contains a host name, the server uses it. If the server does not find the option, it uses the option 12 value. If the use-client-fqdn-first attribute is disabled, the server prefers the option 12 value over option 81.

The use-client-fqdn attribute on the Edit DHCP Server page of the Web UI, or the dhcp enable use-client-fqdn command in the CLI—DHCP server uses the option 81 value on incoming packets and does not examine option 12. The DHCP server ignores all characters after the first dot in the domain name value, because it determines the domain from the defined scope for that client. Disable the use-client-fqdn property if you do not want the server to determine hostnames from option 81, possibly because the client is sending unexpected characters.

The use-client-fqdn-if-asked attribute on the Edit DHCP Server page of the Web UI, or the dhcp enable return-client-fqdn-if-asked command in the CLI—DHCP server returns option 81 in the outgoing packets if the client requests it. For example, the client might want to know the status of DNS activity, and hence request that the DHCP server should present option 81.

The allow-client-a-record-update attribute on the Edit DHCP Policy page of the Web UI, or the policy name enable allow-client-a-record-update command in the CLI—DHCP client can update its A record directly with the DNS server, as long as the client set the option 81 flag to 0 (requesting direct updating). Otherwise, the server updates the A record based on other configuration properties.

Settings in the Windows 2000 Client

The Windows 2000 RC3 client can set advanced properties to enable sending the client-fqdn option.


Step 1 On the Windows 2000 RC3 client, go to the Control Panel and open the TCP/IP Settings dialog box.

Step 2 Click the Advanced tab.

Step 3 Click the DNS tab.

Step 4 To have the client send the client-fqdn option in its request, leave the Register this connection's addresses in DNS box checked. This indicates that the client wants to do the A record update.


Settings in the DHCP Server

You can use the Web UI, CLI, or GUI to apply a relevant policy to a scope that includes the Windows 2000 clients, and enable DNS updates for the scope. However, you must use the CLI to allow the client to send its A record updates directly to the DNS server.


Step 1 Create a new policy for the scope that includes the Windows 2000 clients, as described in the "Defining and Configuring Scopes" section. For example:

nrcmd> policy policywin2k create 
100 Ok
...
nrcmd> scope win2k create 192.168.1.0 255.255.255.0 policy=policyWin2k 
100 Ok
...
nrcmd> scope win2k addRange 192.168.1.10 192.168.1.100 
100 Ok
192.168.1.10 192.168.1.100

Step 2 Use the scope name enable dynamic-dns command, or check the Perform dynamic DNS updates box in the GUI. Then set the zone name, server address (for A records) and reverse server address (for PTR records) properties, as described in the "Configuring Dynamic DNS for a Scope" section.

Step 3 If you want the client to update its A records at the DNS server, use the policy name enable allow-client-a-record-update command (this is the default).

nrcmd> policy policywin2k enable allow-client-a-record-update 
100 Ok
allow-client-a-record-update=enabled

Step 4 Reload the DHCP server.

nrcmd> dhcp reload 
100 Ok


Dual Zone Updates for Windows 2000 Clients

Windows 2000 DHCP clients might be part of a DHCP deployment where they have A records in two DNS zones. In this case, the DHCP server returns the client-fqdn option (81) so that the client can request a dual zone update.

The policy command and the embedded policy commands (client-policy, client-class-policy, and scope-policy) include the allow-dual-zone-dns-update attribute that you can enable. For example:

nrcmd> policy examplepolicy1 enable allow-dual-zone-dns-update 
100 Ok
allow-dual-zone-dns-update=enabled

The DHCP client sends the 0 flag in option 81 and the DHCP server returns the 0 flag so that the client can update the DNS server with the A record in its main zone. However, the DHCP server also directly sends an A record update based on the client's secondary zone in the client's behalf. If both the allow-client-a-record-update and the allow-dual-zone-dns-update attributes are enabled, allowing the dual zone update takes precedence so that the server can update the secondary zone's A record.

Enabling Dynamic Update on the DNS Server

After configuring dynamic DNS update for a DHCP scope, you must enable it for the DNS server.

Using the Web UI


Step 1 Create a zone, as described in the "Adding a Primary Forward Zone" section.

Step 2 Click the name of the zone on the List/Add Zones page to open the Edit Zone page.

Step 3 Enable or set these attributes in the Dynamic DNS attribute category:

Enable dynamic.

Set update-acl to the set of IP addresses from which dynamic updates are accepted.

Step 4 Click Modify Zone.

Step 5 Do the same for a created primary reverse zone, as described in the "Adding a Primary Reverse Zone for the Server" section. See the Network Registrar Web UI Guide for details.


Using the CLI

Use the zone name enable dynamic command to enable dynamic update in the forward and reverse zones and the zone name set update-acl command to specify the (comma-separated) addresses or networks from which to accept updates, then reload the server. If the DNS zone and DHCP scope are on the same machine, include the 127.0.0.1 loopback address in the address list. If you want to remove all dynamic resource records for an owner of a certain type, use the zone name removeDynRR command.

nrcmd> zone example.com. enable dynamic 
100 Ok
dynamic=true
nrcmd> zone example.com. set dynupdate-set=192.168.1.0 
100 Ok
dynupdate-set=192.168.1.0
nrcmd> zone 1.168.192.in-addr.arpa. enable dynamic 
100 Ok
dynamic=true
nrcmd> zone 1.168.192.in-addr.arpa. set dynupdate-set=192.168.1.0 
100 Ok
dynupdate-set=192.168.1.0
nrcmd> zone 1.168.192.in-addr.arpa. removeDynRR green A 
100 Ok
nrcmd> dns reload 
100 Ok

Using the GUI


Step 1 In the Server Manager window, double-click the DNS zone for which to enable dynamic DNS update.

Step 2 Click the DHCP tab of the Primary Zone Properties dialog box.

Step 3 Check the Enable dynamic DNS updates box.

Step 4 In the Accept updates from these addresses only field, enter at least one address or network from which to allow DNS updates. You must enter an address or network, or dynamic updates do not occur. If the DNS zone and DHCP scope are on the same machine, include the 127.0.0.1 loopback address.

Step 5 Repeat this process for the reverse DNS zones.

Step 6 Click OK.

Step 7 Reload the DNS server by right-clicking the icon and clicking Reload.


Setting Advanced Dynamic DNS Update Properties

You rarely need to modify the system defaults for advanced dynamic DNS update properties. Advanced dynamic DNS update support involves setting these parameters:

Setting the Number of DNS Packets

Setting the DNS Packet Size

Setting the Number of DNS Retries

Setting the Number of DNS Renaming Retries

Setting the DNS Request Timeout

Setting the Maximum DNS Record Time to Live

Scavenging Dynamic Records

Setting the Number of DNS Packets

You can control the number of buffers that DHCP allocates for communicating with DNS servers. For example, you can reduce the DHCP server's memory requirements by reducing the number of DNS packets, at the risk of missing updates. The default is 500 packets.

Using the Web UI

On the Primary Navigation bar, click the DHCP tab. On the Secondary Navigation bar, click the DHCP Server tab and the name of the server. This opens the Edit DHCP Server page. Under the Dynamic DNS attribute category, set the max-dns-packets, but not lower than the number of max-dhcp-responses, under the Request and Response Allocations category. Click Modify Server to make the changes. See the Network Registrar Web UI Guide for details.

Using the CLI

Use the dhcp set max-dns-packets command to set the number of DNS packets parameter. Do not set this lower than the number of DHCP responses (the max-dhcp-responses attribute).

nrcmd> dhcp get max-dhcp-responses 
100 Ok
max-dhcp-responses=1000 
nrcmd> dhcp set max-dns-packets=2000 
100 Ok
max-dns-packets=2000
nrcmd> dhcp reload 
100 Ok

Using the GUI


Step 1 In the Server Manager window, double-click the DHCP server to open its properties.

Step 2 Click the Advanced tab of the DHCP Server Properties dialog box.

Step 3 Record the number entered in the Number of DHCP responses field. (For details how to set this number, see the "Defining Advanced Server Parameters" section.)

Step 4 Click the Advanced DNS tab.

Step 5 Set the number of DNS packets in the Number of DNS packets field. Do not set this lower than the number recorded in step 3. The default is 500 packets.

Step 6 When you are finished setting advanced properties, click OK.

Step 7 Reload the DHCP server.


Setting the DNS Packet Size

Do not change the DNS packet size unless instructed to do so by the Cisco Technical Assistance Center (TAC). The default is 512 bytes.


Caution Change this setting under Cisco Technical Assistance Center (TAC) guidance only.

Using the GUI


Step 1 In the Server Manager window, double-click the DHCP server to open its properties.

Step 2 Click the Advanced DNS tab.

Step 3 Enter the value (in bytes) instructed by the Cisco Technical Assistance Center in the DNS packet size field. The default is 512 bytes.

Step 4 When you are finished setting advanced properties, click OK.

Step 5 Reload the DHCP server.


Setting the Number of DNS Retries

You can control the number of times the DHCP server attempts to send dynamic updates to a DNS server. The default is three retries.

Using the Web UI

On the Primary Navigation bar, click the DHCP tab. On the Secondary Navigation bar, click the DHCP Server tab and the name of the server. This opens the Edit DHCP Server page. Under the Dynamic DNS attribute category, adjust the max-dns-retries attribute from its default of 3, if desired, then click Modify Server. See the Network Registrar Web UI Guide for details.

Using the CLI

Use the dhcp set max-dns-retries command to set the number of DNS retries. Reload the DHCP server.

nrcmd> dhcp set max-dns-retries=6 
100 Ok
max-dns-retries=6
nrcmd> dhcp reload 
100 Ok

Using the GUI


Step 1 In the Server Manager window, double-click the DHCP server to open its properties.

Step 2 Click the Advanced DNS tab.

Step 3 Enter a value in the Number of DNS retries field.

Step 4 When you are finished setting advanced properties, click OK.

Step 5 Reload the DHCP server.


Setting the Number of DNS Renaming Retries

You can control the number of times the DHCP server tries to add a host to DNS even if it detects that the host name is already present. This value controls the number of times the DHCP server tries to modify a host name to resolve a conflict. The default is three retries.

Using the Web UI

On the Primary Navigation bar, click the DHCP tab. On the Secondary Navigation bar, click the DHCP Server tab and the name of the server. This opens the Edit DHCP Server page. Under the Dynamic DNS attribute category, adjust the max-dns-renaming-retries attribute from its default of 3, if desired, then click Modify Server. See the Network Registrar Web UI Guide for details.

Using the CLI

Use the dhcp set max-dns-renaming-retries command to set the maximum DNS renaming retries. Reload the DHCP server.

nrcmd> dhcp set max-dns-renaming-retries=6 
100 Ok
max-dns-renaming-retries=6
nrcmd> dhcp reload 
100 Ok

Using the GUI


Step 1 In the Server Manager window, double-click the DHCP server to open its properties.

Step 2 Click the Advanced DNS tab.

Step 3 Enter a value in the Number of DNS renaming retries field.

Step 4 If finished setting advanced properties, click OK.

Step 5 Reload the DHCP server.


Setting the DNS Request Timeout

You can control the number of milliseconds the DHCP server waits for a response before retrying a dynamic DNS request. The default is 60000 milliseconds.

Using the Web UI

On the Primary Navigation bar, click the DHCP tab. On the Secondary Navigation bar, click the DHCP Server tab and the name of the server. This opens the Edit DHCP Server page. Under the Dynamic DNS attribute category, adjust the dns-timeout attribute from its default of 60000ms, if desired, then click Modify Server. See the Network Registrar Web UI Guide for details.

Using the CLI

Use the dhcp set dns-timeout command to set the DNS request timeout value. Reload the DHCP server.

nrcmd> dhcp set dns-timeout=3600 
100 Ok
dns-timeout=3600
nrcmd> dhcp reload 
100 Ok

Using the GUI


Step 1 In the Server Manager window, double-click the DHCP server to open its properties.

Step 2 Click the Advanced DNS tab.

Step 3 Enter a value in milliseconds in the DNS request timeout field.

Step 4 When you are finished setting advanced properties, click OK.

Step 5 Reload the DHCP server.


Setting the Maximum DNS Record Time to Live

You can set the TTL ceiling, in seconds, for DNS records added through dynamic DNS. When the DHCP server adds a DNS record, it sets the TTL to the smaller of one-third of the lease time or this ceiling. The DNS record's effective TTL may actually be the DNS zone's default TTL. See the "Setting the SOA Time to Live" section. The default is 86400 seconds.

Using the Web UI

On the Primary Navigation bar, click the DHCP tab. On the Secondary Navigation bar, click the DHCP Server tab and the name of the server. This opens the Edit DHCP Server page. Under the Dynamic DNS attribute category, adjust the max-dns-ttl attribute from its default of 86400s, if desired, then click Modify Server. See the Network Registrar Web UI Guide for details.

Using the CLI

Use the dhcp set max-dns-ttl command to set the maximum DNS TTL value. Reload the DHCP server.

nrcmd> dhcp set max-dns-ttl=3600 
100 Ok
max-dns-ttl=3600
nrcmd> dhcp reload 
100 Ok

Using the GUI


Step 1 In the Server Manager window, double-click the DHCP server to open its properties.

Step 2 Click the Advanced DNS tab.

Step 3 Enter a value in seconds in the Maximum DNS record time to live field.

Step 4 When you are finished setting advanced properties, click OK.

Step 5 Reload the DHCP server.


Scavenging Dynamic Records

Microsoft Windows 2000 DNS clients that get DHCP leases can update (refresh) their Address (A) records directly with the DNS server. Because many of these clients are mobile laptops that are not permanently connected, some A records may become obsolete over time. The Windows 2000 DNS server scavenges and purges these primary zone records periodically. Network Registrar provides a similar feature that you can use to configure to periodically purge stale records.

Scavenging is normally disabled by default, but you should enable it for zones that exclusively contain Windows 2000 clients. Zones are configured with no-refresh and refresh intervals. Records expire once the record ages past its initial creation date plus these two intervals. Figure 9-1 shows the intervals in the scavenging time line.

Figure 9-1 Address Record Scavenging Time Line Intervals

The Network Registrar process is:

1. When the client updates the DNS server with a new A record, this record gets a timestamp, or if the client refreshes its A record, this may update the timestamp ("Record is created or refreshed").

2. During a no-refresh interval (a default of seven days), if the client keeps sending the same record without an address change, this does not update the record's timestamp.

3. Once the record ages past the no-refresh interval, it enters the refresh interval (also a default of seven days), during which time dynamic updates refresh the timestamp and put the record back into the no-refresh interval.

4. A record that ages past the refresh interval is available for scavenging when it reaches the scavenge interval.

Using the Web UI

On the Edit Zone page, enable or set the attributes described in the "Using the CLI" section. See the Network Registrar Web UI Guide for details.


Step 1 On the Primary Navigation bar, click the Zone tab. See the Network Registrar Web UI Guide for details.

Step 2 On the Secondary Navigation bar, click the Zones tab.

Step 3 Create a zone or edit an existing one.

Step 4 On the Add Zone or Edit Zone page, set these attributes under the Scavenging category:

scvg-interval—Period during which the DNS server checks for stale records in a zone. The default is seven days and the value can range from one hour to 365 days. You can set this at the server and zone levels, although the zone setting overrides the server setting.

scvg-no-refresh-interval—Interval during which actions, such as dynamic or prerequisite-only dynamic updates, do not update the record timestamp. The default is seven days and the value can range from one hour to 365 days. The zone setting overrides the server setting.

scvg-refresh-interval—Interval during which dynamic updates update the record timestamp. After both the no-refresh and refresh intervals expire, the record is a candidate for scavenging. The default is seven days and the value can range from one hour to 365 days. The zone setting overrides the server setting.

scvg-ignore-restart-interval—Ensures that the server does not reset the scavenging time with every server restart. Within this interval, the Network Registrar ignores the time between when the server went down and was restarted, which is usually fairly short. The interval defaults to two hours, but has a maximum value of one day. With any time longer than that set, Network Registrar recalculates the scavenging period to allow for records to be updated that could not do so while the server was stopped. The zone setting overrides the server setting.

Step 5 Click Modify Zone. See the Network Registrar Web UI Guide for details.


Using the CLI


Step 1 You should enable scavenging only for zones where a Network Registrar DNS server receives updates exclusively from Windows 2000 clients (or those known to do automatic periodic DNS updates) only.

nrcmd> zone example.com. enable scvg-enabled 
100 Ok
scvg-enabled=true

Step 2 When you enable zone scavenging, you can also set these time line intervals:

scvg-interval—Period during which the DNS server checks for stale records in a zone. The default is seven days and the value can range from one hour to 365 days. You can set this at the server and zone levels, although the zone setting overrides the server setting.

nrcmd> dns set scvg-interval=7d 
nrcmd> zone example.com. set scvg-interval=7d 
100 Ok
scvg-interval=7d

scvg-no-refresh-interval—Interval during which actions, such as dynamic or prerequisite-only dynamic updates, do not update the record timestamp. The default is seven days and the value can range from one hour to 365 days. The zone setting overrides the server setting.

nrcmd> dns set scvg-no-refresh-interval=7d 
100 Ok
scvg-no-refresh-interval=7d
nrcmd> zone example.com. set scvg-no-refresh-interval=7d 
100 Ok
scvg-no-refresh-interval=7d

scvg-refresh-interval—Interval during which dynamic updates update the record timestamp. After both the no-refresh and refresh intervals expire, the record is a candidate for scavenging. The default is seven days and the value can range from one hour to 365 days. The zone setting overrides the server setting.

nrcmd> dns set scvg-refresh-interval=7d 
100 Ok
scvg-refresh-interval=7d
nrcmd> zone example.com. set scvg-refresh-interval=7d 
100 Ok
scvg-refresh-interval=7d

scvg-ignore-restart-interval—Ensures that the server does not reset the scavenging time with every server restart. Within this interval, the Network Registrar ignores the time between when the server went down and was restarted, which is usually fairly short. The interval defaults to two hours, but has a maximum value of one day. With any time longer than that set, Network Registrar recalculates the scavenging period to allow for records to be updated that could not do so while the server was stopped. The zone setting overrides the server setting.

nrcmd> dns set scvg-ignore-restart-interval=2h 
100 Ok
scvg-ignore-restart-interval=2h
nrcmd> zone example.com. set scvg-ignore-restart-interval=2h 
100 Ok
scvg-ignore-restart-interval=2h

The Network Registrar scavenging manager starts at server startup. It reports records purged through scavenging to the changeset database. Network Registrar also notifies any secondary zones by way of zone transfers of any records scavenged from the primary zone. In cases where you create a zone that has scavenging disabled (the records do not have a timestamp) and then subsequently enable it, Network Registrar uses a proxy timestamp as a default timestamp for each record.

Step 3 You can use the getScavengeStartTime action on a zone to find out the next time scavenging is scheduled to start on the zone. If you want to force scavenging at any time, use the dns scavenge command for all zones that have scavenging enabled, or the zone name scavenge command for a specific zone that has it enabled.

nrcmd> zone example.com. getScavengeStartTime 
359 No zone matched
nrcmd> dns scavenge 
100 Ok
scavenge zones scheduled
nrcmd> zone example.com. scavenge 
359 No zone matched

Step 4 You can monitor scavenging activity using one or more of these log settings.

nrcmd> dns set log-settings=scavenge,scavenge-details,ddns-refreshes, 
ddns-refreshes-details 
100 Ok
log-settings=scavenge,scavenge-details,ddns-refreshes,ddns-refreshes-details



Note For other Windows 2000 issues, see "Windows 2000 Interoperability."


Setting Transaction Security

You can secure dynamic DNS updates using Transaction Signatures (TSIG). This allows DNS and DHCP servers to verify that requests and responses come from an authorized source. Both the DNS and DHCP servers can read and process TSIG data from Network Registrar or other servers. TSIG is based on RFC 2845 and uses the HMAC-MD5 (or keyed-MD5) algorithm for integrity verification of data transmitted over open networks between parties that share a common secret key. TSIG is relatively simple to configure, easy for resolvers and name servers to use, and flexible enough to secure DNS messages.

Currently, TSIG keys are used only for dynamic DNS updates. The DHCP server uses TSIG keys to create TSIG resource records while processing these updates. Each key needs to exist, and the DHCP scope must be enabled for dynamic DNS update using the dynamic-dns attribute. The Web UI allows configuration of TSIG keys for failover partners.

In Network Registrar, the TSIG key name is associated with a shared secret value. The key name should reflect the name of the hosts using this key. Entry of a name also requires a shared secret. The following section describes how to generate random keys.

Generating Random Keys

You can use the Network Registrar cnr_keygen utility to generate random TSIG keys so that you add them using the key command (see the "Adding Keys" section), or import them using the import keys command.

Execute the cnr_keygen key generator utility from a DOS prompt, or a Solaris or Linux shell:

On Windows, the utility is, by default, in the C:\Program Files\Network Registrar\bin folder.

On Solaris and Linux, the utility is in the /opt/nwreg2/usrbin directory.

An example of its usage (on Solaris/Linux) is:

> /opt/nwreg2/usrbin/cnr_keygen -n host-a.host-b.example.com. -a hmac-md5 -t TSIG -b 16 
-s 300 
key "host-a.host-b." { 
algorithm hmac-md5; 
secret "xGVCsFZ0/6e0N97HGF50eg=="; 
# cnr-time-skew 300; 
# cnr-security-type TSIG; 
}; 

The only required input is the key name. The options are described in Table 9-3.

Table 9-3 Options for the cnr_keygen Utility 

Option
Description

-n name

Key name. Required. The maximum length is 255 bytes.

-a hmac-md5

Algorithm. Optional. Only hmac-md5 is currently supported.

-b bytes

Byte size of the secret. Optional. The default is 16 bytes. The valid range is 1 through 64 bytes.

-s skew

Time skew for the key, or the amount of time that the time stamp in packets signed with this key can differ from the local system time. Optional. The default is five minutes. The range is one second through one hour.

-t tsig

Type of security used. Optional. Only TSIG is currently supported.

-h

Help. Optional. Displays the syntax and options of the utility.

-v

Version. Optional. Displays the version of the utility.


The resulting secret is base64-encoded as a random string. Enter this value using the key command (see the "Adding Keys" section).

You can also redirect the output to a file if you use the > or >> indicators at the end of the command line. The > writes or overwrites a given file, while the >> appends to an existing file.

> /opt/nwreg2/usrbin/cnr_keygen -n example.com > keyfile.txt 
> /opt/nwreg2/usrbin/cnr_keygen -n example.com >> addtokeyfile.txt 

You can then import the key file into Network Registrar using the CLI to generate the keys in the file. The key import can generate as many keys as it finds in the import file. Use this command to import the key file:

nrcmd> import keys keyfile.txt 
100 Ok

Guidelines for Generating Your Own Keys

If you generate your own keys, you must enter them as a base64-encoded string. This means that the only characters allowed are those in the base64 alphabet and the padding character (=). Entering a nonbase64-encoded string results in an error message. Because the shared secret is sensitive data and security would be compromised if this data were exposed, these guidelines can improve security:

Do not add or modify keys using batch commands.

Change shared secrets frequently; every two months is recommended. Note that Network Registrar does not explicitly enforce this, but it should be a policy to use.

The shared secret length should be at least as long as the keyed message digest (HMAC-MD5 is 16 bytes). Note that Network Registrar does not explicitly enforce this and only checks that the shared secret is a valid base64-encoded string, but it is the policy recommended by RFC 2845.

Adding Keys

Using the Web UI


Step 1 If you have the rights to do so, on the Primary Navigation bar, click Administration.

Step 2 On the Secondary Navigation bar, click Keys.

Step 3 Add a key name, an optional time skew value, and a secret value. For details, see the Network Registrar Web UI Guide.

Step 4 Click Add Key.

Step 5 On the Primary Navigation bar, click DHCP, then either Scope or DHCP Server. If selecting Scope, also click the name of the appropriate scope.

Step 6 Set these attributes on the scope or DHCP server level, under the Dynamic DNS (Security) category:

dynamic-dns-tsig—Decide if you want to set this for forward or reverse zones, or both. On the scope level, you can set this to enable-fwd-rev, disable-fwd-rev, enable-fwd-only, enable-rev-only, or use-server-settings. On the server level, you can set this to enable-fwd-rev, disable-fwd-rev, enable-fwd-only, or enable-rev-only.

dynamic-tsig-fwd-key—Key for forward zones only.

dynamic-tsig-rev-key—Key for reverse zones only.

Step 7 Click Modify Scope or Modify Server, depending on what page you are on.


Using the CLI

You can create a TSIG security key using the key command. This command takes a name, secret, and some attributes. The attributes define the key's algorithm (which is always HMAC-MD5), type (which is always TSIG), and time skew value (the number of seconds of error permitted in the signature time, which defaults to 300 seconds and can be as long as one hour).

nrcmd> key name create secret attribute=value [attribute=value] ... 

For example, this command creates a key called h-a.h-b.example.com., with a secret "Sc+dRn/kdLl9JzQenByfQA==" and a time-skew factor of 300 seconds (five minutes):

nrcmd> key h-a.h-b.example.com. create "Sc+dRn/kdLl9JzQenByfQA==" algorithm=hmac-md5 
security-type=tsig time-skew=300s 
h-a.h-b.example.com.:
algorithm = hmac-md5
id =
name = h-a.h-b.example.com.
secret = Sc+dRn/kdLl9JzQenByfQA==
security-type = TSIG
time-skew = 5m

Configuring DHCP for Transaction Security

To enable security keys for the server or scope, you must set whether you want TSIG security for forward zone or reverse zone updates, or both. By default, TSIG security is disabled for both types of zone updates on the DHCP server level, and DHCP scopes are set up by default to use the server setting. To change this, set the dynamic-dns-tsig attribute on the DHCP server or scope level to enable it for one or both of the zone types. The possible attribute settings are enable-fwd-rev, disable-fwd-rev, enable-fwd-only, and enable-rev-only, with an additional setting for the scope of use-server-settings. This example enables TSIG for forward and reverse zones on the server level, but the scope setting overrides this by setting it for forward zones only for scope1:

nrcmd> dhcp set dynamic-dns-tsig=enable-fwd-rev 
nrcmd> scope examplescope1 set dynamic-dns-tsig=enable-fwd-only 

Like many other CLI commands, you can list, show, delete, and set and get properties for TSIG keys.

nrcmd> key list 
100 Ok
h-a.h-b.example.com.:
algorithm = hmac-md5
id =
name = h-a.h-b.example.com.
secret = Sc+dRn/kdLl9JzQenByfQA==
security-type = TSIG
time-skew = 5m
nrcmd> key listNames 
100 Ok
h-a.h-b.example.com.
nrcmd> key h-a.h-b.example.com. show 
100 Ok
h-a.h-b.example.com.:
algorithm = hmac-md5
id =
...
nrcmd> key h-a.h-b.example.com. set time-skew=1h 
100 Ok
time-skew=60m
nrcmd> key h-a.h-b.example.com. get time-skew 
100 Ok
time-skew=60m
nrcmd> key h-a.h-b.example.com. unset time-skew 
100 Ok
nrcmd> key h-a.h-b.example.com. delete 
100 Ok

Creating Access Control Lists

Access control lists (ACLs) are a way of setting up authorization permissions for DNS transactions. Currently, ACLs are only supported for dynamic DNS updates. You assign the ACLs on the DNS server or zone level. ACLs can include one or more of these elements:

Key

IP address

Network address (IP address and mask)

Another ACL

Using the Web UI


Step 1 If you have the rights to do so, on the Primary Navigation bar, click Administration.

Step 2 On the Secondary Navigation bar, click ACLs.

Step 3 Add an ACL name and match list. Note that a key value pair should not be in quotes.

Step 4 Click Add ACL. See the Network Registrar Web UI Guide for details.


Using the CLI

You create ACLs using the acl command. This command takes a name and one or more ACL elements. An element can be a key, IP address, network address, or another ACL. The ACL list is comma-separated, with double quotes surrounding it if there is a space character.

Key—The value must be in the form key value, with the keyword key followed by the secret value. Because of the space character, the entire list must be enclosed in double quotes. For keys, see the "Setting Transaction Security" section.

IP address—In the form 192.168.1.2.

Network address—In the form 192.168.0.0/24. As a result, only hosts in that network can update the DNS server.

Another ACL—That ACL must be predefined. You cannot delete the latter ACL, because it is included as a value to the ACL being defined.

nrcmd> acl name create "key value, ..." 

For example, the following commands create three ACLs. The first is a key with a value, the second is for a network, and the third points to the first ACL. Including the ! symbol before a value negates that value, so that you can exclude it in a series of values.

nrcmd> acl sec-acl create "key h-a.h-b.example.com." 
100 Ok
sec-acl:
match-list = "key h-a.h-b.example.com."
nrcmd> acl dyn-update-acl create "192.168.2.0/24,!192.168.2.13" 
nrcmd> acl main-acl create sec-acl 

You can list, show, delete, and add and remove type/value pairs for ACLs.

nrcmd> acl list 
100 Ok
sec-acl:
match-list = "key h-a.h-b.example.com."
nrcmd> acl listNames 
100 Ok
sec-acl
nrcmd> acl sec-acl show 
100 Ok
sec-acl:
match-list = "key h-a.h-b.example.com."
nrcmd> acl sec-acl add "key h-a.h-b.example.com." 
100 Ok
sec-acl:
match-list = "key {h-a.h-b.example.com.;} {key h-a.h-b.example.com.}"
nrcmd> acl sec-acl remove "key h-a.h-b.example.com." 
100 Ok
sec-acl:
match-list = "key h-a.h-b.example.com."
nrcmd> acl sec-acl delete 
100 Ok


Tip You can use the 0.0.0.0/0 network specification in your ACL to allow everyone to update a zone.


Configuring the DNS Server or Zone for ACLs

Using the Web UI


Step 1 On the Primary Navigation bar, click Zone, then either Zones or DNS Server. If selecting Zones, also click the name of the appropriate zone. See the Network Registrar Web UI Guide for details.

Step 2 Set the update-acl attribute on the zone or DNS server level. (For the zone, it is under the Dynamic DNS category; for the server, it is under the Zone Defaults category.) The value can be a key, IP address, network address, or another ACL. Precede the key with the key keyword.

Step 3 Click Modify Zone or Modify Server, depending on what page you are on.


Using the CLI

To set up the DNS server and zones to use ACLs, set the update-acl attribute for the server or zone. An ACL set at the zone level overrides the server value. The attribute takes the ACL name or names as its value. Including the ! symbol before a value negates that value, so that you can exclude it. ACLs are ORed lists and are searched from the left to right. If you include negated elements in the list, they should come before the other ones to assure that the negated ones are handled first.

nrcmd> dns set update-acl=sec-acl,!dynupdate-acl 
100 Ok
update-acl="sec-acl; ! dynupdate-acl"
nrcmd> zone example.com. set update-acl=sec-acl,!dynupdate-acl 
100 Ok
update-acl="sec-acl; ! dynupdate-acl"


Note The update-acl attribute replaces the dynupdate-set attribute, which has been deprecated.


Restrictions to TSIG Keys and ACLs

Here is a list of restrictions to creating TSIG keys and ACLs:

You can only configure one key per DHCP server or scope.

If you set the key on a scope, this overrides the key set on the DHCP server level.

If you set the ACL on a zone, this overrides the ACL set on the DNS server level.

Troubleshooting Dynamic DNS Update

To verify if dynamic updates happened correctly to your DNS server, use the nslookup tool to do a reverse lookup.

$ nslookup 
Default Server: server2.example.com 
Address: 192.168.1.2 
> leasehost1.example.com 
Server: server2.example.com 
Address: 192.168.1.100 
> set type=ptr 
> 192.168.1.100 
Server: server2.example.com 
Address: 192.168.1.100 

100.40.168.192.in-addr.arpa name = leasehost1.example.com 
40.168,192.in-addr.arpa nameserver = server2.example.com 

You can monitor dynamic DNS updates on the DNS server by setting the log-settings attribute on the Edit DNS Server page of the Web UI to ddns, or using the dns set log-settings=ddns command in the CLI, or even more details by setting it to ddns-details.

Changing the following DNS changeset trimming attribute values may help performance tune the changeset transactions. In the Web UI, find these in the Visibility=3 attributes of the Edit DNS Server page. In the CLI, you must change the session visibility level to 3 to change these values.

nrcmd> session set visibility=3 
100 Ok
visibility=3

If you observe excessive full zone transfers, there may be too much trimming activity. Increase the number of histories (changesets) to exclude from trimming. The default is 400 and the suggested range is 200 through 2000.

nrcmd> dns set changeset-db-history-kept=1000 
100 Ok
changeset-db-history-kept=1000

If there are many zones in the changeset database, increase the maximum number of histories (changesets) to delete at one time for trimming. The default is 2000 and the suggested range is 200 through 4000. You may also want to increase the percentage of the zone history through which to travel to check the history size or look for trimming candidates. The default is 10% and the suggested range is 2 through 100 percent.

nrcmd> dns set changeset-db-hist-max-trim-count=3000 
100 Ok
changeset-db-hist-max-trim-count=3000
nrcmd> dns set htrim-zone-size-to-travel=50 
100 Ok
htrim-zone-size-to-travel=50

If you observe many incremental transfers or an excess of zone checkpointing, increase the multiplier value to provide a higher threshold of zone history size for trimming. The default is 5 and the suggested range is 2 through 20. With a changeset-db-history-kept attribute value of 1000 used with the multiplier value 10, this would make a zone of size 10000, instead of the default 2000, a candidate for trimming.

nrcmd> dns set htrim-zone-max-hist-allowed=10 
100 Ok
htrim-zone-max-hist-allowed=10

Always change the session visibility back to 5 after using these commands.

nrcmd> session set visibility=5 
100 Ok
visibility=5