Bravo on deciding to get rid of static IP assignments (except where absolutely necessary). I'd tell you to use the DHCP database as your "IP address list" documentation, too. Put in reservations for devices with static IP addresses assigned, as well. Make the DHCP database be the authoritative "IP address list" instead of having spreadsheets, etc, that fall out of date.
Here's some background re: DNS and DHCP in Windows. It sounds like you may not be aware that the client computer performs half of the registration (the "A" record), and can also perform the "PTR" record registration, too. This allows you to use virtually any DHCP server you want, so long as it hands out addresses of DNS servers that can accept dynamic registrations.
The Windows DHCP server performs backups of the DHCP database to the local hard disk drive periodcially. You can also export the database with "netsh" (W2K3 or newer) such that restore it to another server easily. Restoring an ISC DHCPd scope to another server is a matter of copying the relevant portions of the dhcpd.leases file and the dhcpd.conf file. Embedded DHCP servers may be more problematic in a restore scenario.
As stated above, your Cisco routers can hand out DHCP to Windows PCs, but the PCs can register their own "PTR" and "A" records. Have a look at the Group Policy setting "Register PTR Records" located under "Comptuer Settings", "Administrative Templates", "Network", and "DNS Client". The client will register the "A" record itself by default.
I wouldn't got with a roll-your-own Linux DNS deployment for this application. You're going to put a lot of time in it, and it will always be the source of "Gee, will this work with Windows Server 2029..." type of musings. If not for Active Directory, I might think differently. Since you've got AD in your environment, and since Microsoft tests AD on Microsoft DNS, I'd use Microsoft DNS.
Windows Server does not have the capability to sync DHCP server databases so that you can have multiple authoritative servers for the same subnet. This continues to be decidedly sub-optimal in Windows DHCP. This might be a "win" for ISC DHCPd on Linux. I haven't got any experience with this capability to share a DHCP lease database across multiple DHCP server, but it certainly sounds sweet. I am not aware of any capability in Cisco routers to do this. Again, you can have your PCs register themselves in DNS regardless of what DHCP server you use.
You could rig up active / passive DHCP on multiple Windows Server computers with some scripting and the native database export functionality, as well.
Personally, I'd go for the option of using Windows DNS everywhere, Windows DHCP everywhere where you can have a Windows DHCP server on the same LAN as the clients, and your Cisco routers handing out DHCP everywhere that you can't have a Windows Server computer. The Linux ISC DHCPd solution might be a "win", too, but I'd stick with Windows DNS.
This is probably not the best way to solve this problem but it worked. Here's what I did.
1) I added the following restriction to my Debian-based DHCP server and removed all of the fixed-address entries. This forces any clients in those IP ranges to move somewhere into the .41 - .199 range, otherwise when I turn on the Windows Server clients will receive leases with IPs in the .11 - .40 range that are already present on the network. I then let things sit long enough for any leases in that IP range to expire and have a new one issued.
subnet 192.168.61.0 netmask 255.255.255.0 {
option routers 192.168.61.1;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.61.255;
pool {
range 192.168.61.0 192.168.61.40;
deny all clients;
}
pool {
range 192.168.61.41 192.168.61.199;
}
}
I could not figure out a way to make the Windows Server DHCP implementation act as "authoritative"; the behavior I wanted is when clients with leases from the old Debian-based DHCP server sent their DHCPINFORM packets to the new Windows Server, I wanted those clients to receive a DHCPNAK and the go through the whole process again to get a lease, thus "re-populating" the addressing space from .11 and up.... regardless, continuing on.
2) I cheated by expanding the Exclusion range on the new Windows DHCP server to include 192.168.61.100 - 192.168.61.199. This will force any clients who were assigned an IP in that range by the Debian-based DHCP serve to have their DHCPINFORM denied and then issued a new lease at the "bottom" of the addressing space (.11 and greater).
3) At this point I simply turned the Debian DHCP server off, and the Windows Server on and let the expiry time sort things out. Because of the "deny all clients" line in my dhcpd.conf, there were no clients with "old leases" in the .11 - .40 addressing space that could cause an IP conflict, and because of the Exclusion of .100 - .199 ranges all DHCPINFORM requests were denied (at least I imagine that's what happened... I didn't bother looking at the transaction using a packet sniffer... I probably should of) and the addressing space was re-populated starting from the lower bound of .11.
Best Answer
Ideally, you'd modify dhcpd to support address assignment based on Option82, equivalent to the "hardware" lines in host objects. I've done it with the OpenBSD dhcpd when I worked at an ISP, which has a simpler internal structure to isc-dhcpd.
If you're not in a position to do that, then look at omapi(3) and omshell(1); you'd use OMAPI to dynamically create "class" and "pool" objects, to implement Zypher's suggestion. I just checked
dhcpd.hand theclassstruct has anOMAPI_OBJECT_PREAMBLE, so this should be possible. Beware that the documentation on OMAPI can be a little ... skimpy.