Microsoft windows 2000 DNS manual Secure Dynamic Update Policy

In step 1, the client queries the local name server to discover which server is authoritative for the name it is attempting to update, and the local name server responds with the reference to the authoritative server.

In step 2, the client queries the authoritative server to verify that it is authoritative for the name it is attempting to update, and the server confirms it.

In step 3, the client attempts a non-secure update, and the server refuses the non- secure update. Had the server been configured for non-secure dynamic update for the appropriate zone rather than secure dynamic update, the server would have instead attempted to make the update.

In step 4, the client and server begin security context negotiation. They exchange one or more security tokens (depending on the underlying security provider) using the TKEY resource record as the vehicle to transfer security tokens between the client and the server. The TKEY resource record is specified in the Internet Draft “Secret Key Establishment for DNS (TKEY RR).”

First, the client and server negotiate an underlying security mechanism. Windows 2000 dynamic update clients and servers both propose Kerberos, so in this case, they would decide to use Kerberos. Next, using Kerberos, they verify each other’s identity.

Once the security context has been established, it will be used to create and verify transaction signatures on messages between the client and server.

In step 5, the client sends the signed dynamic update request to the server. As a vehicle to transfer the signatures, the client and server use the TSIG resource record, specified in the Internet Draft “Secret Key Transaction Signatures for DNS” (TSIG).

In step 6, the server attempts to make the update to Active Directory. Whether or not it can depends on whether the client has the proper permissions to make the update and whether the prerequisites have been satisfied.

In step 7, 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.

Secure Dynamic Update Policy

When a client attempts a dynamic update on the DNS server, it can be configured to use one of the following approaches:

•Attempt a non-secure dynamic update first, and if it fails, negotiate a secure dynamic update (default configuration)

•Always negotiate a secure dynamic update

•Attempt only a non-secure dynamic update

The default approach is recommended as it allows client to register with a DNS servers that are not capable of the secure dynamic update. The default setting,

Windows 2000 White Paper 20