Section 17.10. DNS, Windows, and Active Directory

Modern Windows operating systems by which we mean Windows 2000, Windows XP, and Windows Server 2003can use standard dynamic updates to register hosts in DNS. For a modern Windows client, registration means adding a name-to-address mapping and an address-to-name mapping for that clientinformation Windows clients formerly registered with WINS servers. For a Windows 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, an Active Directory Domain Controller uses dynamic update to add SRV records that tell Windows clients which services it's running.

17.10.1. How Windows Uses Dynamic Update

So what gets added when a client registers? Let's reboot a Windows 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 nameserver. 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 nameserver 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 isn'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.edu already points to the correct address, stop. Otherwise, send another dynamic update to bladerunner.fx.movie.edu with the prerequisites that mummy.fx.movie.edu isn't an alias and doesn't have an address recordany address recordalready. 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 nameserver in the MNAME field of the SOA record (though because the MNAME field contains bladerunner.fx.movie.edu, which we looked up recently, and modern Windows OSes have 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.

If we're using the Microsoft DHCP Server included with a modern Windows server operating system, the DHCP server, by default, adds 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 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 an Active Directory domain called fx.movie.edu, let's take a look at the records that our Domain Controller, matrix.fx.movie.edu, added:

These records tell Active Directory clients where the services offered by the Domain Controller, including Kerberos and LDAP, are running.^[*] 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 twice as many records.

The owner names of all the records end in fx.movie.edu, the name of the Active Directory domain. If the Active Directory domain was called ad.movie.edu, the dynamic update routines would update the zone containing the domain name ad.movie.edu, which is movie.edu.

17.10.2. Problems with Active Directory and BIND

While Microsoft's decision to replace WINS with DNS was laudable, the implementation poses some problems for folks who run BIND nameservers. First, Windows 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 happens to use a name that is already taken, maybe by one of our rendering servers, his computer will 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 described in the previous section's 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 Microsoft DHCP Server handle all registration, you don't have the option of leaving conflicting addresses alone. The Microsoft 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 the registering, why would anyone consider it? Because if you allow any client to register itself, and you can use only 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 can easily fire off a few custom-made dynamic updates to change your zone's MX records or the address of your web server.

17.10.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 negotiates a TSIG key with the help of a Kerberos server, then uses that key 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 nameserver 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.

Modern Windows 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.

17.10.3.1. BIND and GSS-TSIG

Unfortunately, BIND nameservers don't yet support GSS-TSIG, so you can't use Windows'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 the update policy rules described in Chapter 10 to control which keys can update which records. A simple set of rules that says:

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

17.10.4. What to Do?

In the meantime, how do you handle the proliferation of Windows and Active Directory on your network? Well, Microsoft would advise you to "upgrade" all your nameservers to the Microsoft DNS Server. But if you like BINDand we doyou'd probably like some other options.

17.10.4.1. Handling Windows clients

The first (and probably most common) option for handling your Windows 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 client will try to register itself in a forward-mapping zone with the same name as its Active Directory domain. So we'll have to do some extra configuration to tell our clients to register in win.fx.movie.edu instead 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 allow dynamic updates only from the address of the DHCP server. You then configure your DHCP server to assume responsibility for maintaining both A records and PTR records. (You can manually add A and PTR records for hosts that don't use DHCP.)

In this scenario, it's more difficult for the little imps to send their custom dynamic updates to your nameserver because 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.

If you're willing to consider using a different DHCP server, you can deploy an even more secure solution. The latest versions of the ISC DHCP server support TSIG-signed dynamic updates and use a clever mechanism based on TXT records to avoid name collisions in DHCP clients. When the DHCP server adds an A record on behalf of a DHCP client, it also adds a TXT record to the client's domain name, in which the record-specific data is a one-way hash of the client's MAC address. The resulting records look like this:

If the DHCP server later tries to add a different A record to that domain name on behalf of a client, it checks whether the client's MAC address hashes to the same value that's stored in the TXT record. If it does, the DHCP server removes the old A record because it belonged to the same client; the client has probably just moved to a new subnet or leased a different address. If it doesn't, the DHCP server won't perform the update because the old A record likely belongs to a different client that happens to have the same domain name.

17.10.4.2. Handling Windows servers

The main server you need to accommodate with your nameservers is the Domain Controller (or Controllers, if you have more than one). The DC wants to add the passel of 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 need to determine which zone you need to update. That's just a matter of finding the zone that contains the Active Directory domain name. If your Active Directory 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 Active Directory domain until you get to the domain name of a zone.

Once you have 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 datafile:

If neither option appeals to you because you want the DC to be able to change its records but don't want it mangling your zone, you still have 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. (You might have to turn off name checking for _msdcs.fx.movie.edu, because the Domain Controller wants to add an address record to the zone in addition to a slew of SRV records, and the owner name of that record will contain an underscore.) Then let the DC dynamically update these zones, but not your main zone:

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