Why does a DHCP server need a static IP address?
My understanding of DHCP is, a client broadcasts a DHCP Discovery request on the network, and any device on the network can respond.
A client can make an unicast DHCP request too, the renewal request is made in unicast, so the client requests directly the DHCP Server. What if the DHCP changed his original IP address ? The renewal will fail and the next request will be made in broadcast. Which is not a behavior that will optimize your network traffic.
Microsoft:
Renewing a Lease The DHCP client first attempts to renew its lease when 50 percent of the original lease time, known as T1, has passed. At this point the DHCP client sends a unicast DHCPRequest message to the DHCP server that originally granted its lease. If the server is available, and the lease is still available, the server responds with a unicast DHCPAck message and the lease is renewed.
Source
ISC:
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/00:0c:29:ac:18:75
Sending on LPF/eth0/00:0c:29:ac:18:75
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 << First request
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 10.0.0.253
DHCPACK from 10.0.0.253
bound to 10.0.0.6 -- renewal in 133 seconds.
DHCPREQUEST on eth0 to 10.0.0.253 port 67 << Renewal
DHCPACK from 10.0.0.253
bound to 10.0.0.6 -- renewal in 119 seconds.
DHCPREQUEST on eth0 to 10.0.0.253 port 67
DHCPACK from 10.0.0.253
bound to 10.0.0.6 -- renewal in 118 seconds.
Once the lease has been granted, however, future DHCP DHCPREQUEST/RENEWAL messages are unicast directly to the DHCP Server
Source
A DHCP server must have a configured IP address so that it can know which scopes are locally attached to physical interfaces, and which Scopes can only be served via a DHCP relay.
Ignore a management point of view,
I am sorry, but I think it is silly to try and hand-wave away and ignore the practical issues about running your network. Getting a valid IP address is critical on most networks. You would never want your DHCP server to fail because it couldn't get its own valid address. Software, and protocols are designed to work in common practical situations. What you are describing seems to create multiple places for things to fail with little or no real gain.
If you really want to have some kind of dynamic configuration of a DHCP server you should probably be looking at using a configuration management system to enforce the settings on the DHCP server, instead of trying to use DHCP to configure your DHCP server.
Technically the DHCP Server must have a known IP address for the packets that are sent after the initial discovery packet. This address usually needs to be known when it starts up so that's pretty much static. It doesn't (IIRC) have to be on the same subnet so that DHCP relay will work, but it's not going to work without a route to the subnet it's allocating on.
If you really want to do it you can probably arrange something using a virtual interface so your physical adaptor (server B) has IP addresses on both the subnets that are on your wire (one DHCP and the other static).
Like Zoredache I would suggest you should really stick with one DHCP server setup for the wire. Most DHCP servers will allow you to classify devices in various ways (eg: Parts of the MAC address) and assign these to different sections of the subnet. You would then be able to give different firewall rules to these subsections.
There would be no difference in security because any client can setup it's own static address in both scenarios.