DNS Scavenging questions

I'm currently planning to perform DNS scavenging on one of our primary
forward lookup zones (AD integrated). We have 3 Win2003 Domain Controllers
all running DNS in our environment.

Before proceeding, however, I have a few items that need some clarification
and I would appreciate any advice from those in the know:

[1] Several days ago I went through the DNS records for this zone on our
primary DC to remove the "delete this record when it becomes stale" checkbox
from our static entries (server dns records). I went back today to recheck
them and I see that once again they are set to be deleted when they become
stale again. Why is this happening? I see on the other DC's that the same
record is not set for deletion though.

[2] In the forward zone I want to scavenge, there are the following sub
folders with records that are all set to delete when they become stale:

- _sites\Default-First-Site-Name\_tcp\ (_ldap record for each DC)
- _tcp (_gc, _kerberos, _kpasswd, _ldap records for each DC)
- _udp (_kerberos, _kpasswd records for each DC)
- DomainDNSZones (A record for each DC)
- DomainDNSZones\_tcp\ (_ldap record for each DC)
- DomainDNSZones\_sites\Default-First-Site-Name\_tcp\ (_ldap record for each
DC)
- ForestDNSZones (A record for each DC)
- ForestDNSZones\_tcp\ (_ldap record for each DC)
- ForestDNSZones\_sites\Default-First-Site-Name\_tcp\ (_ldap record for each
DC)

Should I be unchecking the "delete this record when it becomes stale" for
all these records on all 3 domain controllers?

[3] I realize that I must set scavenging at the server level and at the zone
level but do I want to set scavenging on all 3 DC's or just one? The DNS
zones are set to replicate "to all DNS servers in the Active Directory
domain".

Appreciate any feedback or advice anyone can offer on this matter. Thanks.

Hi Barkley Bees,

Please see in-line.

> [1] Several days ago I went through the DNS records for this zone on our
> primary DC to remove the "delete this record when it becomes stale" checkbox
> from our static entries (server dns records). I went back today to recheck
> them and I see that once again they are set to be deleted when they become
> stale again. Why is this happening? I see on the other DC's that the same
> record is not set for deletion though.

The servers in question will still have permission to update the record.
They will update the timestamp, and therefore update that box. If you
see differences between DCs check replication (or allow time for
replication).

I advise you allow those records to be scavenged anyway. For Host (A)
and Pointer (PTR) records the DHCP Client service will update each once
every 24 hours (this applies to clients with static IP addresses).

Making them completely static just gives you more work to do should you
decommission a server in teh future.

> [2] In the forward zone I want to scavenge, there are the following sub
> folders with records that are all set to delete when they become stale:
>
> - _sites\Default-First-Site-Name\_tcp\ (_ldap record for each DC)
> - _tcp (_gc, _kerberos, _kpasswd, _ldap records for each DC)
> - _udp (_kerberos, _kpasswd records for each DC)
> - DomainDNSZones (A record for each DC)
> - DomainDNSZones\_tcp\ (_ldap record for each DC)
> - DomainDNSZones\_sites\Default-First-Site-Name\_tcp\ (_ldap record for each
> DC)
> - ForestDNSZones (A record for each DC)
> - ForestDNSZones\_tcp\ (_ldap record for each DC)
> - ForestDNSZones\_sites\Default-First-Site-Name\_tcp\ (_ldap record for each
> DC)
>
> Should I be unchecking the "delete this record when it becomes stale" for
> all these records on all 3 domain controllers?

No.

The NetLogon Service on the DC will maintain those registrations,
performing a Refresh once every 24 hours.

> [3] I realize that I must set scavenging at the server level and at the zone
> level but do I want to set scavenging on all 3 DC's or just one? The DNS
> zones are set to replicate "to all DNS servers in the Active Directory
> domain".

Just one. The settings on the zone will replicate to each server. And
the Scavenging task (Server Properties / Advanced) should only run on
one DNS server.

Because of the update intervals mentioned above I strongly recommend you
do not consider setting the Refresh Interval lower than 24 hours.

HTH

Chris

Thanks for your reply Chris, much appreciated.

[1] I went ahead and change the dns records for our core servers static as a
precaution. I realize this is counter to your advice but my concern is that
if the record is not static and it is scavenged, clients will not be able to
successfully look up the server(s) via dns.

I am, however, seeing an issue with the dns records for our Exchange cluster
server. For some reason the virtual host dns record automatically sets the
record to be scavenged when it becomes stale despite my deleting and
manually recreating it as a static one. Any idea what might be the cause and
do I really need be concerned about the server records being scavenged?

