Probably a bad idea
Well it would be easy enough to write a script called by cron to monitor the network using a tool like dhcp_probe or RougeDetect, and that script could of course start and stop your dhcp server.
The problem is that the new dhcp server will not know about current leases.
For example, you plug in your box, it finds no DHCP Server and so it starts up dhcpd and starts serving up IP addresses. What if there are currently leased IPs on the network, your DHCP server will not be aware of them and could re-allocate them, causing duplicate IPs on the network.
The same is true if another device comes on-line after yours and starts serving DHCP, your DHCP server could have allocated say 192.168.0.101. Another DHCP Server starts up, which shuts your DHCP server down, and then a new request comes in it serves 192.168.0.101, now you have two computers with the same IP address on the same network. NOT GOOD!
If you are trying to provide redundancy you will need a DHCP server that can share information about DHCP allocations use DHCPD as part of a cluster, OR you will need to set up non overlapping IP Ranges (probably within the same subnet) to keep things going. This too of course will have some potential issues such as making sure the Gateway address, Subnet . . . are correct on both servers, and it will cause lease renewals to fail and a subsequent change in IP on a client device.
You may want to take a look at clustering your DHCP Server, so if one server goes down it will fail over to the remaining node(s) in the cluster, maintaining current lease info . . .
If I have missed the reason for wanting to do this, perhaps a more detailed explanation of what you want to accomplish and the reasoning behind it would be useful. I know Windows server with AD can do this as can Novell servers through e-directory, but just plain linux dhcpd doesn't leave the needed bread crumbs to make it seamless.
Hope this is helpful.
Last edited by never say never; 04-01-2010 at 11:31 AM.