DNS refuses dynamic updates from servers with manually configured IP addresses

2012-07-18

Question

_{Wednesday, July 18, 2012 1:11 PM}

Two weeks ago we turned on scavenging on Microsoft Windows Server 2008 R2 AD-integrated DNS. And 7 days later all the servers’ records were scavenged away. With hindsight I should have checked the timestamps before turning scavenging on. But what it revealed was that the computers with manually configured IP addresses were unable to update their DNS records dynamically because the DNS servers are refusing updates from computers which are not using DHCP.

The forest and domains are at Windows Server 2008 R2 functional level and there is a root domain with 2 child domains. The DNS is AD-integrated with secure updates and all the zones are forest-wide.

The vast majority of workstations use DHCP. The DHCP configuration was altered this year to allow the dynamic registration of non-Windows devices, so DHCP is doing dynamic updates, Windows Server 2008 R2’s Name Protection feature is on, and the updates are using a special domain user account. This is working fine and the devices which use DHCP, Windows and non-Windows, are updating their records.

The odd behaviour is where the IP address has been configured manually on the network adapter, mostly on servers, with register connection in DNS checked. Existing servers had their A and PTR records (we are not using IPv6), but it seems the timestamps were all old.

A new domain-joined server creates its A and PTR records without a problem, but it seems it can never update them. If you change its IP address, the records do not alter on the DNS server. However if you rename the server, it will create new records for the new name. Change the name back again and it can’t reregister the old name.

Furthermore if a server is removed to be replaced by a new server with the same name, the replacement server cannot overwrite the old record of the original server with the same name, and it cannot do this even if the A and PTR records of the original server have been deleted by hand.

It seems as if once a name record has been created, it can never be amended or reused.

At this point it looks as if the permissions must be wrong. But the DNS records turn out to be owned by each Computer Object and those computer accounts have all permissions that are visible in the DNS console and ADSIEdit.

The permissions on ForestDnsZones appear to be correct. I set up an isolated domain controller for a test new forest in case the years of upgrades which our forest has had since Windows Server 2000 had resulted in odd permissions, and our ForestDnsZones has exactly the same permissions as an out-of-the-box new Windows Server 2008 R2 forest, right down to the last detail. ADSIedit also show no duplicate or conflicting objects under ForestDnsZones or the 3 DomainDnsZones (which only contain root servers).

Deleted records also look as they should, with dNSTombstoned set to TRUE.

Creating a static record with the setting Allow Any Authenticated User to Update All Dns Records with the Same Name sets the write permission for Authenticated Users on the record’s object, but the DNS server still refuses the update.

And it is a refusal by the DNS servers. The debugging log for a transaction with a computer being updated successfully shows first an unauthenticated attempt which is refused and then an attempt with a TSIG section which results in an update performed with reply NOERROR. When a server with a manually configured IP address tries the second attempt with the TSIG is met with RCODE 5 REFUSED.

Ipconfig /registerdns simply causes another RCODE 5 REFUSED in the DNS debugging log. No event is recorded in the Event Viewer.

DCDiag shows everything to be OK there. The only fail is the DNS test for forwarders and root hints (which fails because there aren’t any forwarders we could put in and because it asks the root servers queries they can’t answer). In particular DCDiag is able to write and delete its test DNS records.

The domain controllers are completely unaffected. They can write and update their records.

I am not really sure when this began. Two suspects are: when we let the DHCP server update DNS records for its clients; and the update in MS12-017, KB2647170 – the latter because it replaced the same files and will have incorporated the earlier fix in KB2548145 http://support.microsoft.com/kb/2548145 which altered the behaviour of tombstoning and reusing objects in AD DNS. Neither is convincing since they would have affected large numbers of organizations.

In most cases I can create static records for the servers manually, though I’m a bit worried about the Exchange DAG’s cluster record. I would like to know what is going on here.

All replies (10)

_{Friday, July 20, 2012 1:13 PM ✅Answered}

