Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

After having upgraded a Windows Server 2003 Active Directory Domain to Server 2008, and upgraded client PCs from Windows XP to Windows 7, I'm seeing inconsistent dynamic DNS update behaviour.

Two domain controllers also have a DHCP and DNS role. Each DHCP server has the 'DNS dynamic updates registration credentials' setting populated with a user account which is a member of the 'DnsUpdateProxy' group, and (although I've seen arguments for and against) I've added the servers themselves to the 'DnsUpdateProxy' group.

The DHCP servers are configured with the following settings ticked:

'Enable DNS dynamic updates according to the settings below' 'Always dynamically update DNS A and PTR records' 'Discard A and PTR records when a lease is deleted'

Some PCs seem to work fine. They request a DHCP address, and the DHCP server hands them one and updates DNS. If I check the security of the 'A' record created through the dynamic update, the record is owned by the account created for DNS dynamic update registration and populated in the DHCP server.

Some PCs on the other hand appear to register their own 'A' records directly with the DNS server. This results in an 'A' record owned by either 'system' or the PC's AD computer account. When this happens, the 'A' record becomes unwriteable by the DHCP server due to its security settings.

The only way I can think around this, is to give full control of the zone to the account used by the DHCP server to dynamically update the DHCP server. This would then allow it to delete/modify any 'A' record, even those it has not created.

A better way would be to figure out why PCs sometimes register 'A' records instead of the DHCP server.

I'd really appreciate some advice if anyone has come across this before.

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

I believe what you are wanting to do is simply tell all your DHCP clients to not register their own DNS records in AD. The dynamic update GPO controls this behaviour on a per-computer basis; when it is disabled, the per-connection "register this connection's address in DNS" option has no effect and dynamic registration does not occur, leaving the DHCP server to take care of it without interference. You should set this GPO only on computers which should be DHCP clients.

If you find it useful, here is a reference for GPOs which apply to the Windows DNS client.

You will find this specific GPO at computer scope, under administrative templates and network, in DNS settings. Set the dynamic update policy to disabled, wait for the GPO to be applied, and the behaviour should stop.

share|improve this answer
1  
Thanks for that - I'll give it a go, turn the PCs off, delete the 'A' records and boot them back up. I'll mark this as the answer if it works :-) –  leftcase Sep 4 '13 at 9:40
    
This solution is working so far. I also had to tick the DHCP server option to do Dynamic DNS updates even for clients that do not request them. Thank you for your help. :-) –  leftcase Sep 5 '13 at 10:35
    
Aah, good catch. Glad to hear it. –  Falcon Momot Sep 5 '13 at 12:43
add comment

Something to be aware of with DNS records is they are not re-created every time. When a client unregisters, the record is marked as dnsTombstoned. The record still exists, but is not visible in DNS Manager. When the client renews, the previous DNS record is re-animated. If you find a problem record, you may want to determine if the symptom occurs when the DNS record object is removed using ADSIEDIT (and replicated if you have multiple DC's/DNS Servers), and the client renews and creates a new record, instead of re-animating the existing record. It's possible that the owner was just the existing owner on the tombstoned record.

In ADSIEDIT, you can open the Configuration Naming Context, select Partitions, and in the right pane, right-click on the DomainDNSZones partition and select New Connection To Naming Context, then drill-down to MicrosoftDNS to view the records for the zone.

share|improve this answer
    
Thanks, I'll give that a look too. –  leftcase Sep 5 '13 at 10:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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