DNS on Windows 2000: Chapter 11: New DNS Features in Windows 2000


	DNS on Windows 2000 By Matt Larson & Cricket Liu 2nd Edition September 2001 0-596-00230-0, Order Number: 2300 349 pages, $39.95

Chapter 11
New DNS Features in Windows 2000
In this chapter:
Active Directory
Dynamic Update
Aging and Scavenging
Incremental Zone Transfer
Unicode Character Support
The Hatter opened his eyes very wide on hearing
this; but all he said was, "Why is a raven
like a writing desk?"
"Come, we shall have some fun now!" thought Alice.
"I'm glad they've begun asking riddles--I believe
I can guess that," she added aloud.
"Do you mean that you think you can find out
the answer to it?" said the March Hare.

Windows 2000 includes many new DNS bells and whistles. The DNS server itself is much improved, with more features than ever that make it more functional and easier to manage. From a client perspective, Windows 2000 as an operating system is more dependent on DNS than any previous operating system from Microsoft. And then there's Active Directory....

Active Directory

Active Directory is the major new feature of Windows 2000. It's a hierarchical database of information about all objects in the network: computers, printers, users, and so on. Both users and computers access the information in Active Directory. The Active Directory database is partitioned into domains for administrative purposes, and one or more domain controllers store information about particular domains. (Compare this to DNS's namespace, which is partitioned into zones, with one or more name servers authoritative for each zone.) The most important fact about Active Directory for our purposes is that it is integrated tightly with DNS. For more--much more--information about Active Directory, see Windows 2000 Active Directory by Alistair G. Lowe-Norris (O'Reilly).

Active Directory Domain Names

The most obvious connection between Active Directory and DNS is the naming of domains--Active Directory domains, that is. In the past, under Windows NT, domain names followed the NetBIOS host-naming rules: names consisted of a single label (i.e., no dots) and could contain letters, digits, and limited punctuation. Most Windows dialog boxes forced domain-name input to uppercase, so while they were case-insensitive, you usually saw domain names written in all uppercase. For example, Movie University's Windows NT domain name was MOVIEU.

With Windows 2000, all Active Directory domain names are DNS domain names, but--and this is important--not every DNS domain name is an Active Directory domain name.[1] So while an organization's Active Directory namespace resembles its DNS namespace, the two don't have to be and probably won't be identical. While it's beyond the scope of this book to give an exhaustive explanation of Active Directory namespace design, we can give you some examples to clarify the connection between the naming of Active Directory domains and DNS domains.

Consider Movie University. After reading this far, you're familiar with Movie U.'s DNS namespace: the apex (or top) of the namespace is movie.edu, and there are subdomains named fx.movie.edu, classics.movie.edu, and comedies.movie.edu. This namespace is represented in Figure 11-1.

Now let's talk about Movie U.'s Active Directory namespace. An organization's Active Directory domain names correspond to some of its DNS domain names, and the Active Directory domain at the top of an organization's domain tree usually corresponds to a subdomain of the apex of its DNS namespace. In Movie U.'s case, however, the root of the Active Directory domain tree is the same as the apex of the DNS namespace, movie.edu. Figure 11-1 shows Movie U.'s Active Directory domain tree beside its DNS namespace. Note how the two diverge, though. For various administrative reasons, the folks over in fx.movie.edu need to run their own Active Directory domain. But everyone else at Movie U. is a part of the movie.edu Active Directory domain, even though individual hosts fall into different DNS domains.

Figure 11-1. Movie University's namespace

DNS as Location Broker

You may be wondering why Active Directory domain names are DNS domain names. The answer is that Windows 2000 systems (running in native mode) use DNS as a location broker; that is, to find services. Previous versions of Windows used NetBIOS to find domain controllers, but Windows 2000 hosts use DNS. Take the case of a Windows 2000 Professional host at Movie U. that's been joined to the movie.edu Active Directory domain. When this system boots up, it sends a series of DNS queries to its configured name server to find a domain controller for the movie.edu domain.

The SRV resource record

The particular query sent by the Windows 2000 client is for a resource record type you may not have heard of: the SRV (service location) record. The SRV record, introduced in RFC 2782, is a general mechanism for locating services. Before we can talk in detail about exactly how a Windows 2000 client finds its domain controller using SRV records, we need to describe the SRV record itself.

Locating a service or a particular type of server within a zone is a difficult problem if you don't know which host it runs on. Some zone administrators have attempted to solve this problem by using service-specific aliases in their zones. For example, at Movie U. we created the alias ftp.movie.edu and pointed it to the domain name of the host that runs our FTP archive:
ftp.movie.edu.    IN    CNAME    plan9.fx.movie.edu.
This makes it easy for people to guess a domain name that will get them to our FTP archive and separates the domain name people use to access the archive from the domain name of the host on which it runs. If we were to move the archive to a different host, we could simply change the CNAME record.

Another option, for clients that understand it, is the SRV record. In addition to simply allowing a client to locate the host on which a particular service runs, SRV provides powerful features that allow zone administrators to distribute load and provide backup services, similar to what the MX record provides.

A unique aspect of the SRV record is the format of the domain name to which it's attached. Like the service-specific aliases described earlier, the domain name an SRV record is attached to gives the name of the service sought, but it also includes the protocol it runs over, concatenated with a domain name. The labels representing the service name and the protocol begin with an underscore to distinguish them from labels in the domain name of a host. So, for example:
_ftp._tcp.movie.edu
represents the SRV records someone ftping to movie.edu should retrieve in order to find the movie.edu FTP servers, while:
_http._tcp.www.movie.edu
represents the SRV records someone accessing the URL http://www.movie.edu should look up in order to find the www.movie.edu web servers.

The names of the service and protocol must come from the latest Assigned Numbers RFC (the most recent as of this writing is RFC 1700) or be unique names used only locally. Don't use the port or protocol numbers, just the names. When entering SRV records with the DNS console, the service name is limited to eight common services.

The SRV record has four resource record-specific fields: priority, weight, port, and target. Priority, weight, and port are unsigned 16-bit numbers (between 0 and 65535). Target is a domain name.

Priority works similarly to the preference in an MX record: the lower the number in the priority field, the more desirable the associated target. When searching for the hosts offering a given service, clients should try targets with the same priority value before trying those with a higher value in the priority field (lower priority values indicate higher priority--confusing, eh?).

Weight allows zone administrators to distribute load to multiple targets. Clients should query targets at the same priority in proportion to their weight. For example, if one target has a priority of zero and a weight of one and another target has a priority of zero but a weight of two, the second target should receive twice as much load (in queries, connections, etc.) as the first. It's up to the service's clients to direct that load: they typically use a system call to choose a random number. If the number is, say, in the top one-third of the range, they try the first target, and if the number is in the bottom two-thirds of the range, they try the second target.

Port specifies the port on which the service being sought is running. This allows zone administrators to run servers on nonstandard ports. For example, an administrator can use SRV records to point web browsers at a web server running on port 8000 instead of the standard HTTP port (80).

Finally, target specifies the domain name of a host on which the service is running (on the port specified in the port field). Target must be the canonical name of the host (not an alias), with address records attached to it.

So, for the movie.edu FTP server, we might add two SRV records to the movie.edu zone. Adding the first with the DNS console is shown in Figure 11-2.

Figure 11-2. Adding an SRV record with the DNS console

After adding the second record, the movie.edu zone data file (movie.edu.dns) contains these records:
_ftp._tcp.movie.edu.  IN  SRV  1  0  21  plan9.fx.movie.edu.
                      IN  SRV  2  0  21  thing.fx.movie.edu.
This instructs SRV-capable FTP clients to try the FTP server on plan9.fx.movie.edu's port 21 first when accessing movie.edu's FTP service and then to try the FTP server on thing.fx.movie.edu's port 21 if plan9.fx.movie.edu's FTP server isn't available.

The records:
_http._tcp.www.movie.edu.  IN  SRV  0  2  80   www.movie.edu.
                           IN  SRV  0  1  80   www2.movie.edu.
                           IN  SRV  1  1  8000 postmanrings2x.movie.edu.
direct web queries for www.movie.edu (the web site) to port 80 on www.movie.edu (the host) and www2.movie.edu, with www.movie.edu getting twice the queries www2.movie.edu does. If neither is available, queries go to postmanrings2x.movie.edu on port 8000.

But don't get excited and add SRV records for your FTP and web servers: few clients actually use SRV records to locate their servers. In fact, we're not aware of any FTP clients or web browsers that look up SRV records. On the other hand, when Microsoft was looking for a way to have Windows 2000 clients find their domain controllers, SRV records fit the bill perfectly.

DNS resource records needed by a domain controller

A Windows 2000 client needs to reach several services on its domain controller. Clients communicate with Active Directory itself using the Lightweight Directory Access Protocol (LDAP).[2] Authentication and authorization are handled by Kerberos.[3] A domain controller needs DNS to "advertise" the availability of these services. The resource records needed by the movie.edu Active Directory domain look like this:
movie.edu. 600 IN A 192.249.249.3
_ldap._tcp.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.pdc._msdcs.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.6e10690c-40a2-4383-98a7-c716ef9266d1.domains._msdcs.movie.edu. 
    600 IN SRV 0 100 389 terminator.movie.edu.
260aad2b-3ce7-41c2-923e-8e7bec165788._msdcs.movie.edu. 600 IN CNAME 
    terminator.movie.edu.
_kerberos._tcp.dc._msdcs.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu.
_ldap._tcp.dc._msdcs.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_kerberos._tcp.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu.
_kerberos._udp.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu.
_kpasswd._tcp.movie.edu. 600 IN SRV 0 100 464 terminator.movie.edu.
_kpasswd._udp.movie.edu. 600 IN SRV 0 100 464 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 389 
    terminator.movie.edu.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.movie.edu. 
    600 IN SRV 0 100 88 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.movie.edu. 
    600 IN SRV 0 100 389 terminator.movie.edu.
_kerberos._tcp.Default-First-Site-Name._sites.movie.edu. 
    600 IN SRV 0 100 88 terminator.movie.edu.
_ldap._tcp.gc._msdcs.movie.edu. 600 IN SRV 0 100 3268 terminator.movie.edu.
gc._msdcs.movie.edu. 600 IN A 192.249.249.3
_gc._tcp.movie.edu. 600 IN SRV 0 100 3268 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.movie.edu. 
    600 IN SRV 0 100 3268 terminator.movie.edu.
_gc._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 3268 
    terminator.movie.edu.
The movie.edu domain has one domain controller, terminator.movie.edu. You can see that the target of every SRV record (that is, the host providing the service) is terminator. Notice the various services provided by terminator: LDAP over TCP, Kerberos over TCP and UDP, etc. For an explanation of the function of each of the records needed by a domain controller, see Microsoft Knowledge Base article Q178169.

Also notice two A records hiding among all those SRV records:
movie.edu. 600 IN A 192.249.249.3
gc._msdcs.movie.edu. 600 IN A 192.249.249.3
The first A record is for LDAP clients that don't understand SRV records. Since Windows 2000 clients do use SRV records to locate the LDAP service on the domain controller, you don't need that domain A record (the one for movie.edu) unless you're using other LDAP clients. (And even then, you can just point those clients at the domain controller using its fully qualified name: terminator.movie.edu, in this case.) It's good that the A record isn't required, because a lot of folks already have an A record at the apex of their DNS namespace. This record usually points to a web server, not to an Active Directory server. For example, Movie U.'s main web server is accessible via both www.movie.edu and movie.edu. However, note that the second A record, which points to the Global Catalog service on the domain controller, is required.

This discussion begs the question: how do those SRV records get there? Are you dreading that you'll have to type them in yourself? Never fear--the domain controller adds these records to DNS itself, using a recent DNS protocol enhancement called dynamic update. We'll discuss dynamic update soon, along with more details about how domain controllers update DNS with the records they require.

One final note: if we had multiple domain controllers for movie.edu, there would be an additional set of records for each one.

Storing Zones in Active Directory

Zone storage is another Active Directory-DNS integration point. With the previous version of the Microsoft DNS Server in NT Server 4.0 (or a standard BIND name server, for that matter), a name server loads zones from two places. If the name server is a primary master for a zone, it loads that zone from a file on disk. If the name server is a secondary master (or a slave, to use the newer term used by recent DNS-related RFCs), it loads the zone from another authoritative server (usually the primary master) over the network, using a zone transfer. The purpose of this traditional primary/secondary relationship is to facilitate replication. A zone needs multiple authoritative servers for redundancy and to spread the query load. The zone transfer is DNS's built-in replication mechanism: as you know, just change the zone on the primary, and the change eventually percolates to the secondaries.

The Microsoft DNS Server gives you a third option, called Active Directory integration. Rather than being stored in a file on the primary master's disk, the zone data is stored in the Active Directory database. This option is available only when the DNS server is running on a domain controller. The reasoning is that since Active Directory already has its own replication topology--a "multimaster" scheme in which each domain controller can accept changes and propagate them to the other domain controllers--why not just take advantage of Active Directory's replication for DNS zones, rather than designing a separate primary/secondary topology?

There are at least a couple of reasons why you'd want to opt for Active Directory integration for your zones. While it does save you from designing and implementing primary/secondary relationships for all your name servers and zones, the main reason is secure dynamic update. Microsoft has extended the standard DNS dynamic update protocol, allowing it to work with the Active Directory security model, but this feature is available only with Active Directory-integrated zones. Secure dynamic update alone is enough reason to store zone information in Active Directory.

One other note about Active Directory-integrated zones: strictly speaking, you don't have to make every name server for a zone Active Directory integrated. Since all authoritative servers allow zone transfers, a server that loads a zone from Active Directory will happily respond to zone transfers. So you can conceivably make only a zone's primary master name server Active Directory integrated and have the secondaries continue to load from the primary. However, it defeats one of the purposes of Active Directory integration--letting Active Directory handle zone replication--to use traditional zone transfers. The other huge advantage of Active Directory integration is secure dynamic update, which isn't possible if only the primary master is Active Directory integrated. So to take full advantage of Active Directory integration, all name servers for a zone should store the zone in Active Directory.

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 nonhumans--i.e., programs--to 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 message--including dynamic updates--sent 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 amount--such as changing just one bit--produces 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]

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:

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.

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.

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]

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.

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]

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:

