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:
- Enable scavenging for the zone.
- 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
- 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.
The example.com zone then might include these records:
example.com. 43200 SOA ns.example.com. hostmaster.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?
To deal with the SRV record updates, create subzones for:
_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.