Secure Dynamic Update

You can configure any Active Directory–integrated zone for secure dynamic update, and then use the ACL to specify which users and groups have authority to modify the zone and records in the zone. The following sections describe the standards that comprise secure dynamic update, describe the secure dynamic update process, and explain how to configure secure dynamic update.

Note

Secure dynamic update is available only on Active Directory–integrated zones.

Configuring Secure Dynamic Update

When you create an Active Directory–integrated zone, it is configured by default to allow only secure dynamic updates. If you created the zone as a standard primary zone and then converted it to an Active Directory–integrated zone, it is configured for non-secure dynamic updates or for no dynamic updates, depending on how the primary zone was previously configured.

To configure secure dynamic update

1. In the DNS console, right-click the zone for which you want to configure dynamic update, and then click Properties .

2. In the Allow dynamic updates? box, select Only secure updates .

Controlling Update Access to Zones

With secure dynamic update, only the computers and users you specify in an ACL can create or modify dnsNode objects within the zone. By default, the ACL gives Create permission to all members of the Authenticated User group, the group of all authenticated computers and users in an Active Directory forest This means that any authenticated user or computer can create a new object in the zone. Also by default, the creator owns the new object and is given full control of it.

You can view and change the permissions for all DNS objects on the Security tab for the object, from within the Active Directory Users and Computers console or through the properties of zone and resource record in the DNS console.

To view the ACL for a dnsZone or dnsNode object

1. In the DNS console, right-click the zone or record you want to view, and then click Properties .

2. Click the Security tab.

Note

ACLs are assigned on a per-name basis. Therefore, if you had two different records for the same FQDN, they map to the same object in Active Directory and have the same ACLs. For example, the following records have the same ACLs:

host1.reskit.com    A       172.16.15.9

host1.reskit.com    MX    mailer.reskit.com

Reserving Names

You can reserve FQDNs so that only certain users can use them. To do so, create the FQDN in the DNS console, then modify its ACL so that only particular computer, user, or users can change the set of records associated with the FQDN.

DNS Standards for Secure Dynamic Update

Windows 2000 supports secure dynamic updates through the Generic Security Service Application Program Interface (GSS-API, specified in RFC 2078) rather than Domain Name System Security Extensions (RFC 2535) or Secure Domain Name System Dynamic Update (RFC 2137). The GSS-API provides security services independently of the underlying security mechanism.

The GSS-API specifies a way to establish a security context by passing security tokens. The client generates the initial token and sends it to the server. The server processes the token and, if it is necessary, returns a subsequent token to the client. The process repeats until negotiation is complete and a security context has been established. After the security context has been established, it has a finite lifetime during which it can be used to create and verify the transaction signature on messages between the two parties.

Windows 2000 implements the GSS-API using an algorithm specified in the IETF Internet-Draft "GSS Algorithm for TSIG (GSS-TSIG)." This algorithm uses Kerberos v5 authentication protocol as its underlying security mechanism. Other security providers such as smart cards or certificates have not been tested. The algorithm uses the following resource records to provide security services:

TKEY . A resource record specified in the IETF Internet-Draft "Secret Key Establishment for DNS (TKEY RR)," as the vehicle to transfer security tokens between the client and the server and to establish secret keys to use with the TSIG resource record.

TSIG . A resource record specified in the IETF Internet-Draft "Secret Key Transaction Signatures for DNS (TSIG)," to send and verify signature-protected messages.

To see the TKEY and TSIG records being passed across the network, you can use Network Monitor. Versions 6.12 and later decode the resource records.

TKEY Resource Record

Table 6.7 describes the structure of the TKEY resource record, as described in the IETF Internet-Draft "Secret Key Establishment for DNS (TKEY RR)."

Table   6.7 TKEY Resource Record

Field	Data Type	Comment
NAME	domain name	Differs with mode and context
TTYPE	u_int16_t	TKEY
CLASS	u_int16_t	Ignored; should be zero
TTL	u_int32_t	Should be zero
RDLEN	u_int16_t	Length of RDATA field
RDATA
Algorithm	domain name	Determines how the secret keying material exchanged by using the TKEY resource record is used to derive the algorithm-specific key
Inception	u_int	In number of seconds since January 1, 1970 GMT
Expiration	u_int32_t	In number of seconds since January 1, 1970 GMT
Mode	u_int16_t	Scheme for key agreement
Error	u_int16_t	Error code
Key size	u_int16_t	Size of Key data field in octets
Key data	octet stream	Differs with mode
Other size	u_int16_t	Not used
Other data	octet stream	Not used

TSIG Resource Record

Table 6.8 describes the structure of the TSIG resource record, as described in the IETF Internet-Draft "Secret Key Transaction Signatures for DNS (TSIG)," to send and verify signature-protected messages.

Table   6.8 Structure of TSIG Resource Record