Choose Settings Network and Dial-up Connections

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

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

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

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

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

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.

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

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 192.253.254.13. The dynamic update contains no update section; it's just a probe to see what's out there.

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 192.253.254.13. If mummy.fx.movie.edu already has an A record, the client sends an update to delete that A record and add its own.

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

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

Send a dynamic update to bladerunner.fx.movie.edu with the prerequisite that 13.254.253.192.in-addr.arpa not be an alias. If the prerequisite is satisfied, the update adds a PTR record mapping 192.253.254.13 back to mummy.fx.movie.edu. If 13.254.253.192.in-addr.arpa 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.

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 updates--that is, when the Automatically update DHCP client information in DNS box is checked--the 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 option--in 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.

Aging and Scavenging

Zones with dynamic update enabled are prone to stale records; that is, A or PTR records that are dynamically added but not properly removed when no longer necessary. Most DHCP clients--including Windows clients--don't release their addresses on shutdown, which means they don't send the corresponding dynamic update message to remove their A records (nor does the DHCP server send a dynamic update message to remove the PTR record). Imagine a transient host, such as a laptop, that receives but never releases an address, leaving A and PTR records in DNS. Microsoft refers to these records as stale, and the DNS server in Windows 2000 can track their age and remove, or scavenge, them when they are no longer necessary.

