16.8 DNS and Windows 2000

Windows 2000 can use standard dynamic updates to register hosts in DNS. For a Windows 2000 client, registration means adding a name-to-address mapping and an address-to-name mapping for that client, information Windows clients formerly registered with WINS servers. For a Windows 2000 server, registration involves adding records to a zone to tell clients which services it's running and where (on which host and port). For example, a Windows 2000 Domain Controller uses dynamic update to add an SRV record telling Windows 2000 clients where the Windows 2000 domain's Kerberos service is running.

16.8.1 How Windows 2000 Uses Dynamic Update

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). At boot time, the dynamic update routines on the client go through the following steps:

If we'd been using the Microsoft DHCP Server from Windows 2000, the DHCP server, by default, would have added the PTR record. There's also an option in the DHCP server's MMC-based management interface that allows the administrator to specify that the DHCP server add both the PTR record and the A record. If the DHCP server had added the A record, though, it wouldn't have set a prerequisite.

Servers, particularly Windows 2000 Domain Controllers, register lots of information in DNS using dynamic update, both when they're first set up and periodically thereafter. (The netlogon service, for example, registers its SRV records hourly !) This allows clients to locate services on whichever host and port they're running. Since we just set up a Windows 2000 domain called fx.movie.edu, let's take a look at the records that our Domain Controller, matrix.fx.movie.edu, added:

$ORIGIN fx.movie.edu.
@                         600       A       192.253.254.14
_kerberos._tcp.dc._msdcs  600       SRV     0 100 88   matrix.fx.movie.edu.
_ldap._tcp.dc._msdcs      600       SRV     0 100 389  matrix.fx.movie.edu.
_ldap._tcp.e437709a-1862-11d3-8eda-00400536c213.domains._msdcs 600  SRV  0 100 389 matrix.fx.movie.edu.
e4377099-1862-11d3-8eda-00400536c213._msdcs  600  CNAME  matrix.fx.movie.edu.
gc._msdcs                 600       A       192.253.253.14
_ldap._tcp.gc._msdcs      600       SRV     0 100 3268 matrix.fx.movie.edu.
_ldap._tcp.pdc._msdcs     600       SRV     0 100 389  matrix.fx.movie.edu.
_gc._tcp                  600       SRV     0 100 3268 matrix.fx.movie.edu.
_kerberos._tcp            600       SRV     0 100 88   matrix.fx.movie.edu.
_kpasswd._tcp             600       SRV     0 100 464  matrix.fx.movie.edu.
_ldap._tcp                600       SRV     0 100 389  matrix.fx.movie.edu.
_kerberos._udp            600       SRV     0 100 88   matrix.fx.movie.edu.
_kpasswd._udp             600       SRV     0 100 464  matrix.fx.movie.edu.

Whoa! That's a lot of records!

These records tell Windows 2000 clients where the services offered by the Domain Controller, including Kerberos and LDAP, are running.^[3] You can see from the SRV records that they're all running on matrix.fx.movie.edu, our only Domain Controller. If we had another Domain Controller, you'd see nearly twice as many SRV records.

^[3] For an explanation of the function of each of these records, see Microsoft Knowledge Base article Q178169.

The owner names of all the SRV records end in fx.movie.edu, the name of the Windows 2000 domain. If we'd called our Windows 2000 domain effects.movie.edu, the dynamic update routines would have updated the zone containing the domain name effects.movie.edu, movie.edu. Of course, that would really clutter up movie.edu, since it has other delegated subdomains running Windows 2000. Consequently, we made sure we named our Windows 2000 domain after our zone.

16.8.2 Problems with Windows 2000 and BIND

While Microsoft's decision to replace WINS with DNS was noble, the implementation poses some problems for folks who run BIND name servers. First, Windows 2000 clients and DHCP servers have a nasty habit of deleting address records owned by the same domain name as the clients or servers. For example, if we let the users in the Special Effects Lab configure their own computers and choose their computers' names, and one user happened to use a name that was already taken, maybe by one of our rendering servers, his computer would try to delete the conflicting address record (that of the rendering server) and add its own. That's not very sociable.

Luckily, that behavior can be corrected on the client. The client does, in fact, check to see whether the domain name it's using already owns an address record by setting the prerequisite in step 4. (It just deletes it if it does exist, by default.) But you can follow the instructions in Microsoft Knowledge Base article Q246804 to tell the client not to delete conflicting records. The price? A client can't differentiate between an address being used by a different host with the same domain name and an address that formerly belonged to it, so if the client changes addresses, it can't automatically update the zone.

If you elect to have your DHCP server handle all registration, you don't have the option of leaving conflicting addresses alone. The DHCP server doesn't use prerequisites to detect collisions; it just unceremoniously deletes conflicting address records.

Given the limitations of having the DHCP server handle all of the registering, why would anyone consider it? Because if you allow any client to register itself and you can only use primitive, IP address-based access lists to authorize dynamic updates, you are allowing any client's address to dynamically update your zones. Savvier users of those clients could easily fire off a few custom-made dynamic updates to change your zone's MX records or the address of your web server.

16.8.3 Secure Dynamic Update

Surely Microsoft doesn't just live with these problems, right? No, not with the Microsoft DNS Server. The Microsoft DNS Server supports GSS-TSIG, a dialect of TSIG (which we covered in Chapter 11). A client that uses GSS-TSIG retrieves a TSIG key from a Kerberos server, then uses it to sign a dynamic update. The use of GSS, the Generic Security Service, to retrieve the key means that an administrator doesn't need to hardcode a key on each of his clients.

