Hi!

Two questions: did you enable "automatic scavenging" on advanced tab of properties on DNS server? Are any records removed if you manual try to scavenge stale resource records?

Did you enable advanced view DNS, double click record for which you believe that is stale and checkbox for stale records to be deleted is selected and you al pass the time when record can be scavenged?

Toni

Hi Toni,
so glad youre back!!!

No, the automatic scavenging was not checked.
I have checked this now.

Given that we set the scavenging settings for the subnets which have a 1 Day DHCP lease time to 12 hours refresh and 12 hours no-refresh, what should this setting be set to in order to tie in with the other settings?

One of the stale records has a time stamp of 19/1/2009 08:00:00 and has a TTL of 15 mins
I have ran a manual scavenge, and the record remains there

Most of the stale records have a time stanp of roughly 19th and 20th /1/09

You want to remove stale records as soon as possible, maybe you could start with 12 hrs interval?

Record with time stamp 19/1/2009 08:00:00 has checkbox for deletion checked and it's not removed? Did you try to close and open console once again?

I guessed you'd say 12 hours, so I set it to that.

The record you mentioned definitely had the check box for deletion checked and it has not removed.
I have closed and re-opened the console amnd refreshed too but it still remains.

The strange thing is that the REVERSE lookup zone when I look at their records (which is what I set the scavenging to 12 hours on) is all tidy - no stale records.  However, most of the machines are missing from the reverse lookup zone.

I did note when I clicked on the domain forward lookup zone that there is a setting for scavenging at the domain level, which is set to no refresh of 1 day and refresh of 7 days.

I cant set the entire domin to 12 hours refresh/no refresh as we have other servers which have longer DHCP lease times within the domain.  So, how do I configure DNS so that scavenging is performed on the forward lookup zones the same as the reverse lookup zones, only for the machines which are on the subnet that I need?

I thought doing this on the reverse lookup zone would do this but it appears not...

The reverse lookup zone appears to be OK.

If you need more clarity, please ask!

Thanks.

Scavenging is process in which DNS server decides that record is stale. Scavenging does delete records, only marks them as approved for removal.  It doesn't matter to which subnet does record ih forward lookup zone belong to. There is no such setting which would affect only some of records in one forward lookup zone. Automatic deletion is configured only on per server basis.

Hi Toni, or anybody else for that matter!

The problem I have must be a fairly common one, I'll try to make it as simpe as possible and will attach screen shot to clarify.

One domain with multiple sites.
Each site has a 2003 DC running DHCP and DNS on it's own subnet
Some sites have the default 8 day DHCP lease time, others have a 1 day
I cannot have stale records in DNS

I configured the scavenging on the reverse lookup zones for the subnets which have a 1 day DHCP lease time to 12 Hours no refresh and 12 hours refresh

The reverse lookup zones for these subnets look healthy

I still have stale records in the forward lookup zones though, for machines that have been scavenged in the reverse lookup zones (ie they dont exist in the reverse any longer, but remain in the forward)

As I understand it, DNS marks the record as stale, then a server is configured to automatically scavenge the records on the time scale that I set

If I set a site DNS server to perform a scavenging cycle, will it scavenge records for the entire domain (ie all zones/subnets) or just it's own subnet?

Given the varying DHCP lease times on different sites, I ideally need different scavenging settings in the forward lookup zone for those sites with 8 days DHCP lease than those wth a 1 day lease time.  It apears this isnt possible, so am I safe to configure a 12 hour refresh and 12 hour no refresh for the forward lookup zone, given this scenario?

Stale records in forward lookup zones will not be deleted if a computer registers its own host (A) RR at startup and is later improperly disconnected from the network, this happens very frequently with mobile computers.

Maybe you could configure DHCP to register both A and PTR record on behalf of the client but I'm not sure if this will help with records for disconned computers.

Again, unfortunately, no refresh and refresh interval are specified either per server or per zone. Nothing to configure on per record basis.

Do not configure short intervals for your forward lookup zone, because you might end up deleting some records too quickly, but records for disconnected computers might still remain.

You can ask moderators to send out question alert and post your question in additional topic areas, I would recommend DNS and Active Directory as well.

OK - tearing my hair out now.

I just need DNS to be consistent in forward and reverse lookup zones as out deployment software depends on this info being correct.

I have different DHCP lease times - some site 8 days, others 1 day

How do I set up my DNS/scavenging for this to work!!!????

> No refresh set to 12 hours, Refresh also set to 12 hours

Your Refresh Interval is too short if you ask me.