I have found something. It looks like servers are prevented from updating their records because I created a GlobalNames zone and put CNAMEs for the servers in there (http://technet.microsoft.com/en-us/library/cc731744.aspx). A server which was having its updates refused has just succeeded after I deleted its CNAME from GlobalNames. GlobalNames was implemented to support the non-Windows devices which didn't have a domain-suffix search order listing. Maybe that wasn't such a great idea.

In which case anything placed in GlobalNames must also have static A records and not try to register itself.

_{Wednesday, July 18, 2012 7:44 PM}

It could be that these clients are no longer trusted by the domain. Check their eventvwr for domain errors.

_{Wednesday, July 18, 2012 11:44 PM}

In addition to hkd-naja's suggestion, there are a few things that can be going on.

Basically it comes down to patience with scavenging. If you selected to force scavenging, then any static records will be immediately marked with a time stamp and be eligible for scavening. We don't recommend this, rather just set it and walk away and allow it to happen. You didn't state the refresh and Norefresh period, but for example on a 3-day, you will have to wait a couple of weeks total for the cycle to fully implement, as seen in the graphic below:
[Scavenge interval] > ([No refresh interval] + [Refresh interval])

As for older records that were statically created, a machine will not be able to update them because the machine did not create them.

As for not dynamically registering, here are the basic rules to follow to allow registration to work:

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

AD & Dynamic DNS Registration Rules of engagement. Keep in mind, for the most part it automatically works "out of the box" without much administrative overhead.

===
Summary

The machine's DNS entries in the NIC, must be ONLY configured to use the internal DNS servers that host the zone. No others.
a. DHCP Option 006 MUST only be the internal DNS server(s) you want to use, otherwise if using an ISP's DNS or your router, expect undesired results.
The Primary DNS Suffix on the machine MUST match the zone name in DNS.
a. For joined machines, this is default.
b. For non-joined machines, it must be manually configured or scripted.
If using DHCP Option 015 (Connection Specific Suffix), it must match the zone nam and have "Use This Connection's DNS Suffix in DNS Registration" along with "Register This Connection's Addresses in DNS" checked in the NIC's IPv4, Advanced, DNS tab.
The Zone must be configured to allow updates.
For AD Integrated Zones and Secure Only Updates:
   a. If the machine's DNS is statically configured:
      - It must only point to the internal DNS
      - It must be joined to the domain in order to authenticate using Kerberos to update.
   b. If statically configured and not joined to the domain, the client can't update if the zone is set to Secure Only.
   c. For non-joined domain DHCP clients, you can configure DHCP to update in lieu of the client updating into a Secure Only zone.
For any non-Windows statically configured machine, it must support the DNS Dynamic Updates feature and the zone configured to allow Secure and Unsecure updates.
If the DNS server is multihomed and not configured properly to work with multihoming, it may cause problems with Dynamic Updates.
If the zone is single label name, such as 'domain' instead of the proper minimal format of 'domain.com,' 'domain.net,' etc, it will NOT update.
The client will "look" for the SOA of the zone when it attempts registration. If the SOA is not available or resolvable, it won't register. Keep in mind with AD integrated zones the SOA rotates among the DCs because of the multimaster feature. This is default and expected behavior, but if there are any DCs that have any problems, and the client resolved the SOA to that DC, it may not accept the update.
The zone in DNS must NOT be a single lable name, such as "DOMAIN" instead of the required minimum of two hierarchal levels such as domain.com, domain.local, domain.me, domain.you, etc. Single label name zones are problematic, do not conform to the DNS RFC, and causes excessive internet traffic to the Root Servers when DNS tries to resolve a single label name query, such as querying for computername.domain - in such a query, the domain name is actually treated as a TLD. ISC has made a note of the excessive traffic generated by Microsoft DNS servers configured with a single label name in 2004 with Microsoft, which in turn disabled the ability for Microsoft DNS in Windows 2000 SP4 and newer to resolve single label names without a registry bandaid. More info on this:

Active Directory DNS Domain Name Single Label Names - Problematic
Published by Ace Fekay, MCT, MVP DS on Nov 12, 2009 at 6:25 PM 641 0
http://msmvps.com/blogs/acefekay/archive/2009/11/12/active-directory-dns-domain-name-single-label-names.aspx

More info:

Understanding Dynamic Update, Applies To: Windows Server 2008, Windows Server 2008 R2, and newer
http://technet.microsoft.com/en-us/library/cc771255.aspx

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

DHCP Configuration:

Regarding DHCP configuration, maybe I missed it in your post, but did you configure DHCP to use credentials or the DnsUpdateProxy group? More info on this and scavenging below:

This link covers the following:
DHCP Service Configuration, Dynamic DNS Updates, Scavenging, Static Entries, Timestamps, DnsUpdateProxy Group, DHCP Credentials, prevent duplicate DNS records, DHCP has a "pen" icon, and more...
Published by Ace Fekay, MCT, MVP DS on Aug 20, 2009 at 10:36 AM 3758 2
http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx

DNS Record Ownership and the DnsUpdateProxy Group
Updated: November 10, 2008
http://technet.microsoft.com/en-us/library/dd334715(v=WS.10).aspx

Good article 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, 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

Don't be afraid of DNS Scavenging. Just be patient.
http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

Secure updates uses Kerberos:

One more thing, if set to Secure Only, then Kerberos is used to authenticate the registration attempt. If there are any machines not joined to the domain, or they are missing the primary DNS suffix (or other issues stated in that list above), then they won't be able to register.

Multihomed DHCP and/or DC/DNS servers?

If this is the case, that will definitely cause a problem!

Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & Exchange 2010, Exchange 2010 EA, 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 post is provided AS-IS with no warranties or guarantees and confers no rights.

_{Thursday, July 19, 2012 7:09 AM}

Sorry, guys, none of that helps. The servers are properly domain-joined; there are no errors at all in most of their event logs and they don't have a problem with their domain membership. Their DNS suffixes are correct. I have tried removing from the domain and rejoining, and new machines, and I'm sure there isn't a domain trust problem logging anywhere nor any symptoms of such a thing - and the DNS works once if you rename the machine.

I think scavenging is at this point irrelevant since it is off and it is not coming back. DHCP is not being used by these computers. Ace, I had been through your major blog posts and the others you reference before I posted, and I have checked everything you list.

_{Thursday, July 19, 2012 3:21 PM}

Apparently it seems you've combed over everything and covered all angles. Maybe there's something going on that we are all overlooking.

One thing else comes to mind is the time service, which Kerberos relies on (if 5 min skew or greater between two machines, auth is rejected). If the DCs are in a virtual environment, then the recommendation is if you have VMWare, to disable the VMWare host's time sync service, or if you have HyperV, to "partially" disable the host time service. Of course, I assume that your PDC at the forest root is already configured to sync with a reliable outside time source.

Otherwise, I would suggest as this time to give Microsoft Support a call for specific assistance. They can remote in and take a look at all factors to come up with a resolution. Here's the link with the phone numbers to get you started if you choose this option:
http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS

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

_{Thursday, July 19, 2012 5:26 PM}

What about the DHCP and DNS client services. Are they set to automatic and started?

_{Friday, July 20, 2012 6:46 AM}

If the services weren't started they wouldn't be making a registration attempt which is actively refused by the DNS server.

_{Friday, July 20, 2012 1:52 PM}

GNZ is something MS tried to eliminate or even reduce WINS usage but.... truly it doesn't. It's a useless feature from my pov since you have to manage the records manually. In WINS you don't have to manage them manually. WINS isn't great neither GNZ (even worse in my pov).

In other words, what I suggest is that you keep WINS as good as you can if you have it and don't bother about GNZ.

_{Friday, July 20, 2012 1:53 PM}

If the services weren't started they wouldn't be making a registration attempt which is actively refused by the DNS server.

true. my bad.

_{Friday, July 20, 2012 5:22 PM}

I have found something. It looks like servers are prevented from updating their records because I created a GlobalNames zone and put CNAMEs for the servers in there (http://technet.microsoft.com/en-us/library/cc731744.aspx). A server which was having its updates refused has just succeeded after I deleted its CNAME from GlobalNames. GlobalNames was implemented to support the non-Windows devices which didn't have a domain-suffix search order listing. Maybe that wasn't such a great idea.

In which case anything placed in GlobalNames must also have static A records and not try to register itself.

Good to hear that you resolved it. I didn't even think to ask about GNZs, but I knew they were problematic with registration. At least you nailed it.

Despite its IPv6 shortcomings, I still think that WINS is a better solution to keep in place. Even if you were to use IPv6 for DIrectAccess or other solutions, WINS still gives you that flat namespace support, including of course Network Neighborhood, browsing capabilities that people are used to, etc.

Cheers!

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

Share via

DNS refuses dynamic updates from servers with manually configured IP addresses

Question

All replies (10)

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

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

Additional resources