Since the name of the TSIG key the client uses to sign the update is just the domain name of the client, the name server can make sure that only the client that added an address can delete it later, simply by tracking the domain name of the TSIG key used to add a given record. Only an updater with the same TSIG key is allowed to delete that record.

Windows 2000 clients try GSS-TSIG-signed dynamic updates if their unsigned dynamic updates are refused. You can also configure them to send signed updates first by following the instructions in Knowledge Base article Q246804, mentioned earlier.

16.8.3.1 BIND and GSS-TSIG

Unfortunately, BIND name servers don't yet support GSS-TSIG, so you can't use Windows 2000's secure dynamic update with BIND. A forthcoming version of BIND 9, however, is scheduled to support GSS-TSIG. Once BIND does support GSS-TSIG, you'll be able to use all of the update policy rules described in Chapter 10 to control which keys can update which records. A simple set of rules that says:

zone "fx.movie.edu" {
	type master;
	file "db.fx.movie.edu";
	update-policy {
		grant *.fx.movie.edu. self *.fx.movie.edu. A;
		grant matrix.fx.movie.edu. self matrix.fx.movie.edu. ANY;
		grant matrix.fx.movie.edu. subdomain fx.movie.edu. SRV;
	};
};

may be enough to let Windows 2000 clients and servers register what they need in your zone.

16.8.4 What to Do?

In the meantime, how do you handle the proliferation of Windows 2000 on your network? Well, Microsoft would advise you to "upgrade" all of your name servers to the Windows 2000 version of the Microsoft DNS Server. But if you like BIND—and we do—you'd probably like some other options.

16.8.4.1 Handling Windows 2000 clients

The first (and probably most common) option for handling your Windows 2000 clients is to create a delegated subdomain for all of them to live in. We might call ours win.fx.movie.edu. Within win.fx.movie.edu, anything goes: clients can stomp on other clients' addresses and someone may send a bunch of hand-crafted dynamic updates to add bogus records to the zone. The intent is to create a sandbox (or jail, if you prefer) that the clients can't break out of and that they can trash if they want to. If you have kids, you have an intuitive understanding of this concept.

By default, a Windows 2000 client will try to register itself in a forward-mapping zone with the same name as its Windows 2000 domain. So we'll have to do some extra configuration to tell our clients to register in win.fx.movie.eduinstead of in fx.movie.edu. In particular, we'll have to go to a window that resides at My Computer->Properties->Network Identification->Properties->More, uncheck Change primary DNS suffix when domain membership changes, and type win.fx.movie.edu in the field labeled Primary DNS suffix of this computer. On all our clients.

Another possibility is to leave your clients in your main production zone (for our lab, that's fx.movie.edu) but to allow dynamic updates only from the address of the DHCP server. Then you configure your DHCP server to assume responsibility for maintaining both A records and PTR records. (You can add A and PTR records for hosts that don't use DHCP manually.)

In this scenario, it's more difficult for the little imps to send their custom dynamic updates to your name server, since it involves spoofing the address of the DHCP server. It's still possible that someone will bring up a client with a domain name that conflicts with an existing domain name in the zone, though.

16.8.4.2 Handling Windows 2000 servers

The main server you need to accommodate is the Domain Controller (or Controllers, if you have more than one). The DC wants to add the passel of SRV records we showed earlier. If it can't add them at setup time, it'll write the records, in master file format, to a file called System32\Config\netlogon.dns under the system root.

First, you'll need to determine which zone you need to update. That's just a matter of finding the zone that would contain the Windows 2000 domain name. If your Windows 2000 domain has the same name as an existing zone, of course, that's the zone to update. Otherwise, just keep stripping off the leading labels of your Windows 2000 domain until you get to the domain name of a zone.

Once you've got the zone that you need to update, you need to decide how to proceed. If you don't mind letting your Domain Controller dynamically update your zone, just add an appropriate allow-update substatement to the zone statement and you're done. If you'd rather not allow your DC complete control of the zone, you can leave dynamic updates disabled and let the DC create the netlogon.dns file. Then use an $INCLUDE control statement to read the contents of the file into your zone data file:

$INCLUDE netlogon.dns

If neither of these options appeals to you, because you want the DC to be able to change its SRV records but don't want it mangling your zone, you've still got a trick up your sleeve. You can take advantage of the funny format of the owner names in SRV records and create delegated subdomains called (in our case) _udp.fx.movie.edu, _tcp.fx.movie.edu, _sites.fx.movie.edu, and _msdcs.fx.movie.edu. We'll have to turn off name checking for _msdcs.fx.movie.edu, since the Domain Controller wants to add an address record to the zone in addition to a slew of SRV records. Then let the DC dynamically update these zones, but not your main zone:

acl dc { 192.253.254.13; };

zone "_udp.fx.movie.edu" {
	type master;
	file "db._udp.fx.movie.edu";
	allow-update { dc; };
};

zone "_tcp.fx.movie.edu" {
	type master;
	file "db._tcp.fx.movie.edu";
	allow-update { dc; };
};

zone "_sites.fx.movie.edu" {
	type master;
	file "db._udp.fx.movie.edu";
	allow-update { dc; };
};

zone "_msdcs.fx.movie.edu" {
	type master;
	file "db._udp.fx.movie.edu";
	allow-update { dc; };
	check-names ignore;
};

Now you've got the best of both worlds: dynamic registration of services with a safe production zone.