While that might be perfect for the DHCP leases running with 1 day it's hell for absolutely everything else. Most importantly it's hell for your Domain Controllers Service and Host Records. For that to make sense we must know how records are updated.

First consider the Servers:

 * Service Records (to locate Domain services) - Registered by the NetLogon Service on each Domain Controller. Refresh Interval is 24 hours (or whenever the service is restarted).
 * Host Records for the domain, CNAME record for the server (under _msdcs) - Registered by the NetLogon Service on each Domain Controller. Refresh Interval is 24 hours (or whenever the service is restarted).
 * Host Records for each Server - Registered by the DHCP Client service (even if the address is static). Refresh Interval is 24 hours (or whenever the service is restarted, or "ipconfig /registerdns" is run).

Then the Clients:

* Host Records for DHCP Clients when DHCP is updating - Registerd by the DHCP Server. Added on lease assignment. Refreshed once 50% of the way through the lease (or whenever "ipconfig /release" and "ipconfig /renew" is run).
* Host Records for DHCP Clients when Client is updating (when DHCP is not) - Registed by the DHCP Client service. Refresh Interval is 24 hours (or whenever the service is restarted, or "ipconfig /registerdns" is run).

Automatic removal of "stale" Service Records or Host Records for the servers is likely to cause you quite a bit of bother. Therefore the minimum value you should consider for the Refresh Interval is either 24 hours or 50% of the longest DHCP Lease (whichever is larger).

As Toni says above, the Scavenging settings are per zone, not per site.

Now, Aging and Scavenging...

The very first thing that must be noted about Aging is that it places a lock on the Zone when you first enable it. The zone is locked for the duration of the Refresh Interval. That is there as a safeguard to allow all records to update before Scavenging can run against the zone. You can see the value if you select View / Advanced then take a look at the Aging properties.

On top of this, before Aging is enabled the TimeStamp used to test whether or not a record is stale is not replicated, you will discover that different DCs have different Time Stamps for some records. That should clear up very soon after Aging is enabled.

If you have a lot of variation in DHCP Lease you might simply consider stopping the update DHCP is pushing into DNS (on all DHCP servers). When this is done the client will update directly(1), that will be based on a uniform 24 hour Refresh interval and will be performed by the DHCP Client service (as above).

(1) Do note that clients will not be able to update records added by the DHCP server (check the Security tab of the record if you're curious). Those would have to be removed or scavenged prior to the client adding a record they can maintain.

I'll leave it for your final consideration, but I advise the following:

1. Set the Refresh Interval to 2 Days on the Forward Lookup Zone (I like that as a "safe" minimum value)
2. Stop DHCP updating DNS
3. Enable Scavenging with a Period of 1 Day on one of your servers (just executes the task once a day)
4. Wait for 9 days (for the record with the longest lease to be Scavenged)
5. Audit stale records

I realise that's a long wait but patience is generally a requirement for a long-running process like this. You could audit and delete records added by the DHCP server. Or you could apply a Refresh Interval of 4 days if you prefer.

Any thoughts?

Chris

Just to explain, that 12 hrs no-refresh and refresh intervals were set only for single reverse lookup zone for subnet which has lease time 1 day, and this was my suggestion in previos question. This short lease time on one subnet is culprit of the problem in the first place.

Understandable :) Makes a lot of sense in that context. It's only really the Forward Lookup Zones where I'd avoid setting it :)

Chris

Hi Chris, and thanks for your thorough response.
I've been researching the topic now for over 3 days continuously but am struggling to come up with a strategy that works for us and wanted to take some expert advice.

Our issue lies not least of all in our dependency for DNS to be absolutely spot on, and as a food manufacturing company we have laptop users who hop from site to site on a day to day basis, from subnet to subnet.

These machines need to be reporting correctly into DNS, the problem being that some sites are set to 8 days DHCP and others to 1 day.

My task is to establish a consistent record for our software distribution tool to be able to deploy fixes group wide to any machine in the world, which is why I was looking at 12 hours no refresh, and 12 hours refresh.

In total I am looking at just over 1500 machines on the network, roughly 50% would be laptops moving from location to location.  If the records for these are incorrect I get deployment failures which is a major task to track which machines were where any why the record was incorrect for hundreds of machines!

If I set the refresh interval to 2 days for the forward lookup zone and leave the no refresh at 12 that gives any machine 2 days to re-register into DNS and refresh it's presence on the network.

Sounds feasible.

