Posted on August 13, 2016 by Ace Fekay

It’s me again. I originally posted this in 4/2006, and updated throughout the years, but I still get questions from time to time asking why updates are not working, especially PTR. Well, I thought it’s time for an update and to just offer a summary in the beginning, because in this day and age, no one wants to read! A quick Facebook read the first line and click “Like,” seems to be the norm.  Well, I will also offer the nitty gritty below the summary for those who want to read.

 

Topics Covered:

Preface: The entity that registers the record into DNS, owns the record

Summary: How to configure DHCP & Dynamic DNS Updates

Scavenging Defined

DNS Timestamp and Scavenging (and info on the dnsTombstoned Attribute)

Scavenging Refresh & NoRefresh Settings must be less than the DHCP Lease Period

DHCP Conflict Detection

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

Records & timestamps, and the lack of timestamps

Related Links

Preface:

Dynamic DNS Update Basics:

This is the part that many do not understand. Please read thoroughly before asking me why your PTR updates don’t work.

 

1. By default, ALL Windows 2000 and newer machines statically configured machines will register their own A record (hostname) and PTR (reverse entry) into DNS.

Yep. That’s the basic rule. And yea, I had to state Windows 2000 and newer, because this stuff doesn’t apply to older Windows versions.

2. If set to DHCP, a Windows 2000, 2003 or XP machine, will request DHCP to allow the machine itself to register its own A (forward entry) record.

But DHCP will register its PTR (reverse entry) record.

3. If Windows 2008/Vista, 2008 R2, Windows 2012 R2, Windows 7, 8, 8.1, 1, and all future releases, the DHCP server always registers and updates client information in DNS

Note: “This is a modified configuration supported for DHCP servers running Windows Server 2008 and DHCP clients. In this mode, the DHCP server always performs updates of the client’s FQDN, leased IP address information, and both its host (A) and pointer (PTR) resource records, regardless of whether the client has requested to perform its own updates.”
http://technet.microsoft.com/en-us/library/dd145315(v=WS.10).aspx

4. The entity that registers the record in DNS, owns the record.

Note:  “With secure dynamic update, only the computers and users you specify in an ACL can create or modify dnsNode objects within the zone.

By default, the ACL gives Create permission to all members of the Authenticated User group, the group of all authenticated computers and users in an Active Directory forest. This means that any authenticated user or computer can create a new object in the zone.

Also by default, the creator owns the new object and is given full control of it.
    Secure Dynamic Update
    http://technet.microsoft.com/en-us/library/cc961412.aspx

 

Reference:

Updating DNS Resource Records
https://technet.microsoft.com/en-us/library/ff631099%28v=ws.10%29.aspx

How to configure DNS dynamic updates in Windows Server 2003.
http://support.microsoft.com/kb/816592

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

===============================================================

Summary: How to configure DHCP & Dynamic DNS Updates

1. Configure DHCP Credentials.

   The credentials only need to be a plain-Jane, non-administrator, user account.
   But give it a really, REALLY strong password.

2. Set DHCP to update everything, whether the clients can or cannot.

3. Set the zone for Secure & Unsecure Updates. Do not leave it Unsecure Only.

4. Add the DHCP server(s) computer account to the Active Directory,  Built-In DnsUpdateProxy security group.

   Make sure ALL other non-DHCP servers are NOT in the DnsUpdateProxy group.
   For example, some folks believe that the DNS servers or other DCs not be running DHCP should be in it.
   They must be removed or it won’t work.
   Make sure that NO user accounts are in that group, either.
   (I hope that’s crystal clear – you would be surprised on the number of responses I get asking if the DHCP credentials should be in this group.)

5. On Windows 2008 R2 or newer, DISABLE Name Protection.

6. If DHCP is co-located on a Windows 2008 R2, Windows 2012 R2, and all future Windows versions Domain Controllers:

   You must secure the DnsUpdateProxy group by running the following command:
   dnscmd /config /OpenAclOnProxyUpdates 0

