DHCP, Dynamic DNS Updates , Scavenging, static entries & time stamps, the DnsUpdateProxy Group, and DHCP Name Protection

DHCP, Dynamic DNS Updates , Scavenging, static entries & timestamps, the DnsUpdateProxy Group, and DHCP Name Protection

Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
  Microsoft Certified Trainer
  Microsoft MVP: Directory Services
  Active Directory, Exchange and Windows Infrastructure Engineer

Compiled 4/2006, recompiled 7/2009, & 1/4/2010
11/30/2011 – added DHCP credentials and DHCP/DNS tab properties screenshots.
3/10/2012 – Added enabling DNS scavenging screenshots.
8/22/2012 – Verified with a Microsoft enginner, we need to use the DnsUpdateProxy group and configure credentials to work, not one or the other. My blog has been corrected to reflect this. Also fixed missing screenshots
8/3/2012 – Additional info about DHCP Name Protection and that it requires Credentials, DnsUpdateProxy, but more so to secure the DnsUpdateProxy group


 Topics Covered:

  1. Preface: Keep in Mind, the entiity that registers the record into DNS, owns the record
  2. Scavenging Defined
  3. DNS Timestamp and Scavenging (and info on the dnsTombstoned Attribute)
  4. Scavenging Refresh and No Refresh Settings Must be less than the DHCP Lease Period
  5. DHCP Conflict Detection
  6. DHCP Lease has a “pen” or “pencil” Icon
  7. Records & timestamps, and the lack of timestamps
  8. Related Links




    Dynamic DNS Update Basics:

    1. By default, a Windows 2000 and newer statically configured machines will register their A record (hostname) and PTR (reverse entry) into DNS.
    2. If set to DHCP, a Windows 2000 or newer machine will request DHCP to allow the machine itself to register its own A record, but DHCP will register its PTR (reverse entry) record.
    3. The entity that registers the record in DNS, owns the record.



    How to configure DNS dynamic updates in Windows Server 2003.

    Using DNS servers with DHCP (Contains information on the DnsUpdateProxy group and its usage)
    http://technet.microsoft.com/en-us/library/cc787034 (WS.10).aspx


    Caveat with the DHCP service out-of-the-box configuration

    The goal is to keep DNS clean without duplicate records.

    When a client shuts down, and later returns past the lease time, it may get a different IP address. With the default settings, a duplicate A record gets registered by DHCP with the client’s new IP. This is because the client will not update itself due to the current record in DNS is beyond the lease period. This happens even though DHCP registered the record. This is because DHCP doesn’t own the record, the client does, even though DHCP registered it.

    DHCP Option 081:

    The way to get around this is you can configure DHCP’s Option 081 to update the record for all client, no matter if the client asks or not. To configure DHCP Option 081, you must look at the DHCP server properties, under the DNS Tab in DHCP properties. Despite it being a DHCP Option, it’s not found in a DHCP server, scope or class option.


    Overview to make this work:

    • DHCP must own the record, not the client. This is done by configuring DHCP to register all DHCP clients, whether the client supports Dynamic Updates or not.
      • As long as DHCP owns the record, can keep the records in the FLZ and RLZ up to date when the client renews its lease, same IP or different IP.
      • Otherwise you’ll see duplicate A and PTR records in DNS, whether scavenging is enabled or not.
    • Configure DHCP credentials by creating a plain-Jane, Domain User account. It doesn’t have to be an administrator account.
    • Add the DHCP Server object in Active Directory to the DnsUpdateProxy group.
    • In addition, I suggest to enable DNS scavenging to remove stale records, which will keep the zone clean.


    How do we configure DHCP for this to work??

    Summary to Configure Credentials and add the DHCP server to the DnsUpdateProxy group.

    Windows 2008 R2 or newer:

    You have a new feature to prevent Name Squatting: DHCP Name Protection, you still need to configure Credentials and add the server to the DnsUpdateProxy group.

  10. Add the DHCP server to the Active Directory, Built-In DnsUpdateProxy security group.
  11. Configure DHCP Credentials.
  12. Configure Name Protection.
  13. If DHCP is co-located on a Windows 2008 R2 DC, you must secure the DnsUpdateProxy group by running the following:
    dnscmd /config /OpenAclOnProxyUpdates 0 

    Note: Configuring DHCP credentials AND using the DnsUpdateProxy group, and forcing DHCP to update all records, will also allow DHCP to register Win9x machines, as well as non-Windows machines, such as Linux, OSx (BIND based), and other Unix flavors, and update the records when they get renewed with a different IP.

  14. Scroll down to the Name Protection section for more specifics and references,

    For Windows 2008 and older:

    To force DHCP to own and control all records it updates into the DNS zone, there are two parts of the procedure:

    1. Add the DHCP server to the Active Directory, Built-In DnsUpdateProxy security group.
    2. Configure DHCP Credentials. 


    Step by Step procedure:

    Step 1: To add the DHCP server’s computer account to the DnsUpdateProxy Group  

      • In ADUC, add the DHCP server’s computer properties to the DnsUpdateProxy security group.

        • In ADUC, click on the Built-In container.
        • Scroll down to the DnsUpdateProxy group.
        • Right-click DnsUpdateProxy group, choose properties
        • Click ADD -  make sure that the search criteria is set to look for computer objects,
        • Either type in the DHCP server’s name and click Check Name or click on Advanced, then click on FIND, and scroll down to the DHCP server name.
        • Once you see the DHCP server’s computer object, highlight it
        • Click OK.

    Step 2: Force DHCP to register all records, Forward and PTR, whether a client machine can do it or not:

    See screenshots below to configure the Option 081 settings under DHCP properties, DNS tab

    Step 3: Configure other DHCP Options as needed

    Suggested basic DHCP options:

    • Set the Connection Specific Suffix DHCP Option 015 to the AD domain name (such as example.com).
    • Set Option 006 to only the internal DNS servers.
    • Option 003 to your router

    Step 4: Configure the zone for Secure Updates Only: 

    Credentials and the DnsUpdateProxy group will be used to register them.

    Step 5: Configure DHCP Credentials. Note – you can do this on 2008 R2 and newer, if you chose not to use .     

        • In AD, create and configure a dedicated Domain User account to use as credentials in DHCP.
        • The user account does not need any elevated rights, a normal user account is fine.
        • Choose a very strong password.
        • Set the password so it does not expire.

    Then configure DHCP with the credentials you created:

    For Windows 2003:

    • Open the DHCP Console:
    • Right-click the DHCP servername
    • Choose Properties.
    • Click the Credentials button
    • Provide the account’s credentials

    In Windows 2008 and 2008 R2:  

    • Select IP Scope
    • Choose Properties
    • Select the Advanced tab
    • Click the Credentials button
    • Provide the account’s credentials.

    For Windows 2000: 

    • It must be done with the Netsh command. Windows 2003 and newer can also be done with the Netsh command, if you desire.



    Note and warning: about using the DnsProxyUpdate group on a DC

    • We normally shy away from adding a DC to the DnsProxyUpdate group, as it weakens security including the DC records if DHCP is on a DC. However, in many cases, there’s not much of a choice.
    • Windows 2008 R2 and newer gives you the option to use the DHCP Name Protection Feature, but as stated above, you still need to configure credentials and add the server to the DnsUpdateProxy group.
    • When DHCP is running on a Windows 2008 R2 domain controller, you must secure the DnsUpdateProxy group by running the following:
      dnscmd /config /OpenAclOnProxyUpdates 0


    Note on older, pre-existing records in DNS:

    After configuring the above provedure, the credentials and DnsUpdateProxy group configuratuion will not update current or delete duplicate records. You must delete them manually to allow DHCP to take care of all new records moving forward.

    Also, it will allevaite another issue – If DHCP is on a DC, it will not overwrite the original host record for a machine getting a new lease with an IP previoulsy belonging to another host. 

    If there is a problem with PTRs getting updated even after configuring credentials, please see this article:

    DHCP server processes expired PTR resource records in Windows Server 2003




    Step by step screenshots:

    Windows 2003:




    Windows 2008 & Windows 2008 R2:



    DHCP Name Protection

    If you have Windows 2008 R2, in addition to configuring the DNS tab to force registration, you still must configure credentials and add the server to the DnsUpdateProxy group. If DHCP is on a Windows 2008 R2 DC, to protect the DC when using the DnsUpdateProxy group, you must secure the group by running:

    dnscmd /config /OpenAclOnProxyUpdates 0

    Using  “DHCP Name Protection.” will register A and PTR record on behalf of a client, and will prevent a workstation (non-Windows) Name Squatting, meaning using a name that another machine (non-Windows or Windows) client that DHCP already registered , from registering it’s name. DHCP will give that duplicate named client an IP, but it will not register it into DNS. 

    Quoted from the following link:

    “Name squatting occurs when a non-Windows-based computer registers in Domain Name System (DNS) with a name that is already registered to a computer running a Windows® operating system. The use of Name Protection in the Windows Server® 2008 R2 operating system prevents name squatting by non-Windows-based computers. Name squatting does not present a problem on a homogeneous Windows network where Active Directory® Domain Services (AD DS) can be used to reserve a name for a single user or computer.”

     DHCP Step-by-Step Guide: Demonstrate DHCP Name Protection
    “Name squatting occurs when a non-Windows-based computer registers in Domain Name System (DNS) with a name that is already registered to a computer running a Windows® operating system. The use of Name Protection in the Windows Server® 2008 R2 operating system prevents name squatting by non-Windows-based computers. “

    Configuring DHCP Name Protection

    DHCP: The DNSupdateproxy group must be secured if Name Protection is enabled on any IPv4 scope

    DHCP: Credentials for DNS update should be configured if secure dynamic DNS update is enabled and the domain controller is on the same host as the DHCP server


    To configure Name Protection:

    • Right-click IPv4, choose Properties
    • Click on the DNS tab
    • Click “Configure”
    • Check the box, “Enable Name Protection”

    You can optionally select it on IPv6, too. No harm done, whether you have IPv6 scopes or not.


    You will notice that once you enable it:

    • Except the “Enable DNS Dynamic Updates according to the settings below,” checkbox, everything else under the DNS tab will be grayed out.
      • This is because the Name Protection feature takes over these functions, and will force register everything, so these settings are no longer used.
    • If you have multiple IPv4 scopes, once set at the IPv4 level, it will apply to all IPv4 scopes.
      • If you don’t want it to apply to all scopes, you can selectively disable the setting under each scope, or don’t enable it at the IPv4 level, and selectively enable it on a per scope basis.


    Here’s a screenshot of where to enable it:


    Screenshot of DNS Tab (which is actually Option 081), which grays out. This is because Name Protection took over these functions:


    If you have multiple IPv4 scopes, once set at the IPv4 level, it will apply to all IPv4 scopes.



    Back to top of page>




    Scavenging Defined


    Misconceptions about Scavenging

    There are some misconceptions prompting fears that Scavenging will remove everything in your zone, includind servers. Please understand, the main thing that scavenging works on is the timestamp. If there is no timestamp, such as a manually created, static record, it will not get scavenged. Also, if all servers, including DCs, are automatically updating their own record, then there is no fear of losing their records, because for one, their records (timestamps) are current, therefore scavenging won’t touch them, and two, Windows Servers by default will update their records every 24 hours, with the exception of domain controllers at every 60 minutes. Therefore, even if they were to scavenge these records, assuming the time stamp has ever been reached, the machines will refresh themselves anyway!


    DNS UPdate Interval is based on Operating System and WIndows Server Role:

    By default, statically configured clients and remote access clients that do not rely on the DHCP server for DNS registration, will re-register their A & PTR records dynamically and periodically every 24 hours. This applies to Windows 2000 Professional and all newer operating systems.
    For domain controllers, due to the importance of keeping up to date and accurate SRV and other records, the Netlogon service will attempt to update these records every 60 minutes.
    By default, on a computer that is running Windows XP/2003 or newer, the DefaultRegistrationRefreshInterval key value controls this (except Windows 2000, whichdoes not have this key but can be added), and is set by default to 1 day. This is true regardless of whether the computer is a client or a server, except domain controllers, which are every 60 minutes.
    You can use the following registry subkey to modify the update interval:

     Data type: REG_DWORD
    Range: 0×0 – 0xFFFFFFFF seconds
    Default value: 0×15180 (86,400 seconds = 24 hours) for Windows 2000 Professional
    Default value: 0xE10 (3,600 seconds = 1 hour) for Windows 2000 Server and Windows Advanced Server
     Scope: Affects all adaptors
    This specifies the time interval between DNS update registration updates.
    The default Time To Live (TTL) value used for dynamic registrations is 20 minutes. You can use the following registry subkey to modify the TTL value:


    In Summary:

    • Scavenging is a feature that will remove expired records based on their Timestamps.
    • Scavenging is not enabled by default.
    • Scavenging will NOT remove statically configured records, the ones you manually create unless you run dnscmd /AgeAllRecords, which will stamp them making them eligible for scavenging (more below on this). Without running this command, DNS will scavenge dynamically updated records that have reached their time stamp. To look at the time stamps of a record using Windows 2003 DNS, put the DNS console “view” in the menu to Advanced View, then look at the individual record properties, and you will see the time stamp. If using Windows 2008 or or newer, it will show up in the console as a separate column.


    Scavenge Refresh and No Refresh vs DHCP Lease period

    Scavenging Refresh and No Refresh settings must be equal to or less than the lease period. For example, using  the default DHCP lease period of 8 days with a 7day scavenge setting, is perfect. If you lower the lease, you need to lower the scavenge settings. If you are using a 4 hour lease, well, that’s a tough one, because the lowest you can go with scavenging is 1 day, and may provide inconsistent results.

    And please bear in mind, as already stated, scavenging will not remove statically configured records, (the ones you’ve manually created). It will scavenge updated records that have reached their time stamp. However, if you run dnscmd /AgeAllRecords, it will timestamp all records, making them eligible for scavenging.More on this in the next section, Static records.

    To set aging and scavenging properties for a DNS server using the DNS Console:

    1. In the DNS console, right-click the DNS server name, and choose “Set Aging/Scavenging for All Zones.
    2. Select the Scavenge stale resource records check box.
    3. You can now either choose to set Scavenging for all zones, or choose No, and manually set each zone individually. I suggest setting it for all zones.
    4. It’s recommended to go with the defaults of 7 days. If you choose to change it, it should reflect and stay in line with DHCP’s lease times. Now I’ve never found anything specific stating this, but keeping the scavenge setting to the lease minus one day, ensures that records will be deleted one day before lease renewal so it will be deleted if that record were actually not in use by a client, and has expired. If still in use, it will go through the scavenging refresh period and scavenge lifetime until the next expiration time.
    5. Once you’ve set scavenging, all records that have a time stamp will be aged,  will get scavenged. This does not include static records, because static records do not have a time stamp.


    Excample of a dynamically created record:


    Static Records:

    Static records will not get scavenged, since they have a 0 time stamp. When viewing a static record, it will show as the following:

    However, regarding static records, if you use force age all records using the dnscmd /AgeAllRecords. If the “Delete the record when it becomes stale” box was checked at time of the record creating, it will set a TimeStamp on it, which will make it eligible for scavenging. Therefore, if you have an static records, host, cnames, etc, they will get scavenged, and I advise to take inventory of your static entries if you run this command. I would suggest not to, and just allow scavenging to take it’s time to do its thing. Be PATIENT!!!!




    Rough formula to go by: NoRefresh + Refresh * 2 + the point in time during the 3 day scavenge period.

    Here’s a chart showing when events occur with a 3-day NoRefresh, 3 day Refresh, and 3 day Scavenging. (Graphics from Don’t Be Afraid of Scavening. You must be patient):

    If you look at the chart, based on scavenging settings of a 3 day NoRefresh and 3 day Refresh, then it becomes eligible for scavenging the day after these two pass, so it will be the 7th day. Then it waits for the next scavenge cycle (I kind of call it the garbage collection point), which is somewhere withing the next 72 hours (based on the NoRefresh). So based on this chart, starting at 1/1/2008, the record becomes eligible on 1/7/2008, then it’s deleted (scavenged) on, in this case, on 1/10/2008, at 6am during the next 72 hour scavenge cycle. The 72 hour scavenge cycle in this case, is based on the 3day scavenge setting..

    That was a total of about 10-11 days, but it could have happened, as you can see in the chart, anytime between the 10th day and the 14th day.




    If you choose the default 7 day setting may take up to 4 weeks + 1 day (29 days) for scavenging to take place.



    AD Integrated zones – Where do you set it? – Enable it only on one server, and the timestamp will replicate with AD replication

    In summary, with using AD integrated zones, you just enable scavenging on one server, then the time stamp will replicate to other servers with the normal AD replication process. When AD integrated zones are involved, DNS uses an additional mechanism to control replicating the records’s time stamp behavior through the dnsTombstoned attribute.

    In addition, regarding enabling it on one server, Josh Jones [MSFT] quotes (in his blog, “Don’t be afraid of DNS Scavenging” ):

    “Although you can set every server hosting the zone to scavenge I recommend just having one. The logic for this is simple: If the one server fails to scavenge the world won’t end. You’ll have one place to look for the culprit and one set of logs to check. If on the other hand you have many servers set to scavenge you have many logs to check if scavenging fails. Worse yet, if things start disappearing unexpectedly you don’t want to go hopping from server to server looking for 2501 events.”

    For more specifics, and to not duplicate Josh Jones’ efforts, please read his blog for specific info – “Don’t be afraid of DNS Scavenging

    Don’t be afraid of DNS Scavenging, Josh Jones [MSFT], 19 Mar 2008 6:49 PM


    AD Integrated Zones and Scavenging – How does it do it? It uses the AD attribute called, “dnsTombstoned”

    Good article by Guy Teverovsky [MSFT], explaining how AD handles scavenging with records in an AD integrated zone, as well as what happens if say a machine who’s record is marked as dnsTombstoned, but the machine is reinstalled, which now has a new SID, and how it can’t update the original record -  the original host record is not removed immediately:

    DNS Scavenging internals (or what is the dnsTombstoned attribute) for AD Integrated zones, by Guy Teverovsky [MSFT], 23 Sep 2010


    Other articles on Scavenging:

    Optimizing your network to keep your DNS squeaky clean


    Enable Scavenging Screenshots

    Screenshots showing enabling scavenging with the default 7 Day NoRefresh, and 7 Day Refresh. Note that scavenging will not kick in until 1 day after these two periods combined, meaning 15 days later. And if you also notice, that after I enabled them, and ran dnscmd /AgeAllRecords, the static records still didn’t show as stamped. Eventually they will. That’s the “being patient” part.















    Note of Caution: T\the only problem with running this command, is it will timestamp all static records making them eligible for scavenging. Therefore, you may NOT want to do this.





    Note on the screenshot below (quoted from Don’t Be Afraid of Scavening. You must be patient)::
    “The Scavenging Period is how often this particular server will attempt to scavenge. When a server scavenges it will log a DNS event 2501 to indicate how many records were scavenged. An event 2502 will be logged if no records were scavenged. Only one server is required to scavenge since the zone data is replicated to all servers hosting the zone.

    Tip: You can tell exactly when a server will attempt to scavenge by taking the timestamp on the most recent EventID 2501 & Event ID 2502 events and adding the Scavenging period to it.

    Image from: http://blogs.technet.com/blogfiles/networking/WindowsLiveWriter/DNSscavengingiseasy.Havingpatienceishar_C6E0/image_14.png


    Moral of the story: Be Patient!!



    Back to top of page>

    DNS Time stamp and Scavenging

    If the record was manually created, it won’t show a time stamp, however, if the record was dynamically registered, it will show a time stamp. If you manually create a record, the checkbox will not be checked to scavenge, however if it was dynamically registered, it will be checked.
    As for the server entries (such as from a DC), if you allow auto registration, which is done by default, and it gets scavenged, it gets re-registered anyway by the DC’s Netlogon service (for the SRV, LdapIpAddress and GcIpAddress records) and the operating system (for the A and PTR records). Unless you are seeing something going on that is affecting your environment, the default settings work fine, at least they do for me for all of my customers and installations I’ve worked in that I’ve set scavenging and forced DHCP to own the records so it can update the records it had registered at lease refresh time.

    Regarding the Active Directory dnsTombstoned Attribute

    DNS Scavenging internals (or what is the dnsTombstoned attribute) for AD Integrated zones
    Discuss the internal processing of DNS Scavenging.

    dnsTombstoned Records clean-up:
    Everyday at 2AM (non-configurable) the DNS server scans all DNS integrated zones in AD and determines whether the tombstoned record is ready to be deleted. The default retention time of the tombstoned records is 7 days. This value can be changed by the DsTombStoneinterval value (dnscmd w2k8r2dc01 /config /DsTombstoneInterval value) or by editing the registry under HKLM\CCS\Services\DNS\Parameters Value Name:DsTombstoneInterval

    Value Type: DWORD). The value is in seconds.

    At that point the DNS deletes the record.

    Back to top of page>


    Scavenging Refresh and No Refresh Settings Must be less than the DHCP Lease Period

    The scavenging period must be set less than the lease time. The way you have it currently set, you have two different settings but both are beyond the lease time. Due to both of these settings being different and beyond the lease time, is why you are getting inconsistencies, as I previously mentioned.

    For example: The 7 and 7 day intervals work hand in hand with a default DHCP lease time of 8 days. DHCP renewals are half the lease interval right, whcih is 4 days. If it doesn’t get renewed, then it waits until 87.5% of the lease time to renew, which is at the 7th day. If it doesn’t get renewed, then the lease is lost, and the DHCP client will attempt to get a new lease. Once the lease is lost at the 7th day, then if you left scavenging set to default, it will clean out that old lease entry from DNS in all zones it existed in.

    Therfore, if you have an 8 hour lease, you’ll need to set scavenging for 1 day, but that is not a recommended setting. It’s simply too low. Also an 8 hour lease tries to renew at 50% of the lease time, and if unsuccessful, at 87.5% of the lease time, which is at the 7th hour. Scavening needs to be set below that, but scavenging settings are in days, which is at 24 hours intervals, so there’s no possible way to set it below the lease time.

    Also, a lease time of 8 hours, or even 4 hours, as I’ve heard some admins have set it to, is really an aggressively short lease and can cause other problems elsewhere, such as with WINS and replication partners. I’ve seen errors in WINS in a partnership scenario where the data is constantly changing and WINS simply couldn’t keep up with the changes between partners.

    My suggestion is at least that if you want to keep an aggressively short lease, to at least make the lease period 2 days and scavenging 1 day.

    However, I’ve been in environments with the default 8 day lease and 7 day scavenging settings, along setting either using credentials so DHCP owns all records it updates, or using the DnsProxyUpdate group, and it works fine. If a laptop gets a record at 8am on a Monday, but unplugs and goes home and comes back on Thursday, the laptops will attempt to get the same lease. If the laptop doesn’t come back until Tuesday the following week, it will get a new lease and new IP, since DHCP owns the record, it simply updates it in DNS for the forward and reverse zones.

    To properly make it work using the DnsProxyUpdate group or using credentials, you must force DHCP to update ALL RECORDS, whether the client knows how to update or not or requests it or not (the bottom setting). This will force DHCP to own ALL records. If you do not set these settings, and the scavenging period is more than the lease, unexpected results will occur.

    Scenario: Choosing a Short DHCP Lease Time of 8 hours

    If you reduce the DHCP lease to 8 hours, a number of things can occur, such as increased AD Tombstoning of DNS entries, which will increase the AD NTDS.dit file size, as well as possibly an inconsistency with the records in DNS, as well as issues with WINS trying to keep up with the changes, which will be evident with WINS Event log error entries.

    Also keep in mind, with any DHCP client no matter what operating system, uses the DORA method, that is Discovery, Offer, Request, and Acknowledgement. The point in time a client will ask for a lease refresh is at the 50% mark, where it uses RA, or Request (for the current lease config it has), and Acknowledgment. If it can’t get it at the 50% mark after 3 attempts, it will wait until 7/8 of the lease time to broadcast out a refresh request until the end of the lease period. If it doesn’t get a renewal at the end of lease, the client machine removes the current config from its interface and has no IP.

    Therefore with an 8 hour lease, the refresh time is at 4 hours. That needs to be taken into account with additional traffic, and how DNS updates, as well as how WINS handles it with the contstant requests coming through.

    Regarding the WINS issue, I’ve seen this once at a customer site years ago. It’s always stuck to the back of my mind to keep this in mind when such a short lease is desired. I found  a default lease works fine, as long as scavenging is enabled (using default settings as well), including if the DHCP server is on a DC, adding the DHCP server to the DnsUpdateProxy group, or to alleviate the security issues with such as move, to rather supplying credentials for DHCP, so it owns all records it registers into DNS, in order so it can update the records as they change. Otherwise, expect issues to occur.

    (The following, which goes into much more detail of what is actually occuring, was compiled and posted by Chris Dent in the Microsoft DNS newsgroup.)

    Why would one choose 8 hours? Possibly to handle many laptops coming in and out of the network. So you would think a shorter lease time would work. However, keep in mind with any lease time, the point at which a client will ask for a lease refresh is at 50% of the lease time. Therefore, the client machine will asking for a refresh every four hours.

    This will result in a high rate of change in DNS, which may lead to a large number of tombstoned DNS entries. It would seem reasonable to reconsider the DHCP Lease duration, 8 hours is, after all, extremely short.

    Essentially you have:

    • The amount of AD Tombstoned Data is increasing because of Stale DNS records
    • The number of Stale DNS Records is high because of the (potential) rate of change of records in both Forward and Reverse Lookup
    • The rate of change must be somewhat proportional to changing leases in DHCP

    The DNS Record lifecycle:

    1. An A record is created (as a dnsNode in AD).
    2. When the Timestamp is no longer updated, and the Aging Intervals passes it’s aged setting, the A Record becomes Stale.
    3. Stale Records are removed from the active DNS system, and the AD dnsTombstoned attribute is set to TRUE.
    4. Tombstoned record exists for value of the DsTombstoneInterval attribute, which is 7 days by default.
    5. The DnsNode object is moved to the Deleted Objects for the length of time of the tombstoneLifetime attribute value.

    Note : The Active Directory Tombstone Lifetime is listed in the schema.ini and will be set during the promotion of the very first DC in the forest based on the Windows version used to install the first DC. This value does not change after upgrading all domain controllers to newer Windows versions or by changing the Domain or Forest Functional Levels. The entry in the schema.ini “tombstoneLifetime=<number of days>”  and can be changed. Therefore, this will tell you what the value is depending on what Windows operating system was used to install the very first domain controller in your infrastructure:

    • If the very first DC was installed using a Windows 2003 with integrated SP1 CD or newer, the Tombstone Lifetime Value is 120 days.
    • If the very first DC installed in the forest is Windows 2000 (any Service Pack), or Windows 2003 (pre-Windows 2003 SP1), the Tombstone LIfetime is 60 days.

    The values can be changed. Please read the following for information on how to change it:

    Active Directory Lingering Objects, Journal Wraps, Tombstone Lifetime, and Event IDs 13568, 13508, 1388, 1988, 2042, 2023
    (Scroll down to “Active Directory Tombstone Lifetime”)

    Therefore, you either need to reduce the rate of change by increasing the lease duration, or deal with the inaccuracy in DNS, by limiting the Aging and Scavenging settings, or deal with an increasing directory size to store all this additional data. The directory size should level out eventually, when you reach the point where the number of tombstoned records being flushed is equal to the number being created.



    Back to top of page>

    DHCP Conflict Detection

    When DHCP provides a lease to a client, it tries to determine if there are no conflicts with another machine using the IP, which may have been inadvertently configured with a static IP configuration not realizing the IP is withing the Lease Scope.

    DHCP uses pings for conflict detection.

    Enable address conflict detection

    DHCP Best Practices
    Look for: “Use server-side conflict detection on DHCP servers only when it is needed”

    DHCP Server Conflict Detection

    I’ve been asked a few times in the past if DHCP Conflict detection pings are the same as the pings when one uses a command prompt to ping a host. The answer to that is yes.

    To expand, the term “ping” is short for “Packet Internet Groper.” Pings are based on ICMP packets, just as you would ping an IP address, the DHCP server does the same to detect conflicts. It’s sumamrized in the following link by searching the sentence, “When conflict detection attempts are set, the DHCP server uses the Packet Internet Groper (ping) process …”

    DHCP Server Conflict Detection

    Specific info on the Ping command:

    Ping – General Summary

    Internet Control Message Protocol – Technical Summary

    Back to top of page>

    DHCP Lease has a “pen” or “pencil” Icon

    If a record shows up in the DHCP Lease list with a pen icon, it means that a write is pending. If it doesn’t disappear, it may mean it is trying to register into a zone that does not exist on the DNS servers. This happens in cases where the client machine is not joined to the domain and has a missing or different Primary DNS Suffix than the zone in DNS.

    Registration can only occur into a zone that exists on DNS and that zone updates have been configured to allow updates.

    If this is the case, go into the client machine’s IP properties, and perform the following:

    • On the DNS tab in TCP/IP Advanced properties, clear the “Register this connection’s addresses in DNS”
    • Clear the  “Use this connection’s DNS suffix in DNS registration” check boxes,
    • The DHCP Server will fill these in for you and register using the domain name in Option 015.


    DHCP console icons reference

    Back to top of page>


    Records & timestamps, and the lack of timestamps

    If the record was manually created, it won’t show a time stamp, however, if the record was dynamically registered, it will show a time stamp. My guess is the records you are referring to were manually created. If you manually create a record, the checkbox will not be checked to scavenge, however if it was dynamically registered, it will be checked.

    I just tested this with Windows 2003 DNS. When I had built a few servers for a customer and let them auto register, they had a timestamp and the scavenge checkbox was checked. For the records I manually created, such as internal www records, and others, they did not have a time stamp and were not checked to scavenge.

    Even if you allow auto registration, which I do by default, and it gets scavenged, it gets re-registered anyway by the OS. Unless you are seeing something going on that is affecting your environment, the default settings work fine, at least they do for me for all of my customers and installations I’ve worked in that I’ve set scavenging and forced DHCP to own the records so it can update the records it had registered at lease refresh time.

    Back to top of page>


    Related Links

    How to configure DNS dynamic updates in Windows Server 2003.

    Using DNS servers with DHCP (Contains information on the DnsUpdateProxy group and its usage)
    http://technet.microsoft.com/en-us/library/cc787034 (WS.10).aspx

    Using DNS Aging and Scavenging
    Aging and scavenging of stale resource records are features of Domain Name System (DNS) that are available when you deploy your server with primary zones.

    Microsoft Enterprise Networking Team : Don’t be afraid of DNS, Mar 19, 2008
    DNS Scavenging is a great answer to a problem that has been nagging everyone since RFC 2136 came out way back in 1997.
    http://blogs.technet.com/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be- patient.aspx

    How DHCP Technology Works

    From Ulf B. Simon Weidner:
    DHCP, DNS and the DNSUpdateProxy-Group
    I had a discussion in the Newsgroups lately about DHCP and the DNSUpdateProxy-Group which is used to write unsecured DNS-Entries to a DNS-Zone which only …

    And from Kevin Goodnecht:
    Setting up DHCP for DNS registrations

    317590 – HOW TO Configure DNS Dynamic Update in Windows 2000 and DNSUpdateProxy Group:

    816592 – How to configure DNS dynamic updates in Windows Server 2003:

    Follow up discussion on the DNSUpdateProxy-Group:

    Back to top of page>



    Comments, Corrections and Suggestions are Welcomed

    Ace Fekay


    27 thoughts on “DHCP, Dynamic DNS Updates , Scavenging, static entries & time stamps, the DnsUpdateProxy Group, and DHCP Name Protection

    1. Good morning,

      This is an excellent post, thank you. I am having problems with DNS on our SBS2008 server. This explains some of the issues.

      However, where do I find the scavenging check box? I’ve gone to DNS/ForwardZone/xxxx.xxx/right click on entry in rightside pane/Properties, but no scavenging text box. only Update Associated Pointer. Also, DNS/ReverseZone/xxx.xxx.in-addr.arpa/right click on entry in rightside pane/Properties, no check box

      I have a number of reverse DNS enteries with a “static” timestamp that are causing problems. These are from very old PCs that have been long removed from our system. But of course we have server entries that have a “static” timestamp that we need to keep.

      You help in this would be most valuable.



    2. Hello Jeane,

      Thank you for your comment!

      You make a good point that I forgot to mention where and how to set the Scavenging settings.

      Right click your DNS Server name, choose “Set Aging/Scavenging For All records.” A dialogue box pops up asking what settings you would like to set it to. I would suggest to leave it at the default 7 day settings.

      I hope that helps!


    3. Hi Domain Tools and Valiidation,

      When you register a public domain name, you need to set the information the registrar requires. However, you don’t necessarily have to make your information available to the public. You can opt to hide it and make it private for WHOIS lookups. It’s an added feature registrars offer for an additional price. This way your information shows up as private with only the registrar’s information along with a registrar’s email address that people can use and the registrar will be forward it to your own email address. This keeps your information private as well as preventing domain hijacking.


    4. Hello

      To be sure. We have the dhcp service on a DC and the user account is configured. Should we use the dnsproxyupdate group too?

      Thanks a lot

    5. Great DHCP advice. I spent way too much time trying to figure out why DHCP wasn’t updating DNS in certain scenarios. Credentials fixed the issue. Thanks!

      For some reason firefox/ie9 isn’t showing the text box frames for the comment required inputs. The only frame I can type into visible is the “comments” textarea. The rest I had to click around for.

    6. Hi Ace,
      This is an Excellent article! The thing which i like most in your posts is simple diagrams you use to explain “how it works” . It just stays in mind forever. I have already bookmarked your blogs! :) Keep Going!

      Mohan R
      Sr.Administrator – Server Support

    7. Thanks, Mohan! I’ve always tried to strive for the simplest explanation. It does help to remember it!

      Thanks for the great feedback!


    8. In Windows Vista (and Windows Server 2008) Microsoft moved the registration functionallity from the DHCP Client service to the DNS Client service.

      Will your article be correct for Windows 7 Clients?


    9. In Windows Vista (and Windows Server 2008) Microsoft moved the registration functionallity from the DHCP Client service to the DNS Client service.

      Will your article be correct for Windows 7 Clients?



    10. in multiple dns server scenarios, where scavenging has always been off, timestamps don’t get replicated until i turn scavening on, right? many articles recommend only turning scavenging on one server. does this mean timestamps will get replicated *to* that one server, but not from it? (not so far in my testing.)

      i want to verify the timestamps are correct everywhere *before* i enable scavenging, but i can’t verify timestamp replication *until* i enable scavenging.

    11. Jan-Erik,
      Yes, it works the same for 2000 and newer clients, no matter what the local service is called that performs DNS Dynamic registration.

      Yes, you must enable scavenging on one server. And I know we’ve discussed this in your Technet thread posting. For others, you may want to read the thread for more info and the informative discussion on how this works:

      Technet Thread Question: “DNS timestamp replication (again), and Scavenge vs Enable Automatic scavenging” (3/10/2012): http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/431c3597-e2d1-4061-96ed-4672532dc126/

    12. Great Post! You’ve obviously done your homework.

      I have a few additional questions:

      1. Is the “OWNER” of a DNS record found by right-clicking the record in DNs and selecting Properties->Security->Advanced->Owner? Many of the DNS records seem to be owned by ‘SYSTEM’, some by $, and some by $. This doesn’t seem right based on what I read.

      2. If a dedicated user account is used on the DHCP server to register dynamic DNS updates, does that user need to be a member of the DNSUpdateProxy group?

      3. If I begin using a dedicated user account to register dynamic DNS updates, is there anything to be aware of concerning the existing DNS records?

      4. DHCP option 81 – Should “Always dynamically update DNS A and PTR records” be selected?

      5. DHCP option 81 – Should “Dynamically update DNS A and PTR records for DHCP clients that do not request updates” be checked?

      6. DHCP lease duration for all scopes is currently set to 1 Day. No Refresh and Refresh intervals are at the defaults (7 days). Scavenging is set to occur every 7 days. I don’t see this setup as incorrect except that more AD replication occurs.


    13. Hello Ace!
      Great article, full of unvaluable infos!!!
      I see that some pictures are missing, as I think those pictures are very important in order to better understand the scavenging procedure is it possible to fix the link?
      Many thanks in advance!
      Best regards


    14. I rarely comment on blogs but I must say this is one of the most informative pages I’ve ever read. Thank you for this contribution to my knowledge!

    15. Hello.

      First of all let me thank you for a great article. It helped me a lot.

      Text from your article:
      “…If you are using a 4 hour lease, well, that’s a tough one, because the lowest you can go with scavenging is 1 day, and may provide inconsistent results…”

      The question is: why do you say you can not set scavenging period in DNS shorter than 1 (one) day? The interface allows you to set the number AND the units i.e. choose between “days” and “hours”. I have it set to 1 hour so that scavenging would happen soon after a record can be considered stale (I do not have many computers (200) in my domain and performance impact is not an issue for me).
      It seems to work quite as expected.

      All the settings I use:
      1. DHCP lease : 8 hours
      2. DNS no-refresh: 1 hour
      3. DNS refresh: 3 hours
      4. DNS scavenging: 1 hour
      5. DNS Registration Refresh Interval policy enabled for entire domain and the interval is set to 1800 (30 minutes).


    16. Ace,

      I am abit confused. I am researching this and still am unsure if I should use DHCP with credentials, AND place the DHCP server in teh DNSUpdateProxy group?
      I have seen several of your post on TechNet.

      also if the DHCP server is also a DC and is running Server 2008 (NOT R2) I DO NOT run the open proxy command. That is only for R2?

    17. Hello Ace Fekay,

      I was hoping to submit the comment below but I am unsure if it is going through (going to try one more time).

      Your article was very helpful but I did have a further question.

      If you have a PayPal account, I would not mind paying for your response as I really appreciated your article (and I’d really like to get through this issue).

      Great article – quick question:

      I’m assuming that if this is setup correctly, the permissions for the PTR records in the Reverse Lookup Zone should be automatically set in a specific way – which should be the same for each record in the zone.

      I’m curious to know, then, how the permissions should read when setup correctly to compare to what I am seeing on my network.

      I thought I had resolved my duplicate issue, but after a little over a week I have a duplicate computer name in a RLZ from yesterday.

      Below are the permissions:

      Record 1: 02.05.2013 – 1:00 PM (time stamp)

      The permissions for the DHCP credential account are set to allow for Full Control, Read, and Write.

      Record 2: 02.05.2013 – 10:00 AM (time stamp)

      The permissions for the DHCP credential account are set to allow for Write and Special Permissions. The special permissions allow: Write All Properties, Read Permissions, and All Validated Writes.

      The reset of the records seem to have the same permission as Record 2 – are these the permissions one would expect to see in place when the DNSUpdateProxy group (and everything else in the article) is setup and working correctly?

      If not, how should they read?


    18. Configure DHCP Credentials. Note – you can do this on 2008 R2 and newer, if you chose not to use .

      I am assuming the missing info is Name Protection?

      Configure DHCP Credentials. Note – you can do this on 2008 R2 and newer, if you chose not to use Name Protection.

    19. You say:

      “If the very first DC was installed using a Windows 2003 with integrated SP1 CD or newer, the Tombstone Lifetime Value is 120 days.”

      But the article you reference, http://msmvps.com/blogs/acefekay/archive/2011/12/27/active-directory-lingering-objects-journal-wraps-tombstone-lifetime-and-event-ids-13568-13508-1388-1988-2042-2023.aspx , says 180 days.

      Here’s the breakdown on what your Tombstone Lifetime settings may be:
      - Windows 2000 with all SPs = 60 Days
      - Windows Server 2003 without SP = 60 Days
      - Windows Server 2003 SP1 = 180 Days
      - Windows Server 2003 R2 SP1, installed with both R2 disks = 60 Days
      - Windows Server 2003 R2 SP1, installed with the 1st R2 disk = 180 Days
      - Windows Server 2003 SP2 = 180 Days
      - Windows Server 2003 R2 SP2 = 180 Days
      - Windows Server 2008 = 180 Days
      - Windows Server 2008 R2 = 180 Days

    20. Hi,
      Thanks for the article it is of great help to me.
      I have 23 DCs in my environment.
      If i check the records of one DC on another i used to have a timestamp but now they have static ip address. So i deleted the record manually from one dc and went to the machine ran ipconfig /flushdns. The new A record has a timestamp but after 30 minutes it chnaged to static. Could you help me why it happened.

    21. Nice blug!

      I have question Ace. If my DHCP has option 6 (DNS servers) has 2 DNS servers (DNS1, DNS2) and on the client computer it has DNS3, DNS4. Which DNS server will be updated first?

    22. Hi Ace,
      Thanks for this great article. I’ve tried this in a lab with 2 W2K8 R2 serversw that are DHCP/DC/ DNS and it works great if I don’t enable name protection (that is, i’ve done everything else you’ve recommended). The moment I turn on name protection, the DHCP clients start getting registered as the owners of their records rather than the dhcpsvc credential. Can you please advise? Additionally, even though I have the option ‘Discard A & PTR Records when lease is deleted’ , the records don’t get deleted after the lease is deleted.

      Additionally, would this work with a mix of 2003 & 2008R2 servers (both of which are DCs/DNS/DHCP)?


    23. And here is additional, pertinent information that you and others may find helpful:

      Why is the DnsUpdateProxy group needed in conjunction with credentials?

      The technical reason is twofold:

      Objects created by members of the DNSUpdateProxy group have no security; therefore, any authenticated user can take ownership of the objects.

      DHCP Credentials:
      Forces ownership to the account used in the credentials, which the DnsUpdateProxy group allowed to take ownership other than the registering client.

      The default process is outlined below, and this applies to non-Microsoft
      operating systems, too, but please note that non-Microsoft operating systems
      can’t use Kerberos to authenticate to dynbamically update into a Secure Only
      zone, however you can configure Windows DHCP to do that for you.

      Following discussed in:

    24. Hi Ace,

      I met you in Chesterbrook PA I was there for training I think you were teaching another course maybe 10-12 years ago while we both worked at Knowledge Alliance. I think you were working out of Tampa at the time. How are thing going?

      I am looking for a solution for DNS Delegation that grants permission less than DNS admin and more than readonly DNS mmc access that will allow a user to create or modify a /ptr records of a specific dns zone. Any ideas would be great.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>