11.2 Dynamic Update
11.2 Dynamic Update Dynamic update is a major new feature implemented in the Microsoft DNS Server. Like many other protocols used by Windows 2000, it's an Internet standard, defined in RFC 2136. Dynamic update is simply a protocol that allows a name server to be updated by sending it a message over the network. This is a big improvement over the traditional method, which requires a human to fire up the DNS console to make the change in person. Dynamic update allows nonhumansi.e., programsto easily update DNS information. No security is built into the dynamic update protocol. It's up to an individual name server to decide whether or not to accept an update message. About the only means of authentication a name server has is to look at the source IP address of the dynamic update message, and that's not a very strong means of authentication at all: it's easy to "spoof" or forge a packet's source IP address. And since a complete dynamic update message travels in a single UDP packet, all an attacker needs to know is an IP address that the name server accepting dynamic updates trusts. The Bad Guy just creates a dynamic update with a spoofed source IP address and sends it to the unsuspecting name server. This deficiency begs for some stronger security based on cryptography, which fortunately has been developed. The DNS standards community developed a protocol extension to use transaction signatures to sign any kind of DNS messageincluding dynamic updatessent between two parties: client to server, server to server, dynamic updater to server, etc. The transaction signatures, or TSIGs for short, in DNS use a technique called HMAC (Keyed-Hashing for Message Authentication), [4] which employs a shared secret and a one-way cryptographic hash function to sign data. A shared secret is like a password known only to the two parties. A one-way cryptographic hash function computes a fixed- size checksum based on any amount of input. What differentiates a cryptographic hash function, such as MD5 or SHA1, from a run-of-the-mill checksum, such as a CRC (Cyclic Redundancy Check), is that it's computationally infeasible to find two different input streams that produce the same hash output. With a CRC checksum, on the other hand, the algorithm is easily reversible: given any checksum, it's trivial to calculate an input stream to generate that checksum. Another property of a good cryptographic hash function is that varying the input by even a small amountsuch as changing just one bitproduces a major change in the hash output. In other words, the hash output is like a fingerprint of the original input.
A transaction signature is so-named because it's ephemeral: the signature applies only to a single transaction and is not reusable. Let's say a client wants to send a dynamic update signed with a TSIG to the appropriate name server. After generating the dynamic update message, it appends the secret it shares with the server to the message and runs everything through MD5. The output is the TSIG itself, which is placed into a TSIG resource record that goes in the dynamic update message. Since TSIGs are generated on the fly like this, you see a TSIG record only on a packet sniffer, never in the DNS console or a zone data file. Note that TSIG doesn't encrypt the data being sent: it only authenticates it. HMAC is illustrated in Figure 11-3. Figure 11-3. HMAC illustrated One difficulty with TSIG is distributing the shared secrets. Imagine having hundreds of clients that need to send TSIG-signed dynamic updates to a name server: that requires generating hundreds of keys and distributing them securely to each client. Microsoft found itself in just such a predicament. As we'll see shortly, individual Windows 2000 clients do send dynamic updates to name servers. TSIG is a requirement for these transactions to happen securely, but it's not feasible to statically configure shared secrets on each Windows 2000 client. The solution: Kerberos to the rescue! As we mentioned earlier, Windows 2000 uses Kerberos for authentication and authorization. Kerberos allows two parties who want to communicate securely to negotiate the necessary information to do so. Every Windows 2000 domain controller is a Kerberos Key Distribution Center, or KDC. Every Windows 2000 client and server is a Kerberos "principal." Every Kerberos principal shares a secret with the KDC. (This shared secret is generated when the host is joined to the domain.) The KDC acts as a trusted third party that allows two principals to communicate securely. For example, suppose a client named Alice wants to send an encrypted message to a client named Bob. Alice asks the KDC to help negotiate a session key [5] with Bob. Alice and Bob don't (yet) trust each other, but they do trust the KDC, which facilitates distributing the session key to both of them. This explanation is quite an oversimplification of how Kerberos actually works, but it does show the underlying concepts.
Microsoft extended TSIG in Windows 2000 to use Kerberos. A Windows 2000 client that wants to send a TSIG-signed dynamic update message to a name server doesn't have to be statically configured to share a secret with that server. The client uses Kerberos to obtain a session key, which serves as a one-time shared secret. This variant of TSIG is called GSS-TSIG and is documented in an Internet-Draft. [6]
11.2.1 Domain Controller BehaviorEarlier we showed the records required by domain controllers for clients to locate them. To ensure that these important records are always present, the Netlogon service running on the domain controller attempts to add them to DNS using dynamic update once per hour . A copy of these records can be found in the file %SystemRoot%\system32\config\netlogon.dns . It's worth describing exactly how the Netlogon service attempts to add these records. As an example, we'll show the steps followed by the movie.edu domain controller to register this SRV record (which happens to be the first one in the list of records we showed previously): _ldap._tcp.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu. The steps are:
These steps are repeated for every record: first the SOA query as a "probe" to discover which zone the record should reside in, then the A-record query, and then the dynamic update itself. Note the significance of the SOA query: this means that you don't have to have a zone corresponding to each Active Directory domain. For example, imagine Movie U. has another Active Directory domain named fx.movie.edu but no fx.movie.edu zone in the DNS namespace. Now consider the behavior when the fx.movie.edu domain controller attempts to register its first SRV record for _ ldap._tcp.fx.movie.edu . It sends an SOA query for this domain name but, since there's no fx.movie.edu zone, the negative response includes the SOA record for the movie.edu zone. As a result, the domain controller attempts to add the _ ldap._tcp.fx.movie.edu SRV record to the movie.edu zone. In fact, if there were no movie.edu zone, the domain controller would even try to update the edu zone! It doesn't attempt to send dynamic updates to the root zone, though, which is a good thing. Two Registry settings are used to control the Netlogon service's dynamic update behavior. [7]
First, to stop Netlogon from attempting to register the necessary records with dynamic update once an hour, create the following Registry key: UseDynamicDns HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Data type: REG_DWORD Range: 0 - 1 Default value: 1 Set the value to zero. The Netlogon service periodically checks this Registry key, so you don't need to restart the service or reboot the machine. You'll want to suppress repeated dynamic updates if you don't want to enable dynamic updates on your name server or if it doesn't allow dynamic updates. However, with Microsoft's secure dynamic update, there's really no reason not to enable dynamic updates. If you're running a BIND name server (which doesn't support Microsoft's particular version of secure dynamic update), however, you might want to disable dynamic update and instead add the necessary resource records to your zone by hand. In that case, it's pointless to have the domain controllers continuously attempting to send dynamic updates. [8]
Another useful Registry setting prevents Netlogon from registering A records with dynamic update: RegisterDnsARecords HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Data type: REG_DWORD Range: 0 - 1 Default value: 1 Set this key to zero to stop Netlogon from registering the two A records from movie.edu 's zone: movie.edu. 600 IN A 192.249.249.3 gc._msdcs.movie.edu. 600 IN A 192.249.249.3 Recall that the first one is not required, so setting this key to zero stops Netlogon from repeatedly registering an A record for your domain that might conflict with other records, such as those for your web server. On the other hand, the second record is required, so if you disable automatic A-record registration, you have to add the second record by hand. Remember that you can always check %SystemRoot%\system32\config\netlogon.dns for the exact list of records your domain controller expects to be present in DNS. 11.2.2 Windows 2000 Client BehaviorEvery Windows 2000 host uses dynamic update to maintain the proper DNS information about itself. The DHCP client service sends the updates, regardless of whether the host actually uses DHCP to obtain any IP addresses. If a Windows 2000 host does not use DHCP, it attempts to register name and address information for itself in DNS. Specifically, it sends dynamic updates to the appropriate authoritative name servers to add the appropriate A and PTR records. If the host does get an address from a DHCP server, it still registers the A record itself but allows the DHCP server to register the corresponding PTR record. [9]
This self-registration with dynamic update is feasible only with Microsoft's secure dynamic update. With Kerberos, the Windows 2000 host attempting the registration can authenticate itself to the DNS server. The DNS server can, in turn , implement a fine-grained authorization policy that allows a host to change only the A and PTR records corresponding to its own domain name and IP address. This feature extends a client's behavior dealing with its NetBIOS name to the DNS world. If a Windows (including Windows 2000) host is configured to use a WINS server, it registers its NetBIOS name and address with that server. Dynamic update behavior is controlled from the DNS tab of the Advanced TCP/IP Settings window for each network interface. Getting to this window takes a fair amount of clicking:
Figure 11-4. Advanced TCP/IP Settings Most of the settings on the Advanced TCP/IP Settings window deal with resolver configuration, which we discussed in Chapter 6. The dynamic update settings are at the bottom of the window. Register this connection's addresses in DNS is checked by default, and this setting controls whether or not the client attempts registration with dynamic update (whether it registers both A and PTR records or just an A record is determined by the DHCP settings, as we mentioned previously). By default, the host registers its fully qualified domain name. Windows 2000 calls the fully qualified domain name the full computer name . It's the concatenation of the host's single-label computer name and the primary DNS suffix which, by default, is set to the DNS name of the Active Directory domain to which the computer is joined. The full computer name is displayed on the Network Identification tab of the System Control Panel document, which is shown in Figure 11-5. To change the computer name, click Properties . Figure 11-5. Network Identification tab If you'd like the host to register an additional FQDN in addition to the primary FQDN (or full computer name), enter another domain name in the DNS suffix for this connection field and check Use this connection's DNS suffix in DNS registration . The additional FQDN is a concatenation of a single-label computer name and the connection-specific DNS suffix. If you don't specify the DNS suffix for this connection but check Use this connection's DNS suffix in DNS registration , the DNS suffix is specified by the DHCP server. In that case, the fully qualified domain name registered consists of the host's single-label computer name followed by the contents of the suffix field. So what gets added when a client registers? Let's reboot a Windows 2000 client in the special-effects lab and see. Our client is called mummy.fx.movie.edu . It has the fixed IP address 192.253.254.13 (it doesn't get its address from our DHCP server). The dynamic update routines on the client go through the following steps at boot time:
11.2.2.1 Registry settingsSeveral Registry settings affect a Windows 2000 host's dynamic DNS behavior:
A reboot is required to make any of these Registry changes effective. 11.2.3 DHCP Server BehaviorStill another Windows 2000 component that uses dynamic update is the Windows 2000 DHCP server. The dynamic update behavior is set on a per-scope basis. Every scope has a properties window, and dynamic update is configured using the settings on its DNS tab. Right-click on a scope in the DHCP console and select Properties to produce a window like the one shown in Figure 11-6. Figure 11-6. Scope properties, DNS tab Note that the DHCP server itself has a properties window (right-click on a particular server in the DHCP console and select Properties ) with an identical DNS tab, but the server settings provide defaults only for newly created scopes. The settings of a given scope control the server's dynamic update behavior for addresses given out from that scope. Figure 11-6 shows the default dynamic update settings for an unconfigured server. If you don't change them, every scope created has these dynamic update settings. The wording of the settings is a little confusing. The first one, Automatically update DHCP client information in DNS , applies only to DHCP clients that support the DHCP Fully Qualified Domain Name (FQDN) option, which has code number 81. This option has been defined only recently: at the time of this writing, the document describing it is an Internet-Draft and not yet an RFC. The FQDN option lets a DHCP client inform the DHCP server of its fully qualified domain name and also tell the server its intention about registering A and PTR records. This option can also be sent from server to client to let the server respond to the client's request and specify its intentions. In the Microsoft operating system family, only Windows 2000 DHCP clients support the FQDN option, and we've already mentioned how Windows 2000 DHCP clients use it: they specify their FQDN (computer name plus its primary DNS suffix) and inform the server of their intention to register their own A records. If Automatically update DHCP client information in DNS is selected, you must tell the server how to deal with a DHCP client's FQDN option request regarding dynamic update. The default setting is Update DNS only if DHCP client requests , which causes the server to honor the client's dynamic update requests. On the other hand, checking Always update DNS causes the server to always send dynamic updates for both A and PTR records, regardless of the client's request. The next setting, Discard forward ( name-to-address ) lookups when lease expires , applies to A records. When a Windows 2000 DHCP server is configured to send dynamic updatesthat is, when the Automatically update DHCP client information in DNS box is checkedthe server always sends a dynamic update to remove a client's PTR record when its lease expires. Checking this box causes the server to remove the client's A record with dynamic update, too. The final setting, Enable updates for DNS clients that do not support dynamic update , applies to any DHCP client that doesn't send the FQDN optionin other words, all versions of Windows before Windows 2000. If this box is checked, the DHCP server always updates A and PTR records for every lease issued to clients that don't pass the FQDN option. Since the client doesn't inform the server of its FQDN, the server has to calculate it by concatenating the values from two other DHCP options: Host Name (code 12) and DNS Domain Name (code 15). The DHCP server uses the value of the Host Name option sent by the client plus the value of the DNS Domain Name option defined in the scope from which the address is being leased. The server ignores any client-set value for the DNS Domain Name option. Another dynamic update- related feature of the Windows 2000 DHCP server is the DnsUpdateProxy built-in security group. This group solves a couple of problems. The first is when multiple DHCP servers perform secure dynamic update. The Microsoft DNS Server's access controls allow only the owner of a dynamically created record to change or delete it. Imagine a DHCP registering a PTR record on a client's behalf , then failing and being replaced by a backup DHCP server. If the original server became the owner of the record when creating it, the backup server would be unable to delete the record when the lease expired . The DnsUpdateProxy group solves this problem: when members of this group register records with dynamic update, they aren't marked as the owner. The first nonmember of DnsUpdateProxy to modify the records becomes the owner. To solve the DHCP server problem mentioned earlier, both computers should be members of the DnsUpdateProxy group. Another problem solved is when a DHCP server registers a PTR record on behalf of a "legacy" (i.e., non-Windows 2000) client that can't perform its own dynamic updates. If the client were later upgraded to Windows 2000, without this feature it wouldn't be able to update its own record. The "you touch it, you own it" properties of this group can cause problems, though. Since group ownership applies to the entire computer and not just the DHCP server, any records registered by the computer have this no-owner property. Recall that domain controllers register all kinds of important records. So if you run a DHCP server on a domain controller and you make that machine a member of DnsUpdateProxy, anyone can come along and take ownership of the (very important) records registered by the domain controller's Netlogon service. In addition, a DHCP server running on a domain controller uses local system privileges to modify the DNS records and therefore may update records registered by other computers in a secure zone. (This particular problem and its solution are described in Microsoft Knowledge Base article Q255134.) For these reasons, Microsoft recommends that you don't run a DHCP server on a domain controller. |
 | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 154