11.2 Dynamic Update


DNS on Windows 2000, 2nd Edition
By Matt Larson, Cricket Liu
Table of Contents
Chapter 11.  New DNS Features in Windows 2000

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.

[4] See RFC 2104.

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.

[5] As the name implies, a session key is a short-lived key usually used for a single conversation.

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]

[6] GSS stands for Generic Security Service. At the time of this writing, GSS-TSIG was not yet an Internet standard but was on track to become one. Internet-Drafts may be found at ftp://ftp.ietf.org/internet-drafts/.

11.2.1 Domain Controller Behavior

Earlier 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:

  1. Look up the SOA record for _ ldap._tcp.movie.edu on the local name server. Though there isn't an SOA record for that domain name, the authority section of the NXDOMAIN (negative) response includes the SOA record of the zone that should contain the _ ldap._tcp.movie.edu SRV record, which in this case is movie.edu .

  2. Look up the address of the name server in the MNAME field of the SOA record, terminator.movie.edu (if necessary). Recall that the MNAME field of the SOA record lists the zone's primary master name server, which is where the dynamic update should be sent. Along with the SOA record, the Microsoft DNS Server returns the A record corresponding to the MNAME field in the additional section of the negative response. In that case, no extra A record lookup is needed.

  3. Send a dynamic update to terminator.movie.edu to add the SRV record for the domain name _ ldap._tcp.movie.edu .

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]

[7] See Microsoft Knowledge Base article Q246804 for more information about all aspects of Windows 2000 dynamic update behavior.

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]

[8] The fourth (and latest) edition of our sister book, DNS and BIND , discusses Windows 2000 and BIND name server coexistence in Chapter 16.

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 gc._msdcs.movie.edu. 600 IN A 

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 Behavior

Every 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]

[9] Actually, a host will register one A record for each IP address it has.

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:

  1. Choose Settings figs/u2192.gif Network and Dial-up Connections

  2. Double-click on a LAN interface to display its status window.

  3. Click Properties to display the properties window for the interface. Make sure the General tab is selected.

  4. Click on Internet Protocol (TCP/IP) , then click Properties to display the Internet Protocol (TCP/IP) Properties window.

  5. Click Advanced , which displays the Advanced TCP/IP Settings window.

  6. Select the DNS tab, and you'll see a window like the one shown in Figure 11-4.

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 (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:

  1. Look up the SOA record for mummy.fx.movie.edu on the local name server. Though there isn't an SOA record for that domain name, the authority section of the response includes the SOA record of the zone that contains mummy.fx.movie.edu , fx.movie.edu .

  2. Look up the address of the name server in the MNAME field of the SOA record, bladerunner.fx.movie.edu .

  3. Send a dynamic update to bladerunner.fx.movie.edu with two prerequisites: that mummy.fx.movie.edu not be an alias (i.e., that it not own a CNAME record) and that it not already have an address record pointing to The dynamic update contains no update section; it's just a probe to see what's out there.

  4. If mummy.fx.movie.edu already points to its address, stop. Otherwise, send another dynamic update to bladerunner.fx.movie.edu with the prerequisites that mummy.fx.movie.edu not be an alias and that it not have an A record already. If the prerequisites are satisfied, the update adds an A record pointing mummy.fx.movie.edu to If mummy.fx.movie.edu already has an A record, the client sends an update to delete that A record and add its own.

  5. Look up the SOA record for 254.253.192.in-addr.arpa .

  6. Look up the address of the name server in the MNAME field of the SOA record (though since the MNAME field contains bladerunner.fx.movie.edu , which we looked up recently, and Windows 2000 has a caching resolver, this shouldn't require another query).

  7. Send a dynamic update to bladerunner.fx.movie.edu with the prerequisite that not be an alias. If the prerequisite is satisfied, the update adds a PTR record mapping back to mummy.fx.movie.edu . If is an alias, stop. Registry settings

Several Registry settings affect a Windows 2000 host's dynamic DNS behavior:

Address conflict behavior

This is one Registry entry you should consider changing if you are aren't using a Windows 2000 Microsoft DNS Server and your name server is therefore forced to accept unsigned dynamic updates. By default, a Windows 2000 host unceremoniously deletes what it considers old A records for itself. For example, if the host we rebooted earlier discovered other A records for mummy.fx.movie.edu , it would delete them and then add a new one with its current IP address. The problem is, what if those were legitimate records? The host could be configured with the wrong name; maybe those A records are for the real mummy.fx.movie.edu . Setting this key to a value of one disables the overwriting behavior.

 DisableReplaceAddressesInConflicts HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters  Data type: REG_DWORD Range: 0 - 1 Default value: 0 Scope: Affects all adapters 
Reregistration interval

By default, the DHCP client service sends a dynamic update every 24 hours to register a host's A (and PTR, if applicable ) records. This behavior is an insurance policy against the records being lost from the zone. There's little reason to change this value.

 DefaultRegistrationRefreshInterval HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters  Data type: REG_DWORD Range: 0x0 - 0xFFFFFFFF seconds Default value: 0x15180 (86,400 seconds = 24 hours) Scope: Affects all adapters 
Default TTL

By default, dynamically added resource records have a time to live of 20 minutes. It makes sense to lower this value if you have a large number of hosts changing addresses frequently (such as laptops moving around) and you find DNS information is getting outdated . Recall, however, that this value doesn't affect the authoritative name servers for the zone containing the dynamically added records. Changes to authoritative servers take effect immediately and are propagated quickly, thanks to the NOTIFY protocol. The issue is records remaining in the cache of other name servers after the hosts move.

 DefaultRegistrationTTL HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Data type: REG_DWORD Range: 0x0 - 0xFFFFFFFF seconds Default value: 0x4B0 (1,200 seconds = 20 minutes)  Scope: Affects all adapters 
Maximum number of addresses to register

If a network adapter has multiple virtual addresses, by default only the first is registered using dynamic update. This value sets the maximum number of virtual addresses to register on a per-interface basis. Setting the value to zero disables dynamic updates for this interface.

 MaxNumberOfAddressesToRegister HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters\ interface-name  Data type: REG_DWORD Range: 0x0 - 0xFFFFFFFF Default value: 0x1 Scope: Affects this adapter only 
Update security level

By default, a Windows 2000 host first sends unsigned dynamic updates (i.e., it doesn't use Microsoft's security-enhanced method). If those updates fail, it attempts to negotiate a session key and sign the updates. The default value is 0x0. A value of 0x10 means send only nonsecure updates, and a value of 0x100 means send only secure updates. If you have only Windows 2000 name servers (or only non-Windows 2000 name servers), you can set this value accordingly to avoid sending unnecessary updates.

 UpdateSecurityLevel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters  Data type: REG_DWORD Range: 0x0  0x10  0x100 Default value: 0x0 Scope: Affects all adapters 

A reboot is required to make any of these Registry changes effective.

11.2.3 DHCP Server Behavior

Still 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.


DNS on Windows 2000
DNS on Windows 2000
ISBN: 0596002300
EAN: 2147483647
Year: 2001
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net