7. Configure Scavenging on ONLY one DNS server. What it scavenges will replicate to others anyway.

8. Set the scavenging NOREFRESH and REFRESH values combined to be equal or greater than the DHCP Lease length.

Just to be crystal clear, this means that if the lease is an 8 day lease, than  NOREFRESH should be 4 (four) and REFRESH should be 4 (four) so when you add them together, they are not greater than the lease length.

 

===============================================================

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.

Add the DHCP server to the Active Directory, Built-In DnsUpdateProxy security group.

Configure DHCP Credentials.

Configure Name Protection.

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.

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
http://support.microsoft.com/kb/837061

.

Step by step screenshots:

Windows 2003:

.

.

.

Windows 2008 & Windows 2008 R2:

.

.

DHCP Name Protection

If you have Windows 2008 R2 or Windows 2012 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. “
http://technet.microsoft.com/en-us/library/ee404786(v=ws.10).aspx

Configuring DHCP Name Protection
http://technet.microsoft.com/en-us/library/dd759188.aspx

DHCP: The DNSupdateproxy group must be secured if Name Protection is enabled on any IPv4 scope
http://technet.microsoft.com/en-us/library/ee941099(WS.10).aspx

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
http://technet.microsoft.com/en-us/library/ee941099(WS.10).aspx

.

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationRefreshInterval
Data type: REG_DWORD
Range: 0x0 – 0xFFFFFFFF seconds
Default value: 0x15180 (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:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationTTL

.

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!!!!

.

You MUST 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
http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

.

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
http://blogs.technet.com/b/isrpfeplat/archive/2010/09/23/dns-scavenging-internals-or-what-is-the-dnstombstoned-attribute-for-ad-integrated-zones-dstombstoneinterval-dnstombstoned.aspx

.

Other articles on Scavenging:

Optimizing your network to keep your DNS squeaky clean
http://blogs.technet.com/b/networking/archive/2009/02/09/optimizing-your-network-to-keep-your-dns-squeaky-clean.aspx

.

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.

.

1.
https://qis15w.sn2.livefilestore.com/y1pK2oaDPwDuWcOKuruFE_mG60DX_JdOD9PUVuj8YEvK9bo-HK1WMPfHg3_smfglSU6RuKpxkxvZkP1mgb0AFJD_WZ-yUEOo6np/1.%20Set%20Aging-Scavenging%20for%20all%20zones.jpg?psid=1

.

2.
https://qis15w.sn2.livefilestore.com/y1pjeNJXBaiplqSW8EK6KEbWLD7awc19PpsNJEF6S5456DDriVTJUvCAsIH6EbpHb6zu3at6n2jZVN9BuOMVbNZdJQCCzFYi5I8/2.%20Using%20default%207%20day%20scavenge%20settings.jpg?psid=1

.

3.
https://qis15w.sn2.livefilestore.com/y1pBwESri4t7Ru2PHdykn2_lJm6yxE_QejQVUZP1ROdPqEnd6KenfqyHrYAtU8Vori8WyElUTu_3AjAPe6egZIyK6FuO_yRlJU8/3.%20Chose%20to%20apply%20this%20to%20all%20AD%20integrated%20zones.jpg?psid=1

.

4.
https://qis15w.sn2.livefilestore.com/y1pXZk5kHkkl6EvfrcSprvdxp80i2WdPYaOy5M6uo98Gj5t1Heop_AR2cWXXaCof3yxQ6ORbxUBVAT1C_iDc9hUuymzdwZy2psz/4.%20%20You%20can%20see%20when%20scavenging%20will%20kick%20in%20-%201%20day%20after%20the%207%20day%20No-refresh%20and%207%20day%20Refresh%20period.jpg?psid=1

.

5.
https://qis15w.sn2.livefilestore.com/y1pZdhGtBL_KWnpNMUTcSDkQWF21Ws8y_pkGvfQIZIp4GrHesAv-vl2uyrIhMu2MYm-3SyBa566R_ymHa9ja_ORyEce-cd2U09U/5.%20Set%20aging%20on%20contoso.com%20zone.jpg?psid=1

.

6.
https://qis15w.sn2.livefilestore.com/y1pkkRp01cx-ArzkC6hZ9SW1L2QwKOYK6lWRN5hE0NywrwCKD4a3fNTiwKuWLDIAoM9x0pCK3Z1b5tEZYVICF9qOoSecKMytReK/6.%20DNS%20Server%20Properties%2C%20Advanced%20Tab%2C%20Checked%20Enable%20Automatic%20Scavenging%20of%20stale%20records.%20This%20basically%20turns%20it%20on.jpg?psid=1

.

7.
https://qis15w.sn2.livefilestore.com/y1pInNfBbD8vssqF85PS8-Sgg-60yXVzmxA910iEz_yS2NlY5b8rRUJrr-KlP9dO79XdRksQvHmlrFCNz4FRWAjZmUDNjmguTq9/7.%20Ran%20dnscmd%20ageallrecords.jpg?psid=1

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.

.

8.
https://qis15w.sn2.livefilestore.com/y1pPWlVIC7sDUQkjxinOJhT0nEGJRi4Y_Gctkg_inp2g3ZiMJMSLM16uz_e7GQPEJ7zFqnx2T03n0eRnyZuF8m3Dudp0kdAPQfG/8.%20Restarted%20DNS%20%20although%20this%20is%20not%20necessary.jpg?psid=1

.

9.
https://qis15w.sn2.livefilestore.com/y1pD3XxvDENwxCwEzOVPbngly9Hb29y3Dq1esQItYpXWif5wiBfdBDn19r-O1lGYzGYApi8gEjCb83BvJP9JRXCCXeW-tjzTZUQ/9.%20NYC-DC1%20still%20shows%20as%20static.jpg?psid=1

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.
http://blogs.technet.com/b/isrpfeplat/archive/2010/09/23/dns-scavenging-internals-or-what-is-the-dnstombstoned-attribute-for-ad-integrated-zones-dstombstoneinterval-dnstombstoned.aspx

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.

Therefore, 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. Scavenging 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 constant 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”)
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

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
http://technet.microsoft.com/en-us/library/cc737924(WS.10).aspx