Scavenging I have enabled for one server only, currently running every 12 hours.  I could reduce this to 1 day as per your suggestion but bearing in mind we are a 24/7/365 across the world with several time zones, I'm more comfortable with 12 hours or do you feel this is excessive?

The reason I have DHCP updating DNS is due to the number of laptop users who will simply disconnect at a moments notice and not unregister their <A> records!

Thank you very much for your assistance and I greatly value your or any others' further comments.

Rob.

The first part is the tricky one because it's a fair bit of running around.

1. Delete the _msdcs folder from the Forward Lookup Zone
2. Create a new Forward Lookup Zone called _msdcs.yourdomain.com (Primary, AD Integrated, allow Dynamic Updates)
3. Create a new Delegation in yourdomain.com. Manually add an NS Record to this delegation for each DC (these NS records will have to be manually maintained if you add or remove a DC).
4. Configure No-Refresh and Refresh to 7 days each (defaults) on the _msdcs.yourdomain.com zone
5. Restart NetLogon on every Domain Controller (to register the Service Records in this new zone)

We can't do anything about the Host (A) records for the Servers, but we may as well protect our Service Records a little.

Then we can look at configuring the main zone:

1. No-Refresh to 1 Hour (the shortest it will allow)
2. Refresh to 1 Day
3. Scavenging Period to 1 Day, although there's no harm in 12 hours really.
4. Allow clients to update themselves (stop DHCP doing it)

Now we have a total Aging period that barely exceeds our shortest DHCP lease, any client that pops in, registers a record and goes away will be removed almost as soon as the lease expires.

Any client that registers on one DHCP server, then moves site will have permission to update their own record (the IP will change, a duplicate will not be created).

Any client that stays on one site will issue a Refresh once every 24 hours, maintaining the record.

The primary disadvantage of this is that we have to wait for all the records created by DHCP to disappear. The clients won't have permission to update those themselves.

In an ideal world I'd increase the DHCP Lease to a minimum of 4 days because you'll have a fair bit of replication traffic caused by that lot.

