At its core, DHCP operates through Layer 2 broadcasts before IP assignment occurs. When a client sends a DHCPDISCOVER message, it uses:

Source MAC: client_mac
Destination MAC: ff:ff:ff:ff:ff:ff
Source IP: 0.0.0.0
Destination IP: 255.255.255.255

Any DHCP server on the same broadcast domain can respond, but here's where the static IP requirement becomes critical.

Consider this Python pseudocode showing DHCP server initialization:

def init_dhcp_server():
    if not is_static_ip(config.interface):
        raise DHCPConfigurationError(
            "Cannot bind to dynamic address - lease database would be unreliable"
        )
    bind_socket(IP=config.static_ip, PORT=67)
    load_lease_database()

The technical constraints become apparent:

1. Lease Database Integrity: DHCP servers maintain stateful records of IP assignments. If the server's IP changes, existing clients would lose their reference point for lease renewals.
2. Default Gateway Configuration: DHCP often provides gateway information. Clients would receive inconsistent routing instructions if the DHCP server's address fluctuated.

Your proposed multi-tier architecture creates a bootstrap paradox:

# Scenario where DHCP-B gets address from DHCP-A
DHCP-A (static) → DHCP-B (dynamic) → Client-X

# Failure case sequence:
1. DHCP-A reboots
2. DHCP-B's lease expires
3. Client-X requests renewal
4. DHCP-B cannot renew its own IP because DHCP-A is down
5. Entire network loses DHCP service

The DHCP protocol specification (RFC 2131) implicitly requires stability through these sections:

• Section 4.1: "The server identifies itself to the client" - requires consistent server identification
• Section 4.3.1: Lease renewal assumes stable server addressing

While not recommended, you could implement a hybrid approach using Python's asyncio:

async def fallback_dhcp():
    primary_ip = await get_dhcp_lease()
    backup_ip = "192.168.1.100/24"  # Hardcoded fallback
    
    while True:
        try:
            await renew_lease(primary_ip)
            serve_dhcp(primary_ip)
        except DHCPError:
            serve_dhcp(backup_ip)
            logging.warning("Fell back to static IP")

This demonstrates why static IPs are preferred - the complexity increases exponentially when trying to make DHCP servers dynamic.

Real-world implementations always use static IPs for DHCP servers, with these typical configurations:

When examining DHCP (Dynamic Host Configuration Protocol) at the packet level, we observe that while initial discovery occurs via broadcast (0.0.0.0), subsequent communication requires a stable endpoint. The DHCPOFFER, DHCPACK, and DHCPNAK messages all contain the server's IP in their headers. Consider this Wireshark filter to observe the behavior:

dhcp && (dhcp.option.dhcp == 2 || dhcp.option.dhcp == 5 || dhcp.option.dhcp == 6)

Your VM experiment highlights a critical chicken-and-egg problem. If Server B obtains its address dynamically:

1. During Server B's reboot, its IP lease might expire
2. Server A must be reachable to renew Server B's address
3. But Server B can't route renewal requests without an IP

This creates a circular dependency that breaks the network bootstrap sequence. The Windows Server implementation enforces static IPs precisely to avoid this failure mode.

Let's examine DHCP header structure from RFC 2131:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            xid (4)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           secs (2)            |           flags (2)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          ciaddr (4)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          yiaddr (4)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          siaddr (4)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          giaddr (4)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The siaddr field (server IP address) must remain constant across DHCP transactions. Clients cache this value for lease renewals.

Modern DHCP servers like Windows Server or ISC DHCPd perform these critical functions that require static addressing:

• DDNS (Dynamic DNS) updates - requires consistent source IP
• Option 82 (Relay Agent Information) processing
• Lease database maintenance with IP-based identifiers

Here's PowerShell code that would fail if the DHCP server had a dynamic IP:

# This command depends on the server's IP remaining stable
Add-DhcpServerv4Reservation -IPAddress 10.0.1.50 -ClientId "AA-BB-CC-DD-EE-FF" -Description "Printer"

While your proposed hierarchical design is theoretically possible, it introduces significant complexity. For redundancy, Microsoft recommends:

# Configure DHCP failover in Windows Server
Add-DhcpServerv4Failover -Name "HA-Pair" -ScopeId 10.0.1.0 -PartnerServer secondary.dhcp.local -AutoStateTransition $true

Both servers in the failover pair must maintain static IPs for consistent client communication.