Consider these two issues when configuring DNS updates:

• For security purposes, the Cisco Prime Network Registrar DNS update process does not modify or delete a name an administrator manually enters in the DNS database.
• If you enable DNS update for large deployments, and you are not using HA DNS (see the "Deploying High Availability DNS Pair" chapter in Cisco Prime Network Registrar 11.1 Authoritative and Caching DNS User Guide), divide primary DNS and DHCP servers across multiple clusters. DNS update generates an additional load on the servers.

DNS Updates for DHCPv6 involves AAAA and PTR RR mappings for leases. Cisco Prime Network Registrar supports server- or extension-synthesizing fully qualified domain names and the DHCPv6 client-fqdn option (39).

Because Cisco Prime Network Registrar is compliant with RFCs 4701, 4703, and 4704, it supports the DHCID resource record (RR). All RFC-4703-compliant updaters can generate DHCID RRs and result in data that is a hash of the client identifier (DUID) and the FQDN (per RFC 4701). Nevertheless, you can use AAAA and DHCID RRs in update policy rules.

DNS update processing for DHCPv6 is similar to that for DHCPv4 except that a single FQDN can have more than one lease, resulting in multiple AAAA and PTR RRs for a single client. The multiple AAAA RRs can be under the same name or a different name; however, PTR RRs are always under a different name, based on the lease address. RFC-4703-compliant updaters use the DHCID RR to avoid collisions among multiple clients.

Note	If the DNS server is down and the DHCP server can not complete the DNS updates to remove RRs added for a DHCPv6 lease, the lease continues to exist in the AVAILABLE state. Only the same client reuses the lease.

DNS Updates for delegated prefixes can be enabled to update AAAA and/or PTR mappings for delegated prefix leases. However, this only updates DNS for the all 0's address for the delegated prefix. For example, if a prefix of 2001:db8:3333:3333::/64 is delegated, only the PTR and/or AAAA for 2001:db8:3333:3333::0 is updated in DNS. This feature does not provide a means for doing DNS delegations for delegated prefix.

Updates for delegated prefixes are only enabled if the DNS Update Configuration has the prefix-delegation-updates attribute enabled. This attribute is disabled by default. Updates for delegated prefixes most likely occur to different zones than the address updates, and therefore you may need to create new DNS update configurations and associate them with the corresponding prefixes.

Since the standard name generation rules apply, a client that includes an FQDN option with a hint can impact the resulting name (if the configuration allows this). Clients are never returned the name used for prefix delegation updates if they request the FQDN option.

Note	If using this feature, you MUST assure that both the failover partners are running a version which supports this feature. Otherwise, updates will only be done when serviced by the server that has been upgraded. Therefore, do not enable this feature until both partners have been upgraded.

If you use any policy configured prior to Cisco Prime Network Registrar that references a DNS update object for DHCPv6 processing (see DHCPv6 Policy Hierarchy), after the upgrade, the server begins queuing DNS updates to the specified DNS server or servers. This means that DNS updates might automatically (and unexpectedly) start for DHCPv6 leases.

Caution

If you use earlier versions of Cisco Prime Network Registrar or other DNS servers, you might experience interoperability issues for zone transfers and DNS updates, because of recent DHCID RR standards changes. You might need to upgrade DNS servers to support DHCPv6 DNS updates.

If clients do not supply hostnames, DHCPv4 and DHCPv6 includes a synthetic name generator. The v6-synthetic-name-generator attribute for the DNS update configuration allows appending a generated name to the synthetic-name-stem based on the:

• Hash of the client DHCP Unique Identifier (DUID) value (the preset value).
• Raw client DUID value (as a hex string with no separators).
• CableLabs cablelabs-17 option device-id suboption value (as a hex string with no separators, or the hash of the client DUID if not found).
• CableLabs cablelabs-17 option cm-mac-address suboption value (as a hex string with no separators, or the hash of the client DUID if not found).

Caution

