Optimizing your network to keep your DNS squeaky clean

I have run into this issue several times: My customer has a fairly large network, with several subnets. They have wireless clients unplugging from Ethernet and dashing to conference rooms, then closing their laptop and heading home. The client starts a VPN session and continues working… Then, their spouse needs to use the computer, so the VPN connection gets dropped. They reconnect again later.

So, how many DNS records does that make? Lets count:

The Ethernet connection from the office has one. The Wireless connection may have several, depending on how many subnets the worker crossed going to that conference room, and the VPN may have several of them. 5-6-7 ? 8? 10 Addresses? And there are addresses from their home network as well. Ouch. Which one does the machine really have? And what if they stop at a local coffee shop on the way? They may have an address from the coffee shop’s subnet as well. That’s a load of stuff to pick through. All validly registered, but only one address really works.

The worker calls the helpdesk to get assistance with some application on the machine. The help desk tries to connect, but finds that they are hitting someone else’s machine.

Time to call IT to get things cleaned up so the worker can do their job. IT has to open up the DNS console, find all the records for that machine, figure out which is the most recent, and delete the rest.

One of my customers was getting calls like that 8-10-20 times a day. It was bad enough that they got orders to ”Fix that problem!”

That’s where I came in. Since this is a production network, we had to carefully do this step by step, avoiding any disruption to operations.

This sort of problem requires a system-wide fix. Just turning on DNS Scavenging won’t do it. We need to actually manage the address space properly. And do it in a way that doesn’t stop business.

Step one: Enable scavenging

Before starting anything, we made sure that scavenging was not enabled on ANY of the DNS servers in the environment.

Machines refresh their host records every 24 hours. Because of that, we really don’t want to lower the scavenging period below 2 days to avoid touching all the machines. Servers have to stay visible. Also, DNS time stamps are not updated in Active Directory until you turn on Scavenging on a zone. So, we set the no refresh/refresh interval to 2 days each, and “enable” scavenging on each of the zones where the user may appear (including reverse lookup zones.)

We let this run for several days to verify that time stamps were indeed being updated. (Slow and careful, like I said. We don’t want to lose the static records and so on, so careful analysis of the contents was done.)

A quick side note: Using the Windows Server 2008 management tools provides a much easier way of looking at the time stamps. They are displayed without having to dig into individual records, and makes the job easier.

Once it was clear that everything was updating properly, we pulled the trigger on the server selected to do the scavenging. We gave it a period initially of 3 days. So, over a weekend, it scavenged, and removed a whole bunch of old records.

Step 2: Adjust DHCP credentials and configuration

The next step (done in parallel with the above operation) was to setup a dnsupdateproxy user on all the customer’s DHCP servers. We dropped that user into AD and started testing. Knowledge Base article 932464 describes the cleanup interval used. KB article 837061 goes over the processing of expired pointer records. We bumped the queue length up to the maximum to make sure that the DHCP server could do the updates quickly. We also configured DHCP to always register the clients, and delete the records when the lease expired.

The next step was to lower the lease period dramatically on the wireless and VPN subnets. The customer’s VPN solution was a major brand name concentrator, which used IAS for user authentication. We dropped the leases for those pools down to 3 hours. That means that after 3 hours, the records will vanish from DNS if the client has not renewed the lease.

Step 3: Apply group policy

The company had specific OUs in AD for wireless and VPN users. We applied a group policy to prevent registration of these records in DNS. The reason for this: some clients were still registering records in DNS that should not be. VPN users needed to “log on to domain using dial up networking” to get the group policy applied. That also allowed distributing a registry change that would disable that registration in the future, as described in KB article 246804.

The group policy changes we made are shown in the screen shot below. This policy was applied to the OUs where the wireless capable machines were located, and in the VPN users OU. It would be possible to apply this to all client machines, but you would still need to have the servers refreshing their host and pointer records.

The Results?

The first week that the final changes were applied, the customer’s calls to helpdesk for this issue were down to one per day. After they found that there were work at home users that were not covered by the policy, they added that OU to the group, and there were no calls the next week.

In short, taking a bit of time to do this methodically netted a good result, and lower maintenance costs long term.

Timing could not have been more appropriate – I have been tasked with DNS cleanup due to the same type of issues.

Thanks!

10 years ago

bill

Glad the entry helped. Keeping DNS optimized takes some careful design, and there *are* things that will cause problems, long term. One of the biggies is "guests" who have machines that are not part of your domain. (And worse yet, are members of another domain.) — To keep things running smoothly, have a guest subnet… and DHCP set up for short leases on it. Don’t have DHCP handling DNS on that subnet (and only that subnet)… That way, the visitors won’t start stepping on the rest of your infrastructure.

NAP (with Server 2008) – and 802.1x wired and wireless will help keep things tidy as well, forcing non members, or those that don’t handle your corporate standards off to a vistor subnet…

5 years ago

Anonymous

This is a collection of the top Microsoft Support solutions to the most common issues experienced using

5 years ago

Anonymous

These are the top Microsoft Support solutions to the most common issues experienced using Microsoft Windows

5 years ago

Anonymous

We’ve gathered together the top Microsoft Support solutions for the most common issues experienced

5 years ago

Anonymous

These are the top Microsoft Support solutions for the most common issues experienced when using Windows

5 years ago

Anonymous

As a Microsoft Premier Field Engineer I frequently get asked for more information on Active Directory topics. Most of the time I end up passing along one or more of the links in today’s post. This list will be extremely valuable for anyone who wants

4 years ago

Anonymous

Top Microsoft Support solutions for the most common issues experienced when you use Windows Server 2008

4 years ago

Anonymous

Top Microsoft Support solutions for the most common issues experienced when you use Windows Server 2008

4 years ago

Anonymous

Top Microsoft Support solutions for the most common issues experienced when you use Windows Server 2008

4 years ago

Anonymous

Top Microsoft Support solutions for the most common issues experienced when you use Windows Server 2008