I've run into a strange one. Today I noticed that clients weren't registering their A records in DNS.

Our setup:

  • AD integrated zone - dynamic secure updates enabled on the domain zone.
  • Windows XP/ 7 clients
  • DNS specific search suffixes are pushed out to PCs
    • Primary DNS suffix is listed first
  • All clients are members of domain
  • Clients are receiving DNS Servers via DHCP
  • Clients are receiving DNS domain name via DHCP

Scavenging settings have all been ruled out as the cause of the problem.

Proper functionality would be the clients use their primary DNS suffix to register their A record with the DNS server. However, this is not happening. The only way I have been able to get the clients to register correctly is to enable the "Register DNS records with connection-specific DNS Suffix" setting in TCP/IP settings.

I can push that setting out via GPO to get the clients to register, but this seems like a band-aide.

We have other sites/ subnets that have no issues dynamically updating their dns records. These sites/ subnets have DCs that replicate to the DNS servers that are not receiving the dynamic updates from our site.

The only difference I can find is that the sites that operate correctly do not have the DNS domain name set via Group Policy.

I plan to test tomorrow by creating a new subnet that does not push out the DNS Domain Name setting. I will then see if a PC on that subnet can register it's name without having to enable the connection-specific setting.

Until then, has anyone run into anything like this or have any suggestions?


The only difference I can find is that the sites that operate correctly do not have the DNS domain name set via Group Policy.

Is group policy setting it to something that doesn't match the DNS zone?

The DHCP settings will set the connection-specific suffix, which is great for name resolution, but for registration it's going to want to use the system-wide primary DNS suffix, which is apparently getting set by group policy - which ought not be necessary for domain computers unless there's some very odd things going on with your name resolution.

The setting in question is at Computer -> Administrative Templates -> Network -> DNS Client -> Primary DNS Suffix

Check what it's set to on the broken systems; it shows up at the very top of the output of ipconfig /all:

C:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : systemname
   Primary Dns Suffix  . . . . . . . : domain.com
   Node Type . . . . . . . . . . . . : Peer
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : domain.com

If that primary suffix doesn't exactly match to your DNS zone, then that's your culprit.

| improve this answer | |
  • That's the interesting part, the Primary DNS suffix and the Connection-specific DNS suffix are the same. And it's only the search suffix list order that's pushed via GPO. The primary DNS suffix isn't set via GPO. – HostBits Jun 16 '11 at 22:45
  • Also, both Primary DNS & Connection-Specific DNS suffixes match our FQDN of the domain. – HostBits Jun 17 '11 at 1:23

Your DHCP server is most likely handling DNS record registrations since this is the default. If so, are the credentials set properly in DHCP management?

Have a look on the Advanced tab of the IPv4 node in DHCP management console for: DNS Dynamic updates registration credentials


| improve this answer | |

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.