Filter
Top Products
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