Field	Data Type	Comment
Algorithm name	domain name	Name of the algorithm, expressed as a domain name
Time signed	u_int48_t	Seconds since 1-Jan-70 UTC
Fudge	u_int16_t	Seconds of error permitted in Time signed field
Signature size	u_int16_t	Number of octets in Signature field
Signature	octet stream	Defined by Algorithm name field
Error	u_int16_t	Expanded RCODE covering signature processing
Other len	u_int16_t	Length, in octets, of Other data field
Other data	octet stream	Undefined

Secure Dynamic Update Process

To initiate a secure dynamic update, the client first initiates the TKEY negotiation process, to determine the underlying security mechanism and to exchange keys. Next, the client sends the dynamic update request containing resource records to add, delete, or modify to the server, signed with the TSIG resource record, and the server sends an acknowledgment. Finally, the server attempts to update Active Directory on behalf of the client.

Figure 6.21 shows the dynamic update process that takes place between a Windows 2000–based client and server, if both are configured with the default settings.

Figure 6.21 Secure Dynamic Update Process

In step 1, the client queries the local name server to determine which server is authoritative for the name it is attempting to update (using the process described in "DNS Queries," found earlier in this chapter). The local name server responds with the name of the zone and the primary server that is authoritative for the zone.

In step 2, the client attempts a non-secure update, and the server refuses the non-secure update. Had the zone been configured for non-secure dynamic update rather than secure dynamic update, the server would have instead attempted to add, delete, or modify resource records in Active Directory.

In step 3, the client and server begin TKEY negotiation. First, the client and server negotiate an underlying security mechanism. Windows 2000 dynamic update clients and servers both propose the Kerberos protocol, so they decide to use it. Next, by using the security mechanism, they verify one another's identity and establish security context.

In step 4, the client sends the dynamic update request to the server, signed with the TSIG key that was generated by using the security context established in step 3. The DNS server verifies the origin of the dynamic update packet by using the security context and the TSIG key.

In step 5, the server attempts to add, delete, or modify resource records in Active Directory. Whether or not it can make the update depends on whether the client has the proper permissions to make the update and whether the prerequisites have been satisfied.

In step 6, the server sends a reply to the client stating whether or not it was able to make the update, signed with the TSIG key. If the client receives a spoofed reply, it throws it away and waits for a signed response.

Security for DHCP Clients That Do Not Support the FQDN Option

DHCP clients that do not support the FQDN option are not capable of dynamic updates. Therefore, if you want their A and PTR resource records dynamically registered in DNS, you must configure the DHCP server to perform dynamic updates on their behalf.

However, you do not want the DHCP server to perform secure dynamic updates on behalf of DHCP clients that do not support the FQDN option. If a DHCP server performs a secure dynamic update on a name, the DHCP server becomes the owner of that name, and only that DHCP server can update the name. This can cause problems in a few different circumstances. For example, suppose that the DHCP server DHCP1 created an object for the name nt4host1.reskit.com and then stopped responding, and that the backup DHCP server, DHCP2, tried to update the name; DHCP2 is not able to update the name because it does not own the name. In another example, suppose DHCP1 added an object for the name nt4host1.reskit.com, and then the administrator upgraded nt4host1.reskit.com to a Windows 2000–based computer. Because the Windows 2000–based computer did not own the name, it would not be able to update its own name.

Therefore, if you have enabled secure dynamic update, you might want to perform a special configuration for any DHCP server that will perform dynamic updates. Place the server in a special security group called DNSUpdateProxy. Objects created by members of the DNSUpdateProxy group have no security; therefore, any authenticated user can take ownership of the objects.

To add a DHCP Server to the DNSUpdateProxy group

1. Click Start , point to Programs , point to Administrative Tools , and then click Active Directory Users and Computers .

2. In the console tree, double-click the domain node.

3. Double-click the Users folder.

4. In the details pane, right-click the group and click Properties .

5. Click the Members tab, then click Add .

6. Click Look in to display a list of domains from which users and computers can be added to the group and click the domain containing the server you want to add.

7. Click the server to be added and then click Add .

Caution

If you have installed the DHCP service on a domain controller, be absolutely certain not to make that server a member of the DNS Update Proxy group. Doing so would give any user or computer full control of the DNS records corresponding to the domain controllers, unless you manually modified the corresponding ACL. Moreover, if a DHCP server that is running on a domain controller is configured to perform dynamic updates on behalf of its clients, that DHCP server is able to take ownership of any record, even in the zones that are configured to allow only secure dynamic update. This is because a DHCP server runs under the computer account, so if it is installed on a domain controller it has full control over DNS objects stored in the Active Directory.

Windows 2000 DHCP clients register their own A resource records; therefore, putting a DHCP server in the DNSUpdateProxy group does not affect the security of the A resource records for Windows 2000 DHCP clients.

Note

The A resource record corresponding to the DHCP server has no security if the server is placed in the DNSUpdateProxy group. However, you can manually modify the ACL through the DNS console.

For more information about interaction between DNS and DHCP, see the Windows 2000 Server Help.