DHCP Best Practices
Look for: “Use server-side conflict detection on DHCP servers only when it is needed”
http://technet.microsoft.com/en-us/library/cc780311(WS.10).aspx

DHCP Server Conflict Detection
http://technet.microsoft.com/en-us/library/cc958918.aspx

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
http://technet.microsoft.com/en-us/library/cc958918.aspx

Specific info on the Ping command:

Ping – General Summary
http://en.wikipedia.org/wiki/Ping

Internet Control Message Protocol – Technical Summary
http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

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.

Reference:

DHCP console icons reference
http://technet.microsoft.com/en-us/library/cc784812(WS.10).aspx

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.
http://support.microsoft.com/kb/816592

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.
http://technet.microsoft.com/en-us/library/cc757041(WS.10).aspx

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
http://technet.microsoft.com/en-us/library/cc780760(WS.10).aspx

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 …
http://msmvps.com/ulfbsimonweidner/archive/2004/11/15/19325.aspx

And from Kevin Goodnecht:
Setting up DHCP for DNS registrations
http://support.wftx.us/setting_up_dhcp_for_dns_registra.htm

317590 – HOW TO Configure DNS Dynamic Update in Windows 2000 and DNSUpdateProxy Group:
http://support.microsoft.com/kb=317590

816592 – How to configure DNS dynamic updates in Windows Server 2003:
http://support.microsoft.com/kb/816592

Follow up discussion on the DNSUpdateProxy-Group:
http://msmvps.com/ulfbsimonweidner/archive/2005/03/26/39841.aspx
==================================================================

Back to top of page>

 

More to come… Comments are welcomed.

==================================================================

Summary

I hope this helps!

Published 8/13/2016

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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