I am administering a system which for reasons beyond my control have a disjoint DNS namespace. I don't like it, but that's how it is, and I have no way of changing this. The reason is that the servers need to co-exist with a pre-existing DNS infrastructure.

The Windows Domain is named something like ad.example.com with a NETBIOS name of AD. However, all DNS servers have their primary DNS suffix set either to "example.com" or to "sub.example.com", depending on where in the network they are. I have configured the msDS-AllowedDNSSuffixes attribute in the domain, according to the Create a Disjoint Namespace article on Technet.

The DNS for the ad.example.com domain is run on the two domain controllers in the environment, and the DNS for the example.com and the sub.example.com are run on other non-Microsoft DNS servers.

In this environment, DNS is managed manually, rather than relying on Dynamic DNS registration and updates.

The environment works fine, except for some annoying warning errors that appear in the event logs, that look like this:

The system failed to register host (A or AAAA) resource records (RRs) for
network adapter with settings:

Adapter Name : <censored>
Host Name : <censored>
Primary Domain Suffix : sub.example.com
DNS server list :
<censored> (These are the domain controllers for ad.example.com)
Sent update to server : <?>
IP Address(es) :
<censored> (This is the IP address of the host in question)

The reason the system could not register these RRs was because of a security related
problem. The cause of this could be (a) your computer does not have permissions
to register and update the specific DNS domain name set for this adapter, or 
(b) there might have been a problem negotiating valid credentials with the DNS
server during the processing of the update request.

You can manually retry DNS registration of the network adapter and its settings
by typing 'ipconfig /registerdns' at the command prompt. If problems still persist,
contact your DNS server or network systems administrator. See event details for
specific error code information.

The errors appear in the System log, with source being "DNS Client Events", at the Warning level, with Event ID 8015.

Doing a packet sniff it does appear that the Windows boxes appear to do Dynamic DNS updates to the authoritative DNS server of sub.example.com, which does not support Dynamic Updates (nor do we want to enable them).

Therefore, we set ourselves the task of disabling the dynamic DNS updates using group policy.

On Friday, I created a group policy, and linked it to the top of the domain as in the screenshot below:

Group Policy Management Editor showing the policy

The policy Computer Configuration / Policies / Administrative Templates / Network / DNS Client / Dynamic Updates has been set to Disable.

However, even after several days (ample time for the group policy to replicate and to apply to the servers), these events continue to appear in the logs.

I have verified using GPRESULT that the policy has indeed been applied on the server in question.

The output of gpresult /scope Computer /v is here below (with some irrelevant data removed for anonymization purposes):

Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
© 2013 Microsoft Corporation. All rights reserved.

Created on 2015-10-05 at 15:06:54

RSOP data for AD\ad79632 on BESTLA : Logging Mode

OS Configuration:            Member Server
OS Version:                  6.3.9600
Site Name:                   Example
Roaming Profile:             N/A
Local Profile:               C:\Users\ad79632
Connected over a slow link?: No

    Last time Group Policy was applied: 2015-10-05 at 14:09:58
    Group Policy was applied from:      dc02.example.com
    Group Policy slow link threshold:   500 kbps
    Domain Name:                        AD
    Domain Type:                        Windows 2008 or later

    Applied Group Policy Objects
<some GPOs omitted for security reasons>
        Disable Dynamic DNS Updates

    The following GPOs were not applied because they were filtered out
        Local Group Policy
            Filtering:  Not Applied (Empty)

    The computer is a part of the following security groups
        RDS Endpoint Servers
        RDS Management Servers
        RDS Remote Access Servers
        NT AUTHORITY\Authenticated Users
        This Organization
        Day-active Computers
        Domain Computers
        Authentication authority asserted identity
        System Mandatory Level

    Resultant Set Of Policies for Computer

        Software Installations

        Startup Scripts

        Shutdown Scripts

        Account Policies
<some GPOs omitted for security reasons>

        Audit Policy

        User Rights

        Security Options
<some GPOs omitted for security reasons>

        Event Log Settings

        Restricted Groups

        System Services

        Registry Settings

        File System Settings

        Public Key Policies

        Administrative Templates
<some GPOs omitted for security reasons>
            GPO: Disable Dynamic DNS Updates
                Folder Id: SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\RegistrationEnabled
                Value:       0, 0, 0, 0
                State:       Enabled
<some GPOs omitted for security reasons>

The registry key in question has actually been updated as can be seen in this screenshot:

Screenshot of regedit showing the registry key

So, what am I missing?

  • This group policy needs to land on the individual client computers. What does gpresult show on a client? gpresult /Scope Computer /v – Brian Oct 5 '15 at 12:37
  • @Brian I have added sanitized gpresult output and a screenshot of regedit to the question, showing that the intended registry key does land inside the registry. – Per von Zweigbergk Oct 5 '15 at 13:17
  • What about the DisableDynamicUpdate registry key in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters? – Brian Oct 5 '15 at 14:13
  • Does the problem occur on multiple targets or only a single target? – Clayton Oct 5 '15 at 15:12
  • @Brian That parameter is not in the registry. That's odd, is there a different policy for newer OS:es that I should be using? – Per von Zweigbergk Oct 5 '15 at 17:43

It appears that I was doing everything correctly, except that rebooting was neccessary to stop these messages from occurring, as @Brian suggested in a comment.

I will just wait until our next patch window, which will mean the servers rebooting anyway, since this is not a critical issue. I then expect this message to be gone on all servers.

| improve this answer | |
  • 1
    After rebooting all servers, these messages have indeed disappeared as I expected. – Per von Zweigbergk Oct 21 '15 at 14:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.