DHCP

Dynamic Host Configuration Protocol, or DHCP, lets a host obtain network configuration from a server instead of requiring an administrator to configure every setting manually. In a typical initial IPv4 exchange, the client broadcasts DHCPDISCOVER, receives DHCPOFFER, sends DHCPREQUEST, and receives DHCPACK. This sequence is commonly called DORA. DHCPv4 uses UDP server port 67 and client port 68. Clients subsequently renew their leases; not every renewal repeats the initial discovery sequence.

DHCP can deliver more than an IP address. Options can identify DNS servers, a domain name, a default gateway, time servers, and other supported parameters. Available options and client behavior vary by platform and operating system. DHCP does not perform DNS resolution itself: it tells clients which resolver to use. Similarly, receiving a gateway address does not create routes throughout a cloud network or authorize traffic through firewalls.

Cloud platforms commonly provide DHCP through their virtual networking infrastructure. The provider's control plane assigns an address to a virtual network interface, and DHCP communicates appropriate configuration to the guest. Consequently, a dynamically configured guest can have a stable private address. In Amazon EC2, the primary private IPv4 address remains associated with its network interface across instance stops and starts; renewing a DHCP lease does not inherently allocate a different address. Manually configuring an arbitrary address inside the guest does not assign that address to the cloud network interface.

In Amazon VPC, DHCP option sets control supported parameters such as domain names, DNS servers, and time servers. A VPC can have at most one associated DHCP option set, and its default association can be removed. One option set can be associated with multiple VPCs within the same account and Region. Option sets are immutable: to change their values, create a replacement and associate it with the required VPCs. Existing instances generally receive changed settings during lease renewal, so an association change is not necessarily reflected immediately in running guests.

For example, workloads that must resolve an enterprise directory domain might receive the addresses of reachable directory DNS servers through DHCP options. Those servers must also resolve or forward other required namespaces. Alternatively, workloads can retain the VPC-provided resolver and use Route 53 Resolver forwarding rules for selected enterprise domains. Supplying multiple DNS server addresses does not provide reliable domain-based query routing because clients differ in how they select and retry resolvers.

In multi-account, multi-Region, and multi-VPC architectures, configure DHCP independently of network connectivity. VPC peering and transit gateways do not merge DHCP configurations or forward client DHCP broadcasts between VPCs. Create and associate the intended option sets in each account and Region, then separately provide routes and security permissions to custom DNS or time servers. Changing DHCP options does not modify VPC route tables, security groups, or network ACLs. Traditional DHCP relay designs should not be assumed to work through cloud routed connectivity without explicit platform support.

The main trade-off is centralized consistency versus dependence on correct settings and client renewal behavior. An incorrect DNS option can disrupt applications even when IP connectivity remains healthy. Inspect the guest's effective address, lease, resolver configuration, and DNS responses before changing routes. Coordinate forced renewals carefully because operating-system commands can temporarily interrupt connectivity. On traditional networks, rogue DHCP servers are another concern because basic DHCP does not authenticate configuration sources. DHCPv6 is a separate protocol, and IPv6 networks may also use router advertisements and stateless address autoconfiguration; IPv4 DORA behavior does not describe every IPv6 deployment.