Check that your zone is set to replicate to "All DNS Servers in the Active Directory Domain" (or in the Forest). If set to "All Domain Controllers in the Domain" all of those records / constant changes will be pushed into the Global Catalog as well (which we don't really like).

Chris

I wasn't at all clear above. The Delegation we're creating is for _msdcs (that should be the name of the child domain). Basically we need to give systems querying the DC a way to find the new separated zone.

Chris

Wow Chris,
you certainly know your stuff but that's a scary task to undertake, and I'm confident that my senior manager wouldn't allow it even if i wanted to!

Within that _msdcs folder under the forward lookup zone I have no less than 48 name servers containing 4 different domains (this domain is a subdomain of our root domain)

Gcg.net - root
cs.gcg.net - central services
gc3.cs.gcg.net (the main user domain)
gc1.cs.gcg.net (another arm of the bsiness)

So there's no way I can remove it - it also encompasses 36 sites each on their own subnet so the potential for damage is very high - and could go into millions of pounds, so i have to work with the topology that I am presented with.

Given that I know you completely understand my scenario now, going forward, what would you recommend is the best practice, or is it as it remained before your last post?

Sorry to be such a nuiscance.

Rob.

Hey Rob,

It's not a nuisance, the concerns you have are valid.

The _msdcs folder I'm speaking of should reside under the child domain gc3.cs.gcg.net. That would be the version we're looking to delegate and protect from Aging (ideally the same would happen to _sites, _tcp and _udp). Does that still effect 48 name servers?

If it's not possible / practical then that's fine, we can work within those constraints. Instead, is it possible to consider increasing the DHCP Lease duration in those sites using 1 day leases?

I'd only like to do so because every day of No-Refresh reduces replication traffic, and every day of Refresh gives systems another chance. I just don't like cutting it so close to the wire by using a 1 day refresh.

The note about checking the replication scope for the zone (in the properties for the zone) mentioned above is especially valid and important if we run in a Forest. While the dnsRecord attribute isn't replicated into the Global Catalog many of the other attributes (whenCreated, whenChanged, etc) are. Such a low No-Refresh means that the contents of the GC change on an very regular basis, not something that's desirable in a large domain / forest.

Chris

Hi Chris
The zone is set to replicate to "All DNS Servers in the Active Directory Domain" (or in the Forest).  So no problems there.

The sites that are set to 1 day DHCP leases are done so because of the number of personnel who roam from site to site, eating up our IP addresses which is why it's so important to make sure that we can reclaim them at the end of the day, and keep DNS consistent with the DHCP lease table

Some of the sites in question have the warning ! mark next to the DHCP server due to them being  95% addresses leased out, so we're really that close to the bone.

It's vital that we keen DHCP and DNS consistent and up to date, bu I dont want to kill the network WAN links!

To recap at present the forward lookup zone is set to 12 hours no refresh, 2 days refresh - the only problem I see there is that a DNS record can be over 3 days old before it gets scavenged, by which time the deployment tool will have a different record for it, and once it compared the two (its own record for the machine vs DNS) will fail :(

IP Leases are set to 1 day for 7 sites, the rest remain at 8 days lease duration.

Hi Chris,
thanks for all your help on this.
I also have onther issues regarding DNS zonetransfers to address bythe looks of things but thats a separate issue.

I have set the no refresh to 12 hours for now, and the refresh to 1 day.

I will monitor how this performs.

One question you mention the risk to critical system DNS records.

All our critical servers naturally have static IPS so what is the risk you speak of?


Once again, thankyou, I am in your debt.

Rob.

> All our critical servers naturally have static IPS so what is the risk you speak of?

Indeed, but unless you have manually added records to DNS they will be dynamically registering records. That means their records are subject to Scavenging in the same way as your client records.

That's why I've been so keen on staying a bit away from the 1 day minimum :)

Chris

Incidentally, I wrote a few scripts rather a while ago that will allow us to find the state, and TimeStamp of any record within an AD Integrated zone. They may be useful for auditing the behaviour of Scavenging over time if you want them.

Chris

Hi Chris,
back in the office again....apologies for the late respopnse!

Yes please if you have them they would be extremely useful - can you upload them to here or if you could send thm to me email address
 
rob.berry@greencore.com

I wish I could assign more than 500 points.  I owe you a beer!

They may as well go here, they're on my blog anyway. And they're all variations on a theme. Everything is in PowerShell, it's just easiest for this kind of thing. PowerShell is here:

http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx

That can be installed anywhere, doesn't need to be on the DNS server itself. Then it's just a case of copy and paste into the shell.

It's quite easy to do a lot more filtering, if you wanted to return only static records, or only stale records and so on.

Chris

# Format-Table is included at the end of the query to make the output tabular. 
# Remove "| Format-Table" and it will default to Format-List to show full detail.
# Otherwise the output can be piped to CSV with | Export-CSV -Path "filename.csv"
 
$ServerName = "anyDNSserver"
$ContainerName = "somedomain.example"
 
# Returning Service Records
 
Get-WMIObject -Computer $ServerName `
  -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_SRVType" `
  -Filter "ContainerName='$ContainerName'" `
 | Select-Object OwnerName, TTL, Weight, Priority, Port, DomainName, `
  @{n="TimeStamp";e={ `
    if ($_.TimeStamp -eq 0) { "Static" } `
      else { ((Get-Date("01/01/1601")).AddHours($_.TimeStamp)).ToLocalTime() }}} | Format-Table
 
# Host (A) Records
Get-WMIObject -Computer $ServerName `
  -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_AType" `
  -Filter "ContainerName='$ContainerName'" `
 | Select-Object OwnerName, TTL, RecordData, `
  @{n="TimeStamp";e={ `
    if ($_.TimeStamp -eq 0) { "Static" } `
      else { ((Get-Date("01/01/1601")).AddHours($_.TimeStamp)).ToLocalTime() }}} | Format-Table
 
# Pointer (PTR) Records - Only valid for Reverse Lookup Zones ($ContainerName).
# e.g. $ContainerName = "10.in-addr.arpa" or $ContainerName = "1.168.192.in-addr.arpa"
# Failure to use the correct ContainerName will result in a "Generic Failure"
 
Get-WMIObject -Computer $ServerName `
  -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_PTRType" `
  -Filter "ContainerName='$ContainerName'" `
 | Select-Object OwnerName, TTL, RecordData, `
  @{n="TimeStamp";e={ `
    if ($_.TimeStamp -eq 0) { "Static" } `
      else { ((Get-Date("01/01/1601")).AddHours($_.TimeStamp)).ToLocalTime() }}} | Format-Table

Select allOpen in new window

Brilliant Chris,
thank you so much for all your help.

Are you up for some zone transfer problems next week...  ;-)

Sure, always fun :)

Chris

Chris' knowledge was outstanding and was able to explain it at a comfortable level.
I am now far more comfortable with my understanding of DNS, scavenging, refresh and no refresh.
The man is a legend.