1. Welcome Guest! In order to create a new topic or reply to an existing one, you must register first. It is easy and free. Click here to sign up now!.
    Dismiss Notice

DNS Scavenging questions

Discussion in 'Windows Home Server' started by Barkley Bees, Jul 6, 2009.

  1. Barkley Bees

    Barkley Bees Guest

    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.
     
  2. Chris Dent

    Chris Dent Guest

    Hi Barkley Bees,

    Please see in-line.
    <!--coloro:blue--><span style="color:blue <!--/coloro-->
    > [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.<!--colorc--><!--/colorc-->

    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.
    <!--coloro:blue--><span style="color:blue <!--/coloro-->
    > [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:
    >
    > - _sitesDefault-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_sitesDefault-First-Site-Name_tcp (_ldap record for each
    > DC)
    > - ForestDNSZones (A record for each DC)
    > - ForestDNSZones_tcp (_ldap record for each DC)
    > - ForestDNSZones_sitesDefault-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?<!--colorc--><!--/colorc-->

    No.

    The NetLogon Service on the DC will maintain those registrations,
    performing a Refresh once every 24 hours.
    <!--coloro:blue--><span style="color:blue <!--/coloro-->
    > [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".<!--colorc--><!--/colorc-->

    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
     
  3. Barkley Bees

    Barkley Bees Guest

    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" <chris@noreply.null> wrote in message
    news:uA7yLEh$JHA.1336@TK2MSFTNGP05.phx.gbl...<!--coloro:blue--><span style="color:blue <!--/coloro-->
    >
    > Hi Barkley Bees,
    >
    > Please see in-line.
    ><!--coloro:green--><span style="color:green <!--/coloro-->
    >> [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.<!--colorc--><!--/colorc-->
    >
    > 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.
    ><!--coloro:green--><span style="color:green <!--/coloro-->
    >> [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:
    >>
    >> - _sitesDefault-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_sitesDefault-First-Site-Name_tcp (_ldap record for
    >> each DC)
    >> - ForestDNSZones (A record for each DC)
    >> - ForestDNSZones_tcp (_ldap record for each DC)
    >> - ForestDNSZones_sitesDefault-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?<!--colorc--><!--/colorc-->
    >
    > No.
    >
    > The NetLogon Service on the DC will maintain those registrations,
    > performing a Refresh once every 24 hours.
    ><!--coloro:green--><span style="color:green <!--/coloro-->
    >> [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".<!--colorc--><!--/colorc-->
    >
    > 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 <!--colorc--><!--/colorc-->
     
  4. "Barkley Bees" <barkbees@nomail.com> wrote in message
    news:er40r$TJKHA.4376@TK2MSFTNGP03.phx.gbl...<!--coloro:blue--><span style="color:blue <!--/coloro-->
    > 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.<!--colorc--><!--/colorc-->

    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<!--coloro:blue--><span style="color:blue <!--/coloro-->
    > 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."<!--colorc--><!--/colorc-->

    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
    for regional support phone numbers.
     

Share This Page