Over the years I've seen many DNS issues and many come because of the integration of DNS and DHCP and not a complete understanding of the proper setup. 

Several issues could include

• Stale DDNS records
• Dynamic DNS records that don't update with proper IP
• DNS records that disappear by themselves

All these issues are results of incorrect configuration and could be a simple to fix as one checkbox.  So lets dive in.

Stale DNS records 

These are the result of a host that no longer uses that host entry and thus that entry is invalid.  Typically these may be old computers that have long since been removed from the domain, or even laptops that don't regularly connect to the domain.  It can even be a security related issue on the DNS record itself preventing the computer from properly updating its own DNS record  The record could be manually deleted, but DNS has a built in system to clean up the records.  This system is called: Aging and Scavenging.

Each time a host that is configured to use Dynamic DNS first comes online, it will attempt to register its DNS record, including the timestamp it was created.  It the record already exist, it will just update the timestamp of that record.  This timestamp is what aging will use to determine if the record is considered stale.  If a host has not come online in a long time, its timestamp will be old.  The aging interval that you configure on the DNS zone will flag a DNS record as stale if its timestamp exceeds the duration configured.  The aging interval is a combination of two values.  A no-refresh interval and a refresh interval.  These terms can be very confusing.  I'll try and explain them a little better than Microsoft does.

• No-refresh Interval - Its sole purpose is to prevent excessive DNS replication.  As mentioned earlier, when a dynamic DNS host comes online it will register its DNS record or update the timestamp.  So in the scenario of a computer rebooting 20 times a day for testing would cause that DNS record to be changed and thus replicated 20 times.  Multiply that by a large corporate environment with tens of thousands of computers and you could have quite a bit of replication just for DNS records that aren't really changing.  Since typical computers will retain the same IP address for several days (via DHCP) there really isn't a need to update the timestamp every reboot.  So the no-refresh interval is used to prevent the record from being updated to prevent unneeded replication.  In a DHCP scenario of a 4 day lease, DHCP will attempt to renew the IP address at 50% of the addresses lifecycle.  This is a good rule of thumb for setting the no-refresh interval.  Set it to 50% of your DHCP scope.   What do you do when you have many scopes with different intervals?  I try and follow the majority setting, so if most scopes are 4 days, I'll set it to that.  DNS aging/scavenging is set at a DNS zone level and overlapping DHCP scopes in the same DNS zone with different lease durations can be tough to find the best compromise.

• Refresh interval - Once the no-refresh interval has lapsed, the record can now be refreshed when a dynamic DNS host comes online.  The refresh interval is the period of time between the no-refresh interval lapsing and when a record can become scavenged.  So the total scavenging interval is combination of the two.  So back to our scenario of a 4 day lease.  You would configure the no-refresh interval to 2 days, and then the refresh interval to 2 days. 

Once you have the intervals configured properly and you enable scavenging on a scope, DNS will scavenge records once every 24 hours.  You usually only need to enable scavenging on one DNS server as the record deletions will be replicated to other DNS servers.  I usually keep two servers doing scavenging just to ensure if one of my DNS servers goes down, scavenging will continue working.  You can confirm DNS scavenging is working by looking the DNS event logs for eventid 2501 

Dynamic DNS records that don't update with proper IP

In see this scenario lots with manually created records, wireless access points, or VPN clients.

Manually or statically created DNS records don't store timestamp information and thus never age.  So if a record was manually created, the host will not have the proper security to update the record.  Instead of playing around with security, I will usually just end up deleting the static record and performing an IPCONFIG /Registerdns from the command line of the client.  This will force the client to re-register itself in DNS and create the record if needed.  This time with proper security.

Wireless access points and VPN clients not updating the DNS record are usually the result of incorrect DHCP server settings.  Once again poorly explained options. 

When you create a DHCP scope there are advanced options that need to be configured on that scope to make sure DDNS host are properly updated.  So under the scope properties, you'll see three tabs.  Select the DNS tab.  There you'll see DDNS options.  Pretty simple right, but one setting is particularly important to get right.  You may be tempted to select the option to "Always dynamically update DNS A and PTR records".  Why not since I always want it to happen.  The problem with that setting is it doesn't create the DDNS records with the correct security and thus don't update properly.  Select the option "Dynamically update DNS A and PTR records only if requested by the DHCP clients".  This option creates the records with the proper security so when wireless or vpn hosts come online, they properly update their own DNS records.

DNS records that disappear by themselves

I've seen this in a few scenarios.  One is having much too aggressive scavenging/aging set.  Never set combined aging interval at less than 24 hours.  You may be tempted to set this low to keep DNS always clean, but this can actually take down your Active Directory.  By default the Domain Controllers will register their SRV records when they come online then after a few rapid refresh intervals, then they will revert to a slow refresh interval and only refresh SRV records once every 24 hours.   SRV records are DDNS records and they can be scavenged.  So aging set less than 24 hours can cause the SRV records to disappear and cause all kinds of issues.

If you disable the DHCP client service on a client that has a DDNS record it can remove the DDNS record from DNS.  As funny as it seems the DHCP client service holds the APIs for performing DDNS updates.  So the DHCP client is needed for DDNS to work.  This is why this service is required on Domain controllers despite having statically assigned DNS entries.

Another scenario is when an admin uses the DNSCMD interface to manage DNS and selects the /AgeAllRecords option.  This one is nasty because it will convert all your Static DNS records that you may never want aged to dynamic DNS records.  Since they now having aging information, they have the potential to get aged and scavenged.  The worst part about this scenario is that since they are statically created records, they never get the proper security for the host to update the timestamp, so they will age out and disappear.

One last scenario I've seen is an external host VPNing into our environment that had the same name as a host in our environment.  We had a short DHCP lease time (1 hour) and set the scope to delete the DDNS A and PTR records when the lease expires.  In this case we had the scope incorrectly set to "Always dynamically update DNS A and PTR records" and thus set the incorrect security on the record instead of the hosts computer account and thus caused the record to disappear after the lease expired.

I hoped this helps.  Let me know what you think.