Networking

Tightening Active Directory-Integrated DNS zone aging


Active Directory-Integrated DNS zones are unique in a way that the Windows clients may be authenticating to the network from a foreign network. This is to prevent Active Directory registrations that can cause record confusion with standing records from reverse lookups. Consider the following scenario; a mobile user with a Windows-based client connects to your network through a VPN technology from a hotel, home network, airport, coffee shop, or other wireless hot spot. The address that would be assigned from that public network may be the same IP scope as that of your internal network. In the event that the remote network assigns the remote client an IP address of a server record on your internal network, the client may register the foreign network address on your internal network. Further, if that address is a record that is already in use, that remote client may have difficulty accessing that resource and there would be an IP address with multiple DNS registrations. Determining the root cause of such issues can be difficult due to the transient nature of the remove connection. Tightening the aging for the DNS zone can help reduce the risk of this situation.

The default configuration is for records to scavenge over a 7 day period. For the Active Directory-Integrated zone that contains the clients that may be subject to this situation. Changing the refresh and no-refresh intervals to a shorter timeframe can make some of these issues dissolve before they become greater. To configure the aging, right-click on the Active Directory-Integrated zone and select properties, the aging button, and configure in a way that would work for your environment similar to the figure shown below:

 Configure aging

Once you tighten the aging interval, new records will be able to escape duplicate registrations by having the tighter timeframe. If the computers that may connect remotely are contained within a separate Active Directory domain from the server resources, the specified configuration can be applied more granularly. When managing multiple Active Directory-Integrated zones, this same task can also be completed with the dnscmd command with the /ageallrecords command.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

11 comments
jeff
jeff

What we are up against is a remote support issue for those coming in to the enterprise over vpn. It has a dedicated subnet but a pool of 254 addys. Every time the remote user logs on he gets a new address. So trying to remote support over VPN is next to impossible by hostname and often we run into duplicate IPs assigned to multiple hosts. The only fix is to go delete the bogus a records in DNS. Sometimes these remote users may be on 3 or 4 times in a single day so even though we have pared back the scavenge cycle times we still have issues. Less than before , but they are still there. Looking for a way for the Cisco VPN concentrator to not only report the new a record but also to say 'please delete any old ones for this host' If anyone has this magic potion I'd love to know how :) Jeff

patrick
patrick

I do have a question though. What do you do about non-ad integrated records (no time/date stamps)? How does one actually confirm a record short of deleting them and waiting for the scream? Well, we ran an export and pinged them, which at least confirmed the dead records, reducing our static entries by half. But there is no sure-fired way of ensuring a static or old Windows 2000 record is valid other than deleting them and waiting for the blood curdling holler or finding the owner of that record (waiting for responses from developers... yeah that's fun) and confirming it's need. Or, when you "migrate" to 2008 AD, go ahead and make a new domain, wait for the records to age out of the old domain, ping the leftovers and import the responders into the new. How you determine what is a record that is needed...? Let me just say "good luck." But how do you "prevent" trashing your netbios records with domains from coffee shops? If it was a security problem I might be concerned... ;)

Michael Kassner
Michael Kassner

Hello Rick, A very interesting article and I hope you can eliminate a point of confusion on my part. I do not see where the IP address assigned to the remote computer from the public network affects the office network the remote user is tunneling into. The VPN application as I understand creates a virtual network adapter that gets assigned what is considered the intranet IP address from the office network's DHCP server. Every once and awhile I have a unique problem with a VPN and I wonder if I am missing something. Maybe this is culprit.

rwessling
rwessling

Jeff, We looked at our Cisco VPN gateway and it doesn't appear that there is an option to specify DHCP lease durations. I would think that scavenging is your best option for combatting this issue. What do you set your scavenging interval to?

bullens
bullens

Patrick, The way to remove those nasty stale records (with MS DNS and DHCP at least) is to enable scavenging not just on the zone but also on the server (this will work for not only AD integrated but none-integrated zones), then enable the DHCP option "002 Microsoft Release DHCP Lease on Shutdown option" from the "Microsoft Windows 2000 options" vendor class; which will result in DNS staying nice and fresh and accurate, as the clients records are auto removed from DNS on shutdown and any other recordds will be cleaned by the scavenging on the DNS server. Also worth a note that if you are using WINS to check that it is scanvagine also.

patrick
patrick

I think Rick's point was that when you have a local "coffee shop" connection utilizing the same scope of the internal VPN you could see a registration occur of a doamin not in your network. A simple net view /domain can prove the point. At any hour you can see quite a disparity of domains that you KNOW are not in your perview. And I suspect Rick is right that it this "cross over" of scope utilization that is causing the problem. Of course we all know the registration of a doamin name in a 2003+ AD network has little to no impact on your security without the correct authentication or trust.

jeff
jeff

We have them set to 2 days on the server. At the zone level it is set to 2 days - no refresh interval and 3 days refresh interval. We noticed a few a records from web server aliases got caught in the crossfire but suspect they were set wrong to begin with do delete if stale. thanks for looking at that. We'll be revisiting this until we find a happy medium I guess. Jeff

rwessling
rwessling

I just set up this very same scenario last week in DNS and DHCP, as we are having a problem with stale records. Rather than manually remove the records I am waiting to see how well the scavenging and DHCP Release on shutdown works. Other than the suggestions in the lead post, do you suggest a good interval for aging and scavenging? I just went the defaults for now and figured I would tweak from there. Thanks!

b4real
b4real

Yes, I am getting at scope cross over. And making this tighter helps reduce the time and risk that this can happen.

bullens
bullens

It depends upon your DHCP lease time, and also they way people use there computer, i.e. do they shut down every night or leave their PC's on forever and a day? I personally have adjusted the DNS scavenging to DHCP lease time + 1/3 of DHCP lease time, that way you are at least you are sure that the records in DNS there are being scavenged are stale. I personally think that this is an option that MS should have turned on as default when an MS DHCP is initially configured, it seems so obvious and works very well at keeping DNS accurate. The only thing to note is that if the PC is not shutdown correctly then DHCP will not be able to clear DNS, so this is where scavenging comes into play.

patrick
patrick

...causes other issues. Namely a registration overload would result if you have a significant number of nodes. I don't see her recommendation as being anything more than a dirty band-aide, sorry.

Editor's Picks