Tuesday, November 3, 2015

DNS Error 4015

So ever since upgrading our domain from Server 2008 R2 to Server 2012 R2, we have been plagued with the occasional DNS error 4015.

Log Name:      DNS Server
Source:        Microsoft-Windows-DNS-Server-Service
Date:          10/26/2015 8:03:16 AM
Event ID:      4015
Task Category: None
Level:         Error
Keywords:      (131072)
User:          SYSTEM
Computer:      DC4.MYCOMPANY.ORG
Description:
The DNS server has encountered a critical error from the Active Directory. Check that the Active Directory is functioning properly. The extended error debug information (which may be empty) is "000020E6: SvcErr: DSID-031406C7, problem 5012 (DIR_ERROR), data 2". The event data contains the error.

Running a battery of tests after the event appears to indicate that both Active Directory and DNS are in perfect health.

After opening a call with Microsoft, they had little to offer, other than the order of the DNS servers configured in the DNS client, should point primarily at a peer and then to itself. I accept that this has been Microsoft best practice for some years, but I had the client configured to point to itself first and then to a peer (a habit I picked up when that was best practice some years before).

I changed the order on all domain controllers and the number of instances reduced. I find this weird, since the only argument I have ever heard to support Microsoft's current best practice, is related to boot time of a Domain Controller and a particular disaster recovery scenario. However, it did seem to have a positive effect and that's good. However, across our 24 Domain Controllers, I continued to have the issue around once per week. I then got to thinking about something that I have been ignoring for sometime. Lets take a look at the result of an IPCONFIG /ALL on a Domain Controller:


Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. All rights reserved.

PS C:\Users\putleym.STLUKES-INT> ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . : DC4
   Primary Dns Suffix  . . . . . . : MYCOMPANY.ORG
   Node Type . . . . . . . . . . . : Peer-Peer
   IP Routing Enabled. . . . . . . : No
   WINS Proxy Enabled. . . . . . . : No
   DNS Suffix Search List. . . . . : MYCOMPANY.ORG

Ethernet adapter Corp:

   Connection-specific DNS Suffix  :
   Description . . . . . . . . . . : vmxnet3 Ethernet Adapter
   Physical Address. . . . . . . . : 00-50-56-FF-6A-E4
   DHCP Enabled. . . . . . . . . . : No
   Autoconfiguration Enabled . . . : Yes
   Link-local IPv6 Address . . . . : fe80::c4aa:12ab:4dd9:169%12
   IPv4 Address. . . . . . . . . . : 171.99.2.81(Preferred)
   Subnet Mask . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . : 171.99.2.1
   DHCPv6 IAID . . . . . . . . . . : 385896534
   DHCPv6 Client DUID. . . . . . . : 00-01-FF-01-1C-D3-3B-B0-00
   DNS Servers . . . . . . . . . . : ::1   -- WTF!?!?
                                     101.99.11.122
                                     101.112.1.22
                                     171.99.2.81
   Primary WINS Server . . . . . . : 101.160.0.83
   Secondary WINS Server . . . . . : 101.20.79.10
   NetBIOS over Tcpip. . . . . . . : Enabled

Tunnel adapter isatap.{278B8799-D6AB-4A60-9E62-D41B6894B583}:

   Media State . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  :
   Description . . . . . . . . . . : Microsoft ISATAP Adapter #2
   Physical Address. . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . : No
   Autoconfiguration Enabled . . . : Yes



You will notice that while the IPv4 addresses for DNS reflects two peers and then itself, the IPv6 loop-back address (::1) is still listed as the primary (highlighted in RED). Since, per best practice IPv6 is enabled on the server (despite the fact that we do not route IPv6 internally) and IPv6 is 'preferred' by the operating system, I remain in a scenario where the server is looking to itself for DNS in the first instance.

So what's the fix?



If you take a look at the IPv6 properties, then you can see the loop-back IPv6 address has been erroneously added to the DNS server list, contrary to Microsoft's own best practice. It is for that reason that, in my opinion, this is a BUG.

So simply nix that, by changing it to DHCP, thus


A double check of our IPCONFIG / All shows the desired result:

Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. All rights reserved.

PS C:\Users\putleym.STLUKES-INT> ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . : DC4
   Primary Dns Suffix  . . . . . . : MYCOMPANY.ORG
   Node Type . . . . . . . . . . . : Peer-Peer
   IP Routing Enabled. . . . . . . : No
   WINS Proxy Enabled. . . . . . . : No
   DNS Suffix Search List. . . . . : MYCOMPANY.ORG

Ethernet adapter Corp:

   Connection-specific DNS Suffix  :
   Description . . . . . . . . . . : vmxnet3 Ethernet Adapter
   Physical Address. . . . . . . . : 00-50-56-FF-6A-E4
   DHCP Enabled. . . . . . . . . . : No
   Autoconfiguration Enabled . . . : Yes
   Link-local IPv6 Address . . . . : fe80::c4aa:12ab:4dd9:169%12
   IPv4 Address. . . . . . . . . . . 171.99.2.81(Preferred)
   Subnet Mask . . . . . . . . . . . 255.255.255.0
   Default Gateway . . . . . . . . . 171.99.2.1
   DHCPv6 IAID . . . . . . . . . . . 385896534
   DHCPv6 Client DUID. . . . . . . . 00-01-FF-01-1C-D3-3B-B0-00-50
   DNS Servers . . . . . . . . . . : 101.99.11.122
                                     101.112.1.22
                                     171.99.2.81
   Primary WINS Server . . . . . . : 101.160.0.83
   Secondary WINS Server . . . . . : 101.20.79.10
   NetBIOS over Tcpip. . . . . . . : Enabled

Tunnel adapter isatap.{278B8799-D6AB-4A60-9E62-D41B6894B583}:

   Media State . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  :
   Description . . . . . . . . . . : Microsoft ISATAP Adapter #2
   Physical Address. . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . : No
   Autoconfiguration Enabled . . . : Yes


Cheers!



No comments:

Post a Comment