The DNS server knows a record is not stale when it receives a dynamic update request for it. A Windows 2000 host sends a dynamic update message for its A record (and PTR record, if configured with a static address) every 24 hours by default. Windows 2000 hosts also send dynamic updates on lease renewal. An update of an existing record is called a refresh. (Before sending the update to make any changes, clients actually probe for a record's existence by sending a dynamic update message with only a prerequisite section. The DNS server counts such a message as a refresh, too.) A refresh is the signal to the server that a particular client is still alive and using its records.

The idea behind aging and scavenging is to remove records that haven't been refreshed within a certain interval. The primary master server stores a timestamp for each resource record in zones with aging and scavenging enabled. Every time a record is created, modified, or refreshed, the server updates the timestamp with the current time. If the primary master is Active Directory integrated, it replicates these timestamps to the other servers (since all primary masters may need to perform aging and scavenging). A large number of dynamic updates means a large number of refresh events and corresponding timestamp updates, which means a lot of replication traffic if the zone is Active Directory integrated.

To reduce the replication burden of this algorithm, Microsoft introduced the concept of a "no-refresh" interval. After a record is refreshed and its timestamp is updated, the server will not process additional refresh events (nor update the record's timestamp) for the length of the no-refresh interval. Note that each record has its own refresh or no-refresh timer ticking away. The record can still be changed, though, which does cause its timestamp to be updated. Remember, a refresh is just a dynamic update that doesn't cause any changes[10] because the records specified in the update are already present in the zone. The no-refresh interval is like a cooling-off period that cuts down on replication: since refresh events aren't recorded during this interval, a record's timestamp isn't updated and therefore doesn't have to be replicated.

The DNS server's default refresh and no-refresh interval are both seven days. Aging and scavenging is enabled on a zone-by-zone basis. At a configurable interval, the server makes a scavenging pass to remove any stale records in zones enabled for aging and scavenging. Stale records have a timestamp older than the current time minus the no-refresh interval minus the refresh interval. Figure 11-7 shows the phases of a record from creation through refreshing to scavenging. Since this record was never refreshed, it's eligible for scavenging. Figure 11-8 corresponds to another record from a live client that is sending periodic dynamic updates to keep its A record refreshed. This record won't be scavenged.

Figure 11-7. Nonrefreshed record

Figure 11-8. Periodically refreshed record

Configuring Aging and Scavenging

Aging and scavenging is disabled by default, since its improper use is dangerous. If you set the refresh and no-refresh intervals too low, records that aren't stale can be inadvertently removed. A global setting controls aging and scavenging for the entire DNS server. It's located on the Advanced tab of the server properties window, which is shown in Figure 11-9. The Scavenging period setting controls how often the server makes a scavenging pass through all authoritative zones.

Figure 11-9. Enabling aging and scavenging for an entire server

Once aging and scavenging has been enabled on a given server, you must still enable it for a particular zone. From the General tab of a zone's properties window, click the Aging button to produce a window like the one shown in Figure 11-10. Click Scavenge stale resource records to enable aging and scavenging for this zone. The refresh and no-refresh intervals are set on a per-zone basis.

Figure 11-10. Enabling aging and scavenging for a particular zone

In addition, a DNS server may be configured to apply the zone parameters values to all the existing and future zones.

When Scavenging Occurs

The server stores a parameter called StartScavenging for each primary zone, which is the time after which the zone is eligible for scavenging. A DNS server performs a zone-scavenging pass only if the current time is greater than StartScavenging. (In addition, scavenging must be enabled for the server and the zone, and dynamic update must be enabled for the zone.) The StartScavenging parameter is set to the current time plus the refresh interval of the zone when the following events happen:

When scavenging is enabled for the zone

When dynamic update is enabled for the zone

When the zone is loaded

When the zone is resumed

Other Notes on Aging and Scavenging

Static records (i.e., those added with the DNS console) are considered "permanent." They have a creation/refresh timestamp of zero and are ignored during a scavenging pass.

The DNS server needs to retain each record's creation/refresh timestamp across server restarts, which means writing this information to disk. For Active Directory-integrated zones, this information goes in--surprise!--Active Directory. For standard zones, the server has to store the information in the zone data file. Thus, for standard zones with aging and scavenging enabled, the zone data file format includes an extra field that is incompatible with non-Windows 2000 name servers. An outbound zone transfer of a zone with aging and scavenging enabled is not affected, so you can still have non-Windows 2000 name servers as secondaries. But if aging and scavenging is enabled for a zone, you can't take the actual zone file from a Windows 2000 name server and load it on, say, a BIND name server.

Incremental Zone Transfer

The Microsoft DNS Server in Windows 2000 supports a new kind of zone transfer. Incremental zone transfer, or IXFR for short, is specified in RFC 1995, and it does exactly what you'd expect based on its name. A traditional zone transfer always transfers the entire contents of a zone, even if only one record has changed. Incremental zone transfers allow a name server to send a list of just the records that have changed since the last zone transfer (whether it was a full or incremental one).

This new feature is critical for zones that change frequently. Imagine the scenario with dynamic update: every dynamic update is a change to the zone that requires a zone transfer. Doing a full zone transfer with every small change wastes bandwidth and CPU time. The situation is compounded when the zone being updated and transferred is large.

For IXFR to function, the master servers need to keep track of the differences between successive versions of the zone. A secondary requests an incremental zone transfer and presents its current serial number. The master server calculates and sends the changes needed on the secondary to make its version of the zone current. If the master server can't calculate the changes for whatever reason--perhaps the secondary has an old version of the zone and the primary hasn't kept a record of changes that far back--the primary is allowed to say "Sorry, but you've got to accept a full zone transfer."

A Microsoft DNS Server acting as a secondary requests an incremental zone transfer by default. If the master server doesn't support incremental zone transfer, the Microsoft DNS Server asks for a standard full zone transfer. A Microsoft DNS Server acting as a primary master stores a record of changes going back several versions. The number of versions the server keeps in memory depends on the zone's size: it keeps 25% of the total number of resource records of the zone, up to a total of 64,000. For example, given a zone of 100 resource records, the server would store changes corresponding to the last 25 versions of the zone. It responds with a full zone transfer instead of an incremental when it doesn't have the necessary information to produce the list of changes to the zone or when the list of changes would be larger than a full zone transfer.

Active Directory-integrated zones introduce an extra wrinkle. Any of these zones' authoritative servers can accept a dynamic update for the zone. The change is stored locally and replicated to the other servers using Active Directory. This situation means that different servers can potentially apply changes to the zone in a different order. To maintain a consistent view of changes to a zone, a secondary must always use the same master server. If a particular master server becomes unavailable and a secondary is forced to use another, it automatically requests a full zone transfer for the first transfer from that server to avoid inconsistencies.

Unicode Character Support

The Microsoft DNS Server allows any character from the Unicode character set to be used in a domain name. These characters are represented in UTF-8, a particular method of encoding Unicode characters.[11] The vast majority of DNS domain names are represented with a subset of the ASCII character set: alphanumeric characters (i.e., the uppercase and lowercase letters A-Z and the digits 0-9) and the hyphen. In fact, the DNS specification has always permitted any binary value to be used in domain names, though RFC 1035--one of the core RFCs that define DNS--recommends that domain names be limited to the characters just listed to avoid problems using the domain names with other protocols. For example, the Internet standards dealing with valid hostname syntax (RFCs 952 and 1123) restrict hostnames to the same ASCII alphanumeric subset. Since this hostname syntax is referenced in Internet standards for electronic mail, domain names used in email addresses must use this same limited syntax.

Until Windows 2000, however, networking in Microsoft operating systems was based on NetBIOS, which has more liberal hostname-syntax rules than strict alphanumerics and the hyphen. As we mentioned earlier in this chapter, limited punctuation is allowed in NetBIOS names, as well. Since DNS is the protocol used to name hosts in Windows 2000, sites that upgrade can run into trouble with hosts named according to NetBIOS syntax rules that are no longer valid according to the accepted DNS syntax rules. As a result, Microsoft extended the DNS server and the DNS console user interfaces to support a wider character set--everything in Unicode.

The Microsoft DNS Server can check the syntax of domain names in zones for which it is authoritative. This behavior, called name checking, is controlled on the Advanced tab of the server properties window (see Figure 11-9). The default value is to check according to UTF-8 syntax rules, but domain names can also be restricted to alphanumerics and the hyphen or name checking can be disabled completely.

A word of caution is in order here: just because the Microsoft DNS Server allows you to use all kinds of crazy characters in domain names, it doesn't mean you should. Many other protocols have certain expectations for syntax of domain names, and violating these expectations can cause applications to exhibit strange and unpredictable behavior. We recommend sticking to the accepted alphanumerics and the hyphen until standards for using additional characters are developed by the IETF (they're working on such standards at the time of this writing). If you absolutely must use other characters, do so only for hostnames used inside your organization, not those visible to the entire Internet.

1. And every square is a rectangle, but not all rectangles are squares. All registered mail is certified, but not all certified mail is registered. You get the idea.

2. LDAP is an Internet standard defined in RFC 2251.

3. Kerberos is also an Internet standard--see RFC 1510.

4. See RFC 2104.

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

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

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

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

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

10. Or the prerequisite check we described.

11. More information about the Unicode Standard is available at http://www.unicode.org.