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 hostname. Mobile hosts, for example, can move freely without user or administrator intervention.

This chapter explains how to use dynamic DNS update with 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.

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.

Confirming Dynamic Records

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

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

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 zonenameset 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 hostname 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 hostname 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 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.

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

Step 3 You can set the stem of the default hostname 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 testScope set synthetic-name-stem=dhcp

nrcmd> scope testScope enable synthesize-name

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

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 (see Figure 6-10). 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 hostname 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 hostname 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 hostname prefix other than dhcp, enter the prefix in the "Create hostname starting with" field.

Configuring DNS Updates for Windows 2000 Clients

Windows 2000 clients can directly update DNS servers with address 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 to send them (only the DHCP server keeps track of and can send PTR record updates). 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 Windows 2000 client notifies the DHCP server of its intention 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). 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.

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.

Using the CLI

The following settings related to client address updating in the DNS server are enabled by default.

•dhcp enable use-client-fqdn-first—DHCP server examines option 81 on incoming packets from the client before examining the host-name option (12). If option 81 contains a hostname, 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.

•dhcp enable use-client-fqdn—DHCP server uses the option 81 value on incoming packets and does not examine option 12. It ignores any 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.

•dhcp enable return-client-fqdn-if-asked—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.

•policy name enable allow-client-a-record-update—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 server configuration parameters.

Settings in the Windows 2000 Client

The Windows 2000 RC3 client has an Advanced tab of the TCP/IP Settings in the control panel to enable sending the client-fqdn option with the proper setting.

Using the GUI

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

Step 4 Reload the DHCP server.

nrcmd> dhcp reload

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.

Using the CLI

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 pol1 enable allow-dual-zone-dns-update

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 CLI

Use the zone name enable dynamic command to enable dynamic update in the forward and reverse zones and the zone name set dynupdate-set 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

nrcmd> zone example.com. set dynupdate-set=192.168.1.0

nrcmd> zone 1.168.192.in-addr.arpa. enable dynamic

nrcmd> zone 1.168.192.in-addr.arpa. set dynupdate-set=192.168.1.0

nrcmd> zone 1.168.192.in-addr.arpa. removeDynRR green A

nrcmd> dns reload

Using the GUI

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

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

You can control the number of buffers that DHCP allocates for communicating with DNS servers. 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 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

nrcmd> dhcp reload

Using the GUI

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

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 hostname is already present. This value controls the number of times the DHCP server tries to modify a hostname to resolve a conflict. The default is three retries.

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

nrcmd> dhcp reload

Using the GUI

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

Using the GUI

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

nrcmd> dhcp reload

Using the GUI

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

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 generally update (refresh) their Address (A) records directly with the DNS server every 24 hours. 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. To interoperate with Windows 2000, Network Registrar includes a scavenging period for Windows 2000 clients and others that do automatic record refreshing.

Caution Do not enable record scavenging for zones that do not exclusively contain Windows 2000 clients.

Scavenging is normally disabled by default, but you should enable it for zones that exclusively contain Windows 2000 clients. The prescavenging period goes through intervals before actual record scavenging and purging begins. Figure 9-4 shows the intervals in the scavenging time line.

Figure 9-4 Address Record Scavenging Time Line Intervals

The Network Registrar process is as follows:

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. The prescavenging period 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 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

Step 2 When you enable zone scavenging, you can also set the following 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

•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

nrcmd> zone example.com. set 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

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

•scvg-ignore-restarts-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. The zone setting overrides the server setting.

nrcmd> dns set scvg-ignore-restarts-interval=2h

nrcmd> zone example.com. set scvg-ignore-restarts-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

nrcmd> dns scavenge

nrcmd> zone example.com. scavenge

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

Troubleshooting Dynamic DNS Update

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

$ 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 using the dns set log-settings=ddns command, or more details using the dns set log-settings=ddns-details command.

Changing the following DNS changeset trimming attribute values may help performance tune the changeset transactions. You must change the session visibility level to 3 to change these values.

nrcmd> session set 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

•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

nrcmd> dns set 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.