In my Blog about
DHCP, DNS and the DNSUpdateProxy-Group I was stating that for security reasons you really don't need to use the DNSUpdateProxy-Groups for most scenarios. However Bob has asked a very good question, which is worth another entry in this Blog. Thanks for that Question.
Q: How does this solve the problem that the DNSUPDATEPROXY group was designed to fix, namely the prevention of stale records and the ability of upgrade clients (NT --> 2000) to refresh and update records created for them by the DHCP server?
A: The DnsUpdateProxy-Group was originally designed for two reasons:
- Allow redundancy: Using a DHCP-Cluster or DHCP-Servers which are configured for the same scope you they need to be able to update the records assigned from the other node. I stated in my previous post that there's no reason for the DnsUpdateProxy-Group in that scenario - you can configure a service-account to use by both nodes which will do the update.
- Allow to update records previously created from a DHCP-Server from Clients in a migration scenario. That's what you are referring too. Lets discuss this a bit more.
If a DHCP-Server is member of the DnsUpdateProxy-Group he is creating DNS-Records which are allowed to be updated by authenticated users, so they are not secure.
By default the DHCP-Server will create and update the Forward-Lookup-Entry (A-Record which resolves the Name to the IP) for downlevel-clients which are not able to update those records themselves. He will also update the Reverse-Lookup-Entry (PTR-Record which resolved the IP-Adress to the Full-Qualified Name) for all Clients (He will always be the owner of the IP, whether the Client will be the owner of the Name).
In a migration scenario NT4 and lower clients won't create their DNS-Entries, so the DHCP-Server will take care of it (if he's configured to do so). If the DHCP-Server is member of the DnsUpdateProxy-Group there's a big advantage: as soon as you upgrade the client to Windows 2000 or Windows XP the client will be able to update it's own record, since the DHCP-Server didn't secure it.
It is valid if you want to have the DHCP-Server in the DnsUpdateProxy-Group during the client-migration period (but please don't run it on a DC in that case - we really don't want DCs doing the domain critical updates unsecured), however there are other possibilities as well:
- Do you really need the old clients in DNS? Usually you want to be able to resolve them and you have a running WINS-Infrastructure anyways. So configure the DHCP-Server not to perform updates for downlevel-clients, and configure the DNS-Server to ask the WINS-Server for records he doesn't know. After the migration of the client he's able to create his record since there's no DNS-Record for him yet.
- If you perform the migration of the clients in a short period: You'd be able to delete the client records before the migration, or even every evening when the users are gone. The clients will recreate their records anyways the next day when booting up anyways (for small to medium businesses/domains).
- If you know when you'll migrate which client, you'll also be able to delete just those records.
- You are able to anonymize the client records.
Gosh - this blog-entry is long - sorry for those who pull it as RSS, however I haven't found a possibility to blog offline with providing an excerpt for RSS.
Back to the topic - here are some commands which may help you:
To use WINS-Forward-Lookup:
In the DNS Management Console select the zone, then select the Properties of the Zone, go to the WINS-Tab and select the WINS-Server(s) to ask if the record is not in the zone.
To make sure the DHCP-Server does not create downlevel-entries:
In the DHCP Management Console check the properties of the server and the properties of the specific scopes that the checkbox "Dynamically update DNS A and PTR records for DHCP clients that do not request updates (for example, clients running Windows Nt 4.0)" is not checked.
To "anonymize" a DNS-Record (allow authenticated users to update it, and remove the ACL for the client computer account):
dsacls "DC=xpclient,DC=company.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=company,DC=com" /G "nt authority\authenticated users":CCRCWSWP /R company\xpclient$
You can also use dnscmd /RecordDelete to delete single or more dns-objects, or use a VB-Script which provides more functionality to query clients and delete or modify their DNS-Records.
Note: dsacls and dnscmd are out of the support tools which you'll find on the Windows Server 2003 CD in the directory [CD]:\support\tools.
I hope this helps - there are multiple possibilities for that scenario, but I think most important is not to run the DHCP-Server in the DnsUpdateProxy-Group for a very long time - interim for a migration of the clients would be OK if you are aware of the thread.