DNS Issues in a domain - PTR Records and A records Deleting when a user logs onto their workstation

Hi,

Check the scavenging duration of DNS server (http://blogs.technet.com/b/askpfe/archive/2011/06/03/how-dns-scavenging-and-the-dhcp-lease-duration-relate.aspx)

also lets try to track how the DNS records getting deleted.

http://blogs.technet.com/b/networking/archive/2011/08/17/tracking-dns-record-deletion.aspx

The account used for credentials should be standard domain user account

Also please try re entering account with correct password because if you enter password incorrectly, it will not pops up any error but can create issues

Also add your DHCP server in DNSUPDATEPROXY group on DNS server and run below command on DNS server (DC) with elevated command prompt
dnscmd /config /OpenAclOnProxyUpdates 0

Now just restart DHCP and DNS service and check if issue is resolved or not

Mahesh.

Hi Santosh,

The Zone Againg and Scavenging is set for 7 days - Please see attached screen shot.

I was also able to setup auditing, below is the message I can see in the audit history after I logged into the workstation :

Hen I logged in

An operation was performed on an object.

Subject :
      Security ID:            SYSTEM
      Account Name:            WALDC1$
      Account Domain:            WINTERWYMAN
      Logon ID:            0x1cadbcf6

Object:
      Object Server:            DS
      Object Type:            dnsNode
      Object Name:            DC=waltham3065,DC=winterwyman.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=winterwyman,DC=local
      Handle ID:            0x0

Operation:
      Operation Type:            Object Access
      Accesses:            Write Property
                        
      Access Mask:            0x20
      Properties:            Write Property
            {771727b1-31b8-4cdf-ae62-4fe39fadf89e}
                  {e0fa1e69-9b45-11d0-afdd-00c04fd930c9}
                  {d5eb2eb7-be4e-463b-a214-634a44d7392e}
      {e0fa1e8c-9b45-11d0-afdd-00c04fd930c9}


Additional Information:
      Parameter 1:            -
      Parameter 2:

------------------

An operation was performed on an object.

Subject :
      Security ID:            WINTERWYMAN\Administrator
      Account Name:            Administrator
      Account Domain:            WINTERWYMAN
      Logon ID:            0x1ccf12eb

Object:
      Object Server:            DS
      Object Type:            dnsNode
      Object Name:            DC=38,DC=13.10.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=winterwyman,DC=local
      Handle ID:            0x0

Operation:
      Operation Type:            Object Access
      Accesses:            Write Property
                        
      Access Mask:            0x20
      Properties:            Write Property
            {771727b1-31b8-4cdf-ae62-4fe39fadf89e}
                  {e0fa1e69-9b45-11d0-afdd-00c04fd930c9}
                  {d5eb2eb7-be4e-463b-a214-634a44d7392e}
      {e0fa1e8c-9b45-11d0-afdd-00c04fd930c9}


Additional Information:
Rate-for-DNS.JPG

Hi Mahesh,

I tried the above steps you provided, that did not resolve the issue.

I did stop and start DNS & DHCP service as well.

Hi,

first log says it happened due to scavenging.

pls share the event log ID also.

Hi Santosh,

I took screen shots of each of the event logs - Please see attached.
Event-Log.JPG
Event-Log-2.JPG

Hi,

both logs are showing that record is deleted by administrator and DC itself.

http://blogs.technet.com/b/networking/archive/2011/08/17/tracking-dns-record-deletion.aspx

As per Microsoft, This issue occurs because of an issue in the DNS Client service. When the DNS server configuration information is changed on a client, the DNS Client service deletes the DNS host record of the client from the old DNS server and then adds it to the new DNS server. Because the DNS record is present on the new server that is a part of the same domain, the record is not updated. However, the old DNS server replicates the deletion operation to the new DNS server and to other DNS servers. Therefore, the new DNS server deletes the record, and the record is deleted across the domain.

hotfix-
http://support.microsoft.com/kb/2520155

I wondering if there's a possible conflict with the settings in DHCP and those you have set through Group Policy.  The DHCP settings are telling the DHCP server to register both the A and PTR records, while the GP settings are telling the client to register the PTR record.

Are you only allowing secure dynamic updates in your zones?

I need something clarified.  Are you saying that the records are created as they should be when the workstation starts up (and they remain that way), and that it's only when a user logs on to the workstation that the records are deleted?

Hi Santosh,

I pushed out the hotfix tonight on the DNS server that is handing out the 10.10.13.x range.

It performed a restart of the DC

Once I restarted it, I found the issue is still occurring.

I was thinking of pushing the hotfix on the other DNS server in the office but I wanted to verify that all DNS servers should be updated?

Hi footech,

I found when I disabled the GPO policy the issue still occurred. (Note I did keep the PTR record creation during my test)

Yes, once the workstation has booted DNS will create PTR and Forward zone records but once the user logged in, the records are deleted out the forward and reverse zones.

Note this is how I reproduce the issue:

1. I check the zones on the DNS server that is handing out 10.10.13.X  and ensure that the records are both each in the correct zones (forward and reverse zones) for the host I am testing.

2. I then log onto the host using my account or a test account.

3. Once logged in, I go back to the DNS server and then refresh the forward zone. I will then notice that the A record and PTR record have been deleted.

Please note that I can from that point go back onto the host and perform a ipconfig /registerdns and it will register the record back into the forward and reverse zones.

As far as dymanic updates, I believe that dymanic updates is the only item that we are allowing (set on the DHCP server) but could you provide the settings you are looking to see to verify this?

The goal / place I would like to get this to is to have both the PTR records and forward zone records created for each client that is provided a IP address in the domain.

I hope this information helps but let me know if there any additional information I can provide.

I think Footech is right

After removing policy have you checked client computers that policy have been removed from them because policy will make changes to registry on clients

So instead of removing policy can you please try to undone settings in policy and keep policy applied on machines to check with.

Hi Mahesh,

I updated our group policy to remove those set settings.

Please see screen shot.

I then updated the policy and verified by group policy wizard that the settings were no longer applied.

I then removed the workstation IP address from DHCP, DNS in both the forward and reverse zones.

I then restarted the workstation and verified that the both the forward and reverse zones records were created. I logged into the workstation and found that the records will still delete.

Please note, I can stop this issue from occurring when I remove the DNS Dynamic Registration credentials.

When I do this, the forward zone record will create however the PTR record will not.

I have also attached a screen shot of the IPV4 DHCP scope Properties.


-----------------

Screen shots

Please select checkbox "Discard A and PTR records when lease is deleted"
This will delete DHCP lease from DHCP console automatically when lease get expires.

also select Dynamically update DNS A and PTR records only if requested by DHCP clients
This setting causes A records will be registered by client and PTR will be registered by DHCP, only you have to set credentials in DHCP Console

Credentials are already set in DHCP as per your old comment

This will give A record ownership to client computers and hopefully your records will not get deleted automatically

Also remove DHCP server from DNSUPdateProxy Group on DNS server

Then check if it works

Mahesh.

Hi Mahesh,

I was able to select dynamically update DNS A and PTR Records only if requested by DHCP Clients and then removed the DHCP server from the DNSupdateproxy group.

Unfortunately, I still continue to see the issue.

can you please go to properties of dynamic A record and check its security permissions please
Also check scavenging settings for that record

You need to click view \ advanced in DNS console in order to view advanced settings of A record

May be both screen shot is helpful

Also i hope in dns zone properties dynamic update is set to secure only

Mahesh.

Also just try to disable antivirus software completely on domain controller and check if it works

It might be AV causing this problem

I can't think of anything in the basic process of dynamic updates that occurs at user logon.  Do you have something like VLAN assignment or 802.1x authentication occurring based on which user logs on to a computer?  Maybe some user script assigned via GPO that would affect this?

Previously you showed the results from some 4662 events, but what about others (like 5136 or 5141)?  Here's a link with some additional information about DNS auditing.
http://blogs.technet.com/b/askpfeplat/archive/2013/10/12/who-moved-the-dns-cheese-auditing-for-ad-integrated-dns-zone-and-record-deletions.aspx

Hi Footech,

One item I just tried was placing both the workstation and a user into an OU blocking all GPO Polices.

The issue still remains so I do not believe it is a Group Policy causing this issue.

We do not have any VLAN or 802.1x authentication occurring based on which user logs onto a computer.

Please see below for the attach screen shots of the events that occurred around the timeframe of the DNS events I posted from above.

Here are the events between the 4662 from yesterday:

A logon was attempted using explicit credentials.

Subject:
      Security ID:            NETWORK SERVICE
      Account Name:            WALDC1$
      Account Domain:            WINTERWYMAN
      Logon ID:            0x3e4
      Logon GUID:            {00000000-0000-0000-0000-000000000000}

Account Whose Credentials Were Used:
      Account Name:            administrator
      Account Domain:            WINTERWYMAN.LOCAL
      Logon GUID:            {00000000-0000-0000-0000-000000000000}

Target Server:
      Target Server Name:      waldc1.winterwyman.local
      Additional Information:      DNS/waldc1.winterwyman.local

Process Information:
      Process ID:            0x614
      Process Name:            C:\Windows\System32\svchost.exe

Network Information:
      Network Address:      -
      Port:                  -

This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials.  This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command.

An account was logged off.

Subject:
      Security ID:            WINTERWYMAN\Administrator
      Account Name:            Administrator
      Account Domain:            WINTERWYMAN
      Logon ID:            0x1cceb4af

Logon Type:                  3

This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer

Special privileges assigned to new logon.

Subject:
      Security ID:            WINTERWYMAN\Administrator
      Account Name:            Administrator
      Account Domain:            WINTERWYMAN
      Logon ID:            0x1ccf12eb

Privileges:            SeSecurityPrivilege
                  SeBackupPrivilege
                  SeRestorePrivilege
                  SeTakeOwnershipPrivilege
                  SeDebugPrivilege
                  SeSystemEnvironmentPrivilege
                  SeLoadDriverPrivilege
                  SeImpersonatePrivilege
                  SeEnableDelegationPrivilege
                  SeTcbPrivilege

An account was successfully logged on.

Subject:
      Security ID:            NULL SID
      Account Name:            -
      Account Domain:            -
      Logon ID:            0x0

Logon Type:                  3

New Logon:
      Security ID:            WINTERWYMAN\Administrator
      Account Name:            Administrator
      Account Domain:            WINTERWYMAN
      Logon ID:            0x1ccf12eb
      Logon GUID:            {2cacb48f-5566-8428-f30f-db8394046d18}

Process Information:
      Process ID:            0x0
      Process Name:            -

Network Information:
      Workstation Name:      
      Source Network Address:      -
      Source Port:            -

Detailed Authentication Information:
      Logon Process:            Kerberos
      Authentication Package:      Kerberos
      Transited Services:      -
      Package Name (NTLM only):      -
      Key Length:            0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
      - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
      - Transited services indicate which intermediate services have participated in this logon request.
      - Package name indicates which sub-protocol was used among the NTLM protocols.
      - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Mahesh:

To your questions above, our zones are secure only.

Also, attached are the A Host record and the security settings on the record.
administrators.JPG
Capture.JPG
dnsadmin.JPG
domain-admins.JPG
domain-controllers.JPG
enterprise.JPG
everyone.JPG
prewindows.JPG
self.JPG
system.JPG

I would expect to see an ACE with the account used by DHCP to perform DNS dynamic updates (this account should be a standard domain user, and this should be the same on each DHCP server), with full permissions on the record.
If the record was created by the client, I would expect to see an ACE with the computer account, with full permissions.
Since I don't see any of those, I'm thinking that the DNSUpdateProxy group is involved here.  Does this group contain anything other than the DCHP servers?  I see that Mahesh already provided some guidance along these lines, but you might want to check out this link and follow the steps for configuration.
http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx

What OS is each DHCP server running?

Just an update - I did try this scenario and got different results:

1. I took a non domain machine, laptop and connected it to our internal network.

2. It got an ip address of 10.10.13.38 and created both a A host record and a PTR record.

3. I logged int the laptop, and the record did not delete.

4. I then restarted the laptop and then logged in, the records did not delete.

So, I think the issue is still on the workstation.

In all screen shots I don't see the computer account (Computername$) has got full permissions on A record

After you have made changes to DHCP option "Dynamically update DNS A and PTR records only if requested by DHCP clients" the computer account whose A record is that must have full control permissions on that record
You might check record ownership
Please try below
Add computer name with full control on NTFS permissions  on A record and also grant record ownership to that computer account and then check if its works \ I mean check if record get deleted

You need to check if same account is configured on each DHCP server as suggested by Footech

The link shared above is really good

You might try installing DHCP on another member server for to give a try and check if its works

Mahesh.

What it feels like is happening is that the computer initially gets an IP and DHCP creates the records (but it doesn't look like they are secure), then for some reason when a user logs on, the computer tries to update the records and ends up deleting them.  This would explain why for a non domain-joined machine it doesn't delete the records, because it doesn't have credentials needed for the secure zone.  The "for some reason" is not clear to me though.

This is strange

if you have laptop in workgroup and if your DNS zone is set to secure dynamic update only, then laptop A record should not get created in DNS

As a fact only those records should get created in DNS dynamically which are authenticated

Your workgroup laptop is not authenticated via active directory

Are you mean that you have logged on domain joined laptop with local account or really Laptop is in workgroup ?

Mahesh.

if you have laptop in workgroup and if your DNS zone is set to secure dynamic update only, then laptop A record should not get created in DNS

That's true if if the DHCP option 81 is set to "Dynamically update DNS A and PTR records only if requested by DHCP clients".  If it is set to "Always Dynamically Update DNS A and PTR Records" then the behavior matches.

One other test I would do:  After logging in, instead of launching the Mitel toolbar, run ipconfig /registerdns.  At that point does the DNS record get deleted or updated (compare ACL before and after)?  Lastly start the toolbar and check the record again.

Good detective work on finding what is involved at user logon.  I wonder if it uses the Windows processes for dynamic updates or if it's trying to make an update directly from its own process.

That's true if if the DHCP option 81 is set to "Dynamically update DNS A and PTR records only if requested by DHCP clients".  If it is set to "Always Dynamically Update DNS A and PTR Records" then the behavior matches.

One other test I would do:  After logging in, instead of launching the Mitel toolbar, run ipconfig /registerdns.  At that point does the DNS record get deleted or updated (compare ACL before and after)?  Lastly start the toolbar and check the record again.

Good detective work on finding what is involved at user logon.  I wonder if it uses the Windows processes for dynamic updates or if it's trying to make an update directly from its own process.

I am still in the process of troubleshooting the software but I did try your test by ipconfig/ registerdns before opening the mitel toolbar, then I opened the toolbar and found the records still deleted.

I even changed the DHCP server option to Dynamially update DNS A and PTR records only if request by the DHCP Clients and the issue still occurs.

I've requested that this question be deleted for the following reason:

The question has either no comments or not enough useful information to be called an "answer".

The bulk of the answer is provided in http:#a39990487, the cause being the "UCA Express Mitel Toolbar" software.  Although the reason why this software is causing the problem isn't fully explained (whether it is due a setting within the software, fault installation, etc.), just naming the software is enough to accept that post as the answer.