Some generation methods might cause privacy issues if the domain is accessible from the Internet.

The v4-synthetic-name-generator attribute for the DNS update configuration allows appending a generated name to the synthetic-name-stem based on the:

• address—Identifies the v4 address of client.
• client-id—Client-id or DUID given by DHCPv4 client in its request (Option 61).
• hashed-client-id—The hashed client-id which is a 13-character base 32 encoded string formed of the right part 64-bits of the SHA-256 hash appended with the forward zone name.

See Creating DNS Update Configurations for how to create a DNS update configuration with synthetic name generation.

In the CLI, an example of this setting is:

nrcmd> dhcp-dns-update example-update-config set v6-synthetic-name-generator=hashed-duid
 
nrcmd> dhcp-dns-update example-update-config set v4-synthetic-name-generator=client-id

The DNS update configuration uses the prefix length value in the specified reverse-zone-prefix-length attribute to generate a reverse zone in the ip6.arpa domain. You do not need to specify the full reverse zone, because you can synthesize it by using the ip6.arpa domain. You set this attribute for the reverse DNS update configuration (see Creating DNS Update Configurations). Here are some rules for reverse-zone-prefix-length:

• Use a multiple of 4 for the value, because ip6.arpa zones are on 4-bit boundaries. If not a multiple of 4, the value is rounded up to the next multiple of 4.
• The maximum value is 124, because specifying 128 would create a zone name without any possible hostnames contained therein.
• A value of 0 means none of the bits are used for the zone name, hence ip6.arpa is used.
• If you omit the value from the DNS update configuration, the server uses the value from the prefix or, as a last resort, the prefix length derived from the address value of the prefix (see Configuring Prefixes and Links).

Note that to synthesize the reverse zone name, the synthesize-reverse-zone attribute must remain enabled for the DHCP server. Thus, the order in which a reverse zone name is synthesized for DHCPv6 is:

1. Use the full reverse-zone-name in the reverse DNS update configuration.
2. Base it on the ip6.arpa zone from the reverse-zone-prefix-length in the reverse DNS update configuration.
3. Base it on the ip6.arpa zone from the reverse-zone-prefix-length in the prefix definition.
4. Base it on the ip6.arpa zone from the prefix length for the address in the prefix definition.

nrcmd> dhcp-dns-update example-update-config set reverse-zone-prefix-length=32

To create a reverse zone for a prefix in the web UI, the List/Add Prefixes page includes a Create Reverse Zone button for each prefix. (See Creating and Editing Prefixes.)

The CLI also provides the prefix name createReverseZone [–range ] command to create a reverse zone for a prefix (from its address or range value). Delete the reverse zone by using prefix name deleteReverseZone [–range ].

You can also create a reverse zone from a DHCPv4 subnet or DHCPv6 prefix by entering the subnet or prefix value when directly configuring the reverse zone. See the "Configuring Primary Reverse Zones" section in Cisco Prime Network Registrar 11.1 Authoritative and Caching DNS User Guide for details.

The existing DHCP server use-client-fqdn attribute controls whether the server pays attention to the DHCPv6 client FQDN option in the request. The rules that the server uses to determine which name to return when multiple names exist for a client are in the following order of preference:

1. The server FQDN that uses the client requested FQDN if it is in use for any lease (even if not considered to be in DNS).
2. The FQDN with the longest valid lifetime considered to be in DNS.
3. The FQDN with the longest valid lifetime that is not yet considered to be in DNS.

You assign ACLs on the DNS Caching server or zone level. ACLs can include one or more of these elements:

• IP address —In dotted decimal notation; for example, 192.168.1.2.
• Network address —In dotted decimal and slash notation; for example, 192.168.0.0/24. In this example, only hosts on that network can update the DNS server.
• Another ACL —Must be predefined. You cannot delete an ACL that is embedded in another one until you remove the embedded relationship. You should not delete an ACL until all references to that ACL are deleted.
• Transaction Signature (TSIG) key —The value must be in the form key value, with the keyword key followed by the secret value. To accommodate space characters, the entire list must be enclosed in double quotes. For TSIG keys, see Transaction Security.

