 |  |
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:
- 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, which is 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.eduisn't an alias (i.e., doesn't own a CNAME record) and that it doesn't 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.edualready points to its address, stop. Otherwise, send another dynamic update to bladerunner.fx.movie.edu with the prerequisites that mummy.fx.movie.eduisn't an alias and doesn't have an address record already. If the prerequisites are satisfied, the update adds an address record pointing mummy.fx.movie.edu to 192.253.254.13. If mummy.fx.movie.edu already has an address record, the client sends an update to delete that address 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 isn't 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.
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:
Whoa! That's a lot of records!$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.
These records tell Windows 2000 clients where the services offered by the Domain Controller, including Kerberos and LDAP, are running.[107] 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.
[107]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, "Security"). 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, "Advanced Features" 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;
};
};
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.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:
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:$INCLUDE netlogon.dns
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;
};
