Handling Windows Registration with a BIND Name Server
8.8.1 Problem
You want to allow your computers running Windows 2000 and XP to register using dynamic update.
8.8.2 Solution
There are several techniques for dealing with Windows computers' desire to register their name-to-address and address-to-name mappings, but one of the most popular is to create a special subzone just for the computers to register in. If your main forward-mapping zone is corp.example, you might create a dyn.corp.example subzone for the Windows computers to live in. The name servers for dyn.corp.example don't need to be different from the name servers that serve corp.example; what's important is that the zones are separate. This lets you allow dynamic updates to one while keeping the other static.
The delegation for dyn.corp.example in the corp.example zone might look like this:
dyn.corp.example. IN NS ns1.corp.example. dyn.corp.example. IN NS ns2.corp.example.
dyn.corp.example could begin life as a minimal zone, with just an SOA record and NS records:
$TTL 1d @ IN SOA ns1.corp.example. hostmaster.corp.example. ( 2002061900 1h 15m 30d 1h ) IN NS ns1.corp.example. IN NS ns2.corp.example.
Over time, of course, computers running Windows will register themselves and "fill out" the contents of the zone.
The name servers for dyn.corp.example must allow dynamic updates from the addresses of any Windows computers that might register. For example:
acl dhcp-clients { 192.168.0.128/25; }; acl static-clients { 192.168.0.64/26; }; zone "dyn.corp.example" { type master; file "db.dyn.corp.example"; allow-update { dhcp-clients; static-clients; }; };
Finally, the Windows computers must be configured with dyn.corp.example as their primary DNS suffix, Microsoft's term for a local domain name. Go to My Computer
8.8.3 Discussion
All this work is necessary because allowing dynamic updates to your main forward-mapping zone from just any old computer running Windows 2000 or XP is a bad idea. One of those users could easily download a copy of BIND, precompiled for Windows computers, and use nsupdate to modify the zone. And with unsigned dynamic updates -- the only kind that currently work between Windows computers and BIND name servers -- there are no restrictions to what he could change in the zone. By cordoning off the Windows computers in their own zone, they can only hurt each other.
If you're not comfortable with the idea of allowing dynamic updates to a subzone from all of your Windows machines, you might consider using DHCP to assign their addresses -- even the addresses of statically addressed hosts -- and configuring the DHCP server to assume responsibility for updating its clients' forward- and reverse-mapping information. Most modern DHCP servers support this. With this configuration, you can allow dynamic updates only from the address of your DHCP server. You can also restrict dynamic updates to your reverse-mapping zones to just your DHCP server, which helps minimize the threat to those zones. See Section 8.10 for instructions on configuring one DHCP server, the ISC's, to update a forward- and reverse-mapping zone.
8.8.4 See Also
"DNS and Windows 2000" in Chapter 16 of DNS and BIND; and "The Ties That BIND" in the March, 2001, issue of Linux Magazine, at http://www.linux-mag.com/2001-03/bind_01.html.