You assign each ACL a unique name. However, the following ACL names have special meanings and you cannot use them for regular ACL names:

• any —Anyone can perform a certain action
• none —No one can perform a certain action
• localhost —Any of the local host addresses can perform a certain action
• localnets —Any of the local networks can perform a certain action

Note the following:

• If an ACL is not configured, any is assumed.
• If an ACL is configured, at least one clause must allow traffic.
• The negation operator (! ) disallows traffic for the object it precedes, but it does not intrinsically allow anything else unless you also explicitly specify it. For example, to disallow traffic for the IP address 192.168.50.0 only, use !192.168.50.0, any .

To configure ACLs for the DNS server or zones, set up a DNS update policy, then define this update policy for the zone (see Configuring DNS Update Policies).

It is recommended that you use the Cisco Prime Network Registrar cnr_keygen utility to generate TSIG keys so that you add them or import them using import keys .

Execute the cnr_keygen key generator utility from a Linux shell. The utility is in the install-path/usrbin directory.

An example of its usage is:

> /opt/nwreg2/local/usrbin/cnr_keygen -n a.b.example.com. -a hmac-md5 -t TSIG -b 16
-s 300
 
key "a.b.example.com." { 
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 the table below.

The resulting secret is base64-encoded as a random string.

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

You can then import the key file into Cisco Prime 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. The path to the file should be fully qualified. For example:

nrcmd> import keys keydir/keyfile.txt
 

If you generate your own keys, you must enter them as a base64-encoded string (See RFC 4648 for more information on base64 encoding). This means that the only characters allowed are those in the base64 alphabet and the equals sign (=) as pad character. Entering a nonbase64-encoded string results in an error message.

Here are some other suggestions:

• Do not add or modify keys using batch commands.
• Change shared secrets frequently; every two months is recommended. Note that Cisco Prime Network Registrar does not explicitly enforce this.
• The shared secret length should be at least as long as the keyed message digest (HMAC-MD5 is 16 bytes). Note that Cisco Prime 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.

To add TSIG support for a DNS update configuration (see Creating DNS Update Configurations), set these attributes:

• server-key

• backup-server-key

To use GSS-TSIG security algorithm in TSIG, enable the below attribute:

• use-gss-tsig

Use dhcp-dns-update name create [attribute=value ...]. For example:

dhcp-dns-update example-update-config create

Set the dynamic-dns attribute to its appropriate value (update-none, update-all, update-fwd-only, or update-reverse-only). For example:

nrcmd> dhcp-dns-update example-update-config set dynamic-dns=update-all

Cisco Prime Network Registrar releases used static RRs that administrators entered, but that DNS updates could not modify. This distinction between static and dynamic RRs no longer exists. RRs can now be marked as protected or unprotected (see the "Protecting Resource Record Sets" section in Cisco Prime Network Registrar 11.1 Authoritative and Caching DNS User Guide). Administrators creating or modifying RRs can now specify whether RRs should be protected. A DNS update cannot modify a protected RR set, even if an RR of the given type does not yet exist in the set.

Note	Previous releases allowed DNS updates only to A, TXT, PTR, CNAME and SRV records. This was changed to allow updates to all but SOA and NS records in unprotected name sets. To remain compatible with a previous release, use an update policy to limit RR updates.

DNS update policies are effective only if you define rules for each that grant or deny updates for certain RRs based on an ACL. If no rule is satisfied, the default (last implicit) rule is to deny all updates ("deny any wildcard * *" ).

From the Design menu, choose Forward Zones under the Auth DNS submenu to open the List/Add Forward Zones page. Select the required zone from the left pane and click the Resource Records tab on the Edit Zone page.

Use zone name listRR dns .

On the Manage DNS Server page, click the Commands button to open the DNS Commands dialog box. Click the Run icon next to Scavenge all zones.

To scavenge a particular forward or reverse zone only, go to the Zone Commands for Zone page, which is available by clicking the Commands button on the List/Add Forward Zones page or List/Add Reverse Zones page. Click the Run icon next to Scavenge zone. To find out the next time scavenging is scheduled for the zone, click the Run icon next to Get scavenge start time.

Use dns scavenge for all zones that have scavenging enabled. Use the getScavengeStartTime action on a zone to find out the next time scavenging is scheduled to start.

It is not recommended that clients be allowed to update DNS directly.

For a Windows client to send address record updates to the DNS server, two conditions must apply:

• The Windows 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 (Cisco Prime Network Registrar policies do so by default).

The Windows 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 (FQDN), the option states unambiguously the client location in the domain namespace. Along with the FQDN itself, the client or server can send one of these possible flags in the client-fqdn option:

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

• 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 request (done through the policy allow-client-a-record-update attribute being disabled, which is the default value). Only the DHCP server can set this flag.

The DHCP server returns its own client-fqdn response to the client in a DHCPACK based on whether DNS update is enabled. However, if the 0 flag is set (the allow-client-a-record-update attribute is enabled for the policy), enabling or disabling DNS update is irrelevant, because the client can still send its updates to DNS servers. See the table below for the actions taken based on how various properties are set.

A DHCP server can set the client-fqdn option to ignore the client request. To enable this behavior in Cisco Prime Network Registrar, create a policy for Windows clients and disable the allow-client-a-record-update attribute for this policy.

The following attributes are enabled by default in Cisco Prime Network Registrar:

• Server use-client-fqdn—The server uses the client-fqdn value on incoming packets and does not examine the host-name. 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 use-client-fqdn only if you do not want the server to determine hostnames from client-fqdn, possibly because the client is sending unexpected characters.

• Server use-client-fqdn-first—The server examines client-fqdn on incoming packets from the client before examining the host-name option (12). If client-fqdn contains a hostname, the server uses it. If the server does not find the option, it uses the host-name value. If use-client-fqdn-first is disabled, the server prefers the host-name value over client-fqdn.

• Server use-client-fqdn-if-asked—The server returns the client-fqdn value 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 the client-fqdn value.

• Policy allow-client-a-record-update—The client can update its A record directly with the DNS server, as long as the client sets the client-fqdn flag to 0 (requesting direct updating). Otherwise, the server updates the A record based on other configuration properties.

The hostnames returned to client requests vary depending on these settings (see the table below).

Windows 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 so that the client can request a dual zone update. To enable a dual zone update, enable the policy attribute allow-dual-zone-dns-update.

The DHCP client sends the 0 flag in client-fqdn 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 secondary zone in the behalf of the client. If both allow-client-a-record-update and the allow-dual-zone-dns-update are enabled, allowing the dual zone update takes precedence so that the server can update the secondary zone A record.

Windows relies heavily on the DNS protocol for advertising services to the network. The table below describes how Windows handles service location (SRV) DNS RRs and DNS updates.

You can configure the Cisco Prime Network Registrar DNS server so that Windows domain controllers can dynamically register their services in DNS and, thereby, advertise themselves to the network. Because this process occurs through RFC-compliant DNS updates, you do not need to do anything out of the ordinary in Cisco Prime Network Registrar.

_ service ._ protocol . name ttl class SRV priority weight port target

myserver.example.com A 10.100.200.11
_ldap._tcp.example.com SRV 0 0 389 myserver.example.com
_kdc._tcp.example.com SRV 0 0 88 myserver.example.com
_ldap._tcp.dc_msdcs.example.com SRV 0 0 88 myserver.example.com

data time name/dns/1 Activity Protocol 0 Added type 33 record to name 
“_ldap._tcp.w2k.example.com”, zone “w2k.example.com”
 
data time name/dns/1 Activity Protocol 0 Update of zone “w2k.example.com” 
from address [10.100.200.2] succeeded.

The table below describes the issues concerning interoperability between Windows and Cisco Prime Network Registrar. The information in this table is intended to inform you of possible problems before you encounter them in the field. For some frequently asked questions about Windows interoperability, see Frequently Asked Questions About Windows Integration.

nrcmd> zone myzone listRR dynamic myfile

nrcmd> zone myzone removeDynRR myname [ type ] 

w2k.example.com. 43200 SOA nameserver.example.com.
hostadmin.example.com.
(
98011312 ;serial
3600 ;refresh
3600 ;retry
3600000 ;expire
43200 ) ;minim
w2k.example.com.86400 NS nameserver.example.com 

w2k.example.com. 86400 A 192.168.2.1

0 8/10/2000 16:35:33 name/dns/1 Info Protocol 0 Error - REFUSED - 
Update of static name “w2k.example.com”, from address [10.100.200.2]

08/10/2000 14:56:23 name/dhcp/1 Activity Protocol 0 10.0.0.15 Lease offered 
to Host:'My-Computer' CID: 01:00:a0:24:1a:b0:d8 packet'R15' until True, 
10 Aug 2000 14:58:23 -0400. 301 ms.
 
08/10/2000 14:56:23 name/dhcp/1 Warning Protocol 0 Unable to find necessary Client 
information in packet from MAC address:'1,6,00:d0:ba:d3:bd:3b'. Packet dropped!

These questions are frequently asked about integrating Cisco Prime Network Registrar DNS services with Windows:

What happens if both Windows clients and the DHCP server are allowed to update the same zone? Can this create the potential for stale DNS records being left in a zone? If so, what can be done about it?

The recommendation is not to allow Windows clients to update their zones. Instead, the DHCP server should manage all the client dynamic RR records. When configured to perform DNS updates, the DHCP server accurately manages all the RRs associated with the clients that it served leases to. In contrast, Windows client machines blindly send a daily DNS update to the server, and when removed from the network, leave a stale DNS entry behind.

Any zone being updated by DNS update clients should have DNS scavenging enabled to shorten the longevity of stale RRs left by transient Windows clients. If the DHCP server and Windows clients are both updating the same zone, three things are required in Cisco Prime Network Registrar:

1. Enable scavenging for the zone.

2. Configure the DHCP server to refresh its DNS update entries as each client renews its lease. By default, Cisco Prime Network Registrar does not update the DNS record again between its creation and its final deletion. A DNS update record that Cisco Prime Network Registrar creates lives from the start of the lease until the lease expires. You can change this behavior using a DHCP server (or DNS update configuration) attribute, force-dns-updates. For example:

   nrcmd> dhcp enable force-dns-updates
    
   100 Ok 
   force-dns-updates=true 
   

3. If scavenging is enabled on a particular zone, then the lease time associated with clients that the DHCP server updates that zone on behalf of must be less than the sum of the no-refresh-interval and refresh-interval scavenging settings. Both of these settings default to seven days. You can set the lease time to 14 days or less if you do not change these default values.

What needs to be done to integrate a Windows domain with a pre-existing DNS domain naming structure if it was decided not to have overlapping DNS and Windows domains? For example, if there is a pre-existing DNS domain called example.com and a Windows domain is created that is called w2k.example.com, what needs to be done to integrate the Windows domain with the DNS domain?

In the example, a tree in the Windows domain forest would have a root of w2k.example.com. There would be a DNS domain named example.com. This DNS domain would be represented by a zone named example.com. There may be additional DNS subdomains represented in this zone, but no subdomains are ever delegated out of this zone into their own zones. All the subdomains will always reside in the example.com. zone.

In this case, how are DNS updates from the domain controllers dealt with?

To deal with the SRV record updates from the Windows domain controllers, limit DNS updates to the example.com. zone to the domain controllers by IP address only. (Later, you will also add the IP address of the DHCP server to the list.) Enable scavenging on the zone. The controllers will update SRV and A records for the w2k.example.com subdomain in the example.com zone. There is no special configuration required to deal with the A record update from each domain controller, because an A record for w2k.example.com does not conflict with the SOA, NS, or any other static record in the example.com zone.

example.com. 43200 SOA ns.example.com. hostadmin.example.com. (
98011312 ;serial
3600 ;refresh
3600 ;retry
3600000 ;expire
43200 ) ;minimum
example.com.86400 NS ns.example.com
ns.example.com. 86400 A 10.0.0.10
_ldap._tcp.w2k.example.com. IN SRV 0 0 389 dc1.w2k.example.com
w2k.example.com 86400 A 10.0.0.25
...

In this case, how are zone updates from individual Windows client machines dealt with?

In this scenario, the clients could potentially try to update the example.com. zone with updates to the w2k.example.com domain. The way to avoid this is to close down the zone to updates except from trusted sources. For Cisco Prime Network Registrar, you can use transaction signatures (TSIG) between the DHCP server and the primary DNS server for the example.com zone.

Configure the DHCP server to do DNS updates to the example.com zone and the appropriate reverse zone for each client, and use option 81 to prevent the clients from doing DNS updates themselves.

Has security been addressed in this case?

By configuring the forward and reverse zone to accept only updates from trusted IP addresses, you close the zone to updates from any other device on the network. Security by IP is not the most ideal solution, as it would not prevent a malicious attack from a spoofed IP address source. You can secure updates from the DHCP server by configuring TSIG between the DHCP server and the DNS server.

Is scavenging required in this case?

No. Updates are only accepted from the domain controllers and the DHCP server. The DHCP server accurately maintains the life cycle of the records that they add and do not require scavenging. You can manage the domain controller dynamic entries manually by using the Cisco Prime Network Registrar single-record dynamic RR removal feature.

What needs to be done to integrate a Windows domain that shares its namespace with a DNS domain? For example, if there is a pre-existing DNS zone called example.com and a Windows Active Directory domain called example.com needs to be deployed, how can it be done?

In this example, a tree in the Windows domain forest would have a root of example.com. There is a pre-existing domain that is also named example.com that is represented by a zone named example.com.

In this case, how are DNS updates from individual Windows client machines dealt with?

_tcp.example.com.
_sites.example.com.
_msdcs.example.com.
_msdcs.example.com.
_udp.example.com.

Limit DNS updates to those zones to the domain controllers by IP address only. Enable scavenging on these zones.

To deal with the A record update from each domain controller, enable a DNS server attribute, simulate-zone-top-dynupdate.

nrcmd> dns enable simulate-zone-top-dynupdate

It is not required, but if desired, manually add an A record for the domain controllers to the example.com zone.

In this case, how are zone updates from individual Windows client machines dealt with?

In this scenario, the clients could potentially try to update the example.com zone. The way to avoid this is to close down the zone to updates except from trusted sources. For Cisco Prime Network Registrar, you can use transaction signatures (TSIG) between the DHCP server and the primary DNS server for the example.com zone.

Configure the DHCP server to do DNS updates to the example.com zone and the appropriate reverse zone for each client, and use option 81 to prevent the clients from doing DNS updates themselves.

Has security been addressed in this case?

By configuring the forward and reverse zone to accept only updates from trusted IP addresses, you close the zone to updates from other devices on the network. Security by IP is not the most ideal solution, as it would not prevent a malicious attack from a spoofed source. Updates from the DHCP server are more secure when TSIG is configured between the DHCP server and the DNS server.

Has scavenging been addressed in this case?

Yes. The subzones _tcp.example.com, _sites.example.com, _msdcs.example.com, _msdcs.example.com, and _udp.example.com zones accept updates only from the domain controllers, and scavenging was turned on for these zones. The example.com zone accepts DNS updates only from the DHCP server.