If you're using both DNS and DHCP on the same network, as many of us are, you should consider a couple of specific things that involve the interaction between these two components.
As mentioned often throughout this book, all applications and services run within a user context. This user context provides the access control list (ACL) that's used by the various access control mechanisms in Windows to determine whether access is granted or denied to an object. With the DHCP service, there is a specific concern about what account this service uses.
The DHCP server runs in the Local System security context. When the DHCP server is running on an Active Directory domain controller and contacts a DNS server for record registration, it contacts that DNS server in the domain controller's computer account context. This means that the connection has significantly elevated privileges. Such a connection could be used by an attacker who has compromised one server to "bounce" to another server in a highly privileged context.
To mitigate this threat, you should create a service account specifically for the DHCP service. You must configure your DHCP servers to start the DHCP service in that user context. This will avoid the privileged context problem and help ensure that an attacker has as little leverage as possible against your servers.
DHCP has a wonderful feature in Windows Server 2003. It can register A and PTR records on behalf of clients that lease addresses from it. The client doesn't have to do any work to make this happen. Client-side settings for this feature are configured through Group Policy, while the DHCP server settings are made in the configuration of the DHCP server itself.
This feature should be used whenever possible and is in fact the default when installing DNS and DHCP on domain controllers. Having the DHCP server update the DNS server allows the DHCP server to control and manage the DNS database for its hosts. This helps prevent attackers from manually modifying zone data. There is some configuration flexibility with this though.
To help provide some flexibility for down DHCP servers and possible record corruption, Windows Server 2003 provides a group called DnsUpdateProxy. If your DHCP servers are joined to the DnsUpdateProxy group, any authenticated user can take ownership of the records registered by DHCP server. This allows for situations in which one DHCP server has gone down and a record needs to be updated by a different server. It also provides some security because users must be authenticated before they can take ownership of a record, and this leaves an audit trail in case of attack or misconfiguration. On the other hand, members of DnsUpdateProxy by definition have elevated privileges on records they don't own. This can be considered a security vulnerability. In this case, you're trading compatibility for security, and you should consider this option carefully before implementing it.