How Windows 2000 Secures DNS Dynamic Updates

Microsoft Windows 2000 manages DNS dynamic update security permissions by integrating the Domain Name System (DNS) service with Active Directory, utilizing Kerberos v5 authentication, and enforcing discretionary access control lists (DACLs) on DNS zone and record objects. This article explains the technical mechanisms Windows 2000 uses to authenticate clients, verify permissions, and safely modify resource records during secure dynamic updates.

Active Directory Integration Requirement

Secure dynamic updates are exclusively available for Active Directory-integrated zones. In standard primary zones, zone data is stored in flat text files that cannot enforce object-level security. When a zone is integrated into Active Directory, each DNS zone becomes an Active Directory container, and individual resource records become directory objects. This integration allows the DNS service to leverage Windows 2000's native security model, including Access Control Lists (ACLs).

Authentication via GSS-TSIG

Windows 2000 implements the Generic Security Service Algorithm for Secret Key Transaction Signatures (GSS-TSIG) specified in RFC 3645 to authenticate dynamic update requests:

  1. Initial Unsecured Attempt: The client attempts an unauthenticated dynamic update. If the zone is configured for "Secure updates only," the DNS server rejects the request with a REFUSED error.
  2. Security Context Negotiation: Upon receiving the rejection, the client initiates a negotiation with the DNS server using the TKEY (Transaction Key) resource record type.
  3. Kerberos Authentication: The client and server establish a security context using the Kerberos v5 authentication protocol. The client proves its identity (typically using its Active Directory computer account or user account).
  4. Signed Update: Once the security context is established, the client signs the dynamic update payload using a shared transaction key derived through GSS-TSIG and resubmits the request.

Permission Verification via Access Control Lists (ACLs)

After verifying the client's identity through Kerberos, the DNS service evaluates whether the caller has the necessary permissions to modify the targeted resource record:

  • Object-Level Permissions: Each resource record in an Active Directory-integrated zone contains a DACL. The DNS server evaluates the authenticated client’s token against this DACL to determine if it has Write or Modify access.
  • Default Ownership: When a computer account creates a new record (such as its own host A record), that account becomes the owner of the record by default. The owner is granted permission to update, modify, or delete the record in future transactions.
  • Pre-existing Records: If another entity owns the record, the update is rejected unless the client belongs to a group with administrative privileges (such as DnsAdmins, Domain Admins, or Enterprise Admins) that has been granted blanket modification rights on the zone or object.

The Role of DHCP in Secure Updates

For legacy clients that do not support GSS-TSIG dynamic updates (such as Windows 95 or Windows NT 4.0), a Windows 2000 DHCP server can be configured to register records on their behalf.

In this scenario:

  • The DHCP server authenticates to the DNS service using the DHCP service's computer account.
  • The DHCP server becomes the owner of the record.
  • To prevent conflicts between multiple DHCP servers, administrators can place DHCP servers into the DnsUpdateProxy built-in security group. Any record created by a member of this group is created without dedicated ownership, allowing other DHCP servers to update or overwrite the record when leases change.

Execution or Rejection

Once the DACL check succeeds, the DNS server writes the updated resource record directly to Active Directory, and the changes replicate across domain controllers through multi-master replication. If the authentication fails or the DACL denies the requested action, the DNS server drops the request and returns an access-denied error code back to the client.