[3] I plan to use the default Microsoft settings of 7 days/7 days.


"Chris Dent" <(E-Mail Removed)> wrote in message
news:uA7yLEh$(E-Mail Removed)...
>
> Hi Barkley Bees,
>
> Please see in-line.
>
>> [1] Several days ago I went through the DNS records for this zone on our
>> primary DC to remove the "delete this record when it becomes stale"
>> checkbox from our static entries (server dns records). I went back today
>> to recheck them and I see that once again they are set to be deleted when
>> they become stale again. Why is this happening? I see on the other DC's
>> that the same record is not set for deletion though.
>
> The servers in question will still have permission to update the record.
> They will update the timestamp, and therefore update that box. If you see
> differences between DCs check replication (or allow time for replication).
>
> I advise you allow those records to be scavenged anyway. For Host (A) and
> Pointer (PTR) records the DHCP Client service will update each once every
> 24 hours (this applies to clients with static IP addresses).
>
> Making them completely static just gives you more work to do should you
> decommission a server in teh future.
>
>> [2] In the forward zone I want to scavenge, there are the following sub
>> folders with records that are all set to delete when they become stale:
>>
>> - _sites\Default-First-Site-Name\_tcp\ (_ldap record for each DC)
>> - _tcp (_gc, _kerberos, _kpasswd, _ldap records for each DC)
>> - _udp (_kerberos, _kpasswd records for each DC)
>> - DomainDNSZones (A record for each DC)
>> - DomainDNSZones\_tcp\ (_ldap record for each DC)
>> - DomainDNSZones\_sites\Default-First-Site-Name\_tcp\ (_ldap record for
>> each DC)
>> - ForestDNSZones (A record for each DC)
>> - ForestDNSZones\_tcp\ (_ldap record for each DC)
>> - ForestDNSZones\_sites\Default-First-Site-Name\_tcp\ (_ldap record for
>> each DC)
>>
>> Should I be unchecking the "delete this record when it becomes stale"
>> for all these records on all 3 domain controllers?
>
> No.
>
> The NetLogon Service on the DC will maintain those registrations,
> performing a Refresh once every 24 hours.
>
>> [3] I realize that I must set scavenging at the server level and at the
>> zone level but do I want to set scavenging on all 3 DC's or just one? The
>> DNS zones are set to replicate "to all DNS servers in the Active
>> Directory domain".
>
> Just one. The settings on the zone will replicate to each server. And the
> Scavenging task (Server Properties / Advanced) should only run on one DNS
> server.
>
> Because of the update intervals mentioned above I strongly recommend you
> do not consider setting the Refresh Interval lower than 24 hours.
>
> HTH
>
> Chris

"Barkley Bees" <(E-Mail Removed)> wrote in message
news:er40r$(E-Mail Removed)...
> Thanks for your reply Chris, much appreciated.
>
> [1] I went ahead and change the dns records for our core servers static as
> a precaution. I realize this is counter to your advice but my concern is
> that if the record is not static and it is scavenged, clients will not be
> able to successfully look up the server(s) via dns.
>
> I am, however, seeing an issue with the dns records for our Exchange
> cluster server. For some reason the virtual host dns record automatically
> sets the record to be scavenged when it becomes stale despite my deleting
> and manually recreating it as a static one. Any idea what might be the
> cause and do I really need be concerned about the server records being
> scavenged?
>
> [3] I plan to use the default Microsoft settings of 7 days/7 days.

Hello Barkley Bees,

I'm not sure why you would want to manually set them to not get scavenged.
As Chris mentioned, it's additional work. His advise and suggestions are
valid, and based on industry acceptance. If you find records are being
deleted, then there's something else going on.

Also from reading the following from your initial post, if you find one DC
shows the record as different than another DC, then once again, something
else is going on, possibly replication problems.
"... I went back today to recheck
> them and I see that once again they are set to be deleted when they become
> stale again. Why is this happening? I see on the other DC's that the same
> record is not set for deletion though."

Did you set credentials to allow DHCP to own the records for DHCP addresses?
I would suggest that, which will allow DHCP to update any DHCP client
records that get an IP change, or else a dupe/multiple records will occur. I
would also suggest to set it for DHCP to force updates whether a client can
or not (DNS tab in DHCP properties).

As for the AD SRV records, as Chris mentioned, they are automatically
refreshed once every 24 hours. No need to manually do anything with them
becaues the Netlogon service will automatically update and overwrite any
changes you make to them. It's additional administrative overhead what
you're proposing. I have multiple customers with more than two DCs, and I've
set them all up as described, and haven't touched them in years.


--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.