DHCP Processes and Interactions

Applies To: Windows Server 2008

In Windows Server 2008, the DHCP Server service interacts with several other services, including the directory service in Active Directory Domain Services (AD DS), as well as DNS and the Routing and Remote Access service.

Detecting unauthorized DHCP servers

An unauthorized DHCP server on a network can cause a variety of problems, such as the leasing of incorrect IP addresses and options. To protect against this type of problem, when a DHCP server running Windows Server 2003 or Windows Server 2008 starts on the network, it first attempts to determine if it is authorized to service clients. Different methods are used, depending on how the network is configured.

Unauthorized domain member DHCP servers

A domain member DHCP server queries AD DS. The DHCP server compares its IP address and server name to the list of authorized DHCP servers. If either the server name or IP address is found on the list of authorized DHCP servers, the server is authorized as a DHCP server. If no match is found, the server is not authorized in AD DS, the server does not respond to DHCP traffic, and a system event is logged.

Unauthorized workgroup DHCP servers

A Windows Server 2008 workgroup member DHCP server uses the following process to detect other DHCP servers running on the reachable network and determine if it is authorized to provide service.

1. When the DHCP Server service starts, it sends a DHCPInform request message to the reachable network, using the local limited broadcast address (255.255.255.255), to locate other DHCP servers on the network.

   This message includes several vendor-specific option types that are known and supported by other DHCP servers running Windows Server 2008. These other DHCP servers will respond with a DHCPAck containing information indicating if they are authorized domain member or workgroup member servers.

2. When queried, other DHCP servers running Windows Server 2003 and Windows Server 2008 reply with DHCPAck messages to acknowledge and answer with workgroup or domain membership information.

3. If an Active Directory domain member DHCP server is found, then the workgroup member server determines that it is not authorized and does not service clients. If other workgroup servers are found, the workgroup member server determines that it is authorized to service clients, and begins service. It then performs the check again at one-hour intervals.

DHCP and DNS

DNS servers provide name resolution for network clients. DNS resolves a fully qualified domain name (FQDN) to its corresponding IP address.

Although DHCP provides a powerful mechanism for automatically configuring client IP addresses, in releases of the operating system before Windows 2000, the DHCP Server service did not notify DNS to update the DNS records on behalf of the client. Specifically, DHCP did not map the client name to an IP address and did not update IP address-to-name mappings using DNS dynamic update.

Without a way for DHCP to interact with DNS, the information maintained by DNS for a DHCP client might be incorrect. For example, a client can acquire its IP address from a DHCP server, but the DNS records might not reflect the IP address acquired nor provide a mapping from the new IP address to the FQDN.

DNS dynamic update

In Windows Server 2003 and Windows Server 2008, DHCP servers and clients can register record updates if the DNS server supports DNS dynamic update. In Windows Server 2003 and Windows Server 2008, the DNS service supports DNS dynamic update.

A DHCP server running Windows Server 2008 can register with a DNS server and update pointer (PTR) and address (A) resource records on behalf of its DHCP-enabled clients by using the DNS dynamic update protocol.

The ability to register A and PTR resource records lets a DHCP server act as a DNS registration proxy for clients using Windows NT 4.0, Windows 98, or Windows Millennium Edition, and possibly other clients that are not able to register the updates on their own, as shown in the following figure.

DHCP server performing DNS dynamic update on behalf of DHCP client

DHCP clients running Windows operating systems from Windows 2000 and later typically update their own dynamic forward lookup names, as shown in the following figure.

DHCP client and DHCP server performing DNS dynamic update

An additional DHCP option code (option code 81) enables the return of a client’s FQDN to the DHCP server. If implemented, the DHCP server can dynamically update an individual computer’s resource records on a DNS server by using the DNS dynamic update protocol.

For more information about DNS dynamic update, see the DNS Technical Reference (https://go.microsoft.com/fwlink/?LinkId=129568).

Secure DNS dynamic updates

By itself, DNS dynamic update is not secure; any client can modify DNS records. When secure DNS dynamic update is configured, the authoritative name server accepts updates only from clients and servers that are authorized to make DNS dynamic updates to the appropriate objects in AD DS. Secure DNS dynamic update is available only on Active Directory–integrated zones.

Secure DNS dynamic update allows you to specify the users and groups that can modify zones and resource records. By default, Windows clients running Windows 2000 and later attempt unsecured DNS dynamic updates first. If that request fails, they attempt secure updates.

When using multiple DHCP servers and secure DNS dynamic updates, add each of the DHCP servers as members of the DnsUpdateProxy global security group so that any DHCP server can perform a secure DNS dynamic update for any record. Otherwise, when a DHCP server performs a secure DNS dynamic update for a record, that DHCP server is the only computer that can update the record.

DHCP and Routing and Remote Access

The Windows Server 2008 DHCP Server service interacts with the Windows Server 2008 Routing and Remote Access service in two ways. When Routing and Remote Access is used to provide remote access to PPP clients, the remote access server obtains IP addresses from the DHCP server, which it then assigns to the PPP clients.

DHCP also interacts with routers when DHCP clients and DHCP servers are on different subnets. In this situation, a router that can act as a DHCP relay agent must be present on the subnet of the DHCP client. You can use the Windows Server 2008 Routing and Remote Access service to act as a DHCP relay agent.

Configuration of PPP clients

When the Routing and Remote Access service is configured to use DHCP to obtain IP addresses for TCP/IP based clients, the Routing and Remote Access service instructs the DHCP Client service to obtain 10 IP addresses from a DHCP server when the first PPP client connects. The Routing and Remote Access service uses the first IP address obtained from DHCP for the Internal interface, which is a logical interface that represents the connections to all PPP-based clients. Subsequent addresses are assigned to TCP/IP-based PPP clients as they connect. After the PPP client disconnects, the now-unassigned IP address is reused for a future PPP connection.

The remote access server uses the IP addresses from these leases to configure PPP clients, but discards all options contained in the leases.

When all 10 IP addresses are used, the Routing and Remote Access service obtains another block of 10 IP addresses from the DHCP server.

With a Windows NT 4.0–based remote access server, DHCP-allocated addresses are recorded and reused when the remote access service is restarted. In Windows Server 2003 and Windows Server 2008, the Routing and Remote Access service releases all DHCP-allocated IP addresses by using DHCPRelease messages each time the service is stopped.

If the DHCP server becomes unavailable, the DHCP Client service on the Routing and Remote Access server assigns APIPA addresses to TCP/IP-based PPP clients. APIPA addresses for remote access connectivity work only if the network to which the remote access client is attached is also using APIPA addresses (which is not a recommended configuration). If the local network is not using APIPA addresses, remote access clients can only obtain point-to-point remote access connectivity.

The Routing and Remote Access service uses a specific LAN interface to obtain DHCP-allocated IP addresses for remote access clients. You can select which LAN interface to use on the IP tab of the Properties dialog box of a server in the Routing and Remote Access snap-in. If the Routing and Remote Access server has more than one LAN interface installed, the Routing and Remote Access Server Setup Wizard prompts you to select the LAN interface.

Options for PPP clients

Although the remote access server running Windows Server 2008 discards all options from the leases it obtains from the DHCP server, PPP clients do receive specific configuration information, such as WINS server and DNS server assignments, from the settings of the remote access server as part of the negotiation of the PPP connection. However, clients running Windows 2000, Windows XP, or Windows Server 2008 can receive additional configuration information from the DHCP server, by using a DHCPInform message after the connection has been established. These options are available only if the VPN server has the DHCP Relay Agent routing protocol component configured with the IP address of the DHCP server.

Following are the three steps taken by the remote access server to obtain leases from the DHCP server.

1. Remote access server obtains IP addresses

   First, when the first PPP client connects to the remote access server, the remote access server obtains 10 IP addresses from the DHCP server.

2. Remote access server configures PPP client

   Next, the remote access server uses Internet Protocol Control Protocol (IPCP) to configure the IP address of the client, as well as assign the DNS server and WINS server settings that are configured on the selected interface of the remote access server.

3. PPP client obtains DHCP options

   After the remote access client has an IP address, it sends a unicast DHCPInform message to request options from the DHCP server to the remote access server. The remote access server must also be configured with the DHCP Relay Agent routing protocol component. The remote access server, acting in its role as a DHCP relay agent, then sends the DHCPInform message to the DHCP server. The DHCP server responds with the options in a DHCPAck message, which is sent back to the remote access server. Finally, the DHCP relay agent on the remote access server sends the DHCPAck message to the remote access client, as shown in the following figure.

The following table lists the DHCP options that are requested by the client in the DHCPInform message.

DHCP options requested in DHCPInform message

DHCP relay agents

A DHCP relay agent is a hardware device or software program that can pass DHCP or BOOTP messages between DHCP clients and servers, according to the RFC 2131 specification for DHCP. DHCP relay agents act as proxies, forwarding messages from a subnet to one or more DHCP servers. Some DHCP messages are sent as broadcasts, so without relay agents and the ability to pass DHCP and BOOTP messages across routers, every subnet on a network must have its own DHCP server.

Most routers support acting as a DHCP relay agent. Alternatively, if a router cannot function as a DHCP relay agent, a computer that can function as a DHCP relay agent must be configured on each subnet to which the router is connected.

In cases where it is impractical or impossible to configure routers to act as a DHCP relay agent, you can configure a computer running Windows Server 2003 or Windows Server 2008, to act as a relay agent by enabling the Routing and Remote Access service and installing the DHCP Relay Agent routing protocol component.

How relay agents work

The following figure shows how Client C on Subnet 2 obtains a DHCP address lease from DHCP Server 1 on Subnet 1.

Using a relay agent

1. DHCP Client C broadcasts a DHCPDiscover message on Subnet 2 as a UDP datagram over well-known UDP port 67, which is the port reserved and shared for BOOTP and DHCP server communication.

2. The relay agent, in this case a DHCP relay-enabled router, examines the Gateway IP Address field (also known as the giaddr field) in the DHCP message header. If the field has an IP address of 0.0.0.0, the agent fills the Gateway IP Address field with the IP address assigned to the interface on which the DHCPDiscover was received, and forwards the DHCPDiscover message as a unicast message to the DHCP server on Subnet 1.

3. When DHCP Server 1 receives the DHCPDiscover message, it examines the Gateway IP Address field to determine if the packet was relayed. The DHCP server then determines whether it can supply an IP address lease to clients on the subnet indicated by the address in the Gateway IP Address field.

   For example, if the Gateway IP Address field has an IP address of 192.168.45.2, the DHCP server checks its DHCP scopes for a scope range that includes 192.168.45.2 (the gateway IP address in the packet). To find a match, the DHCP server determines whether the IP address 192.168.45.2 matches the network ID of each scope. It determines the network ID of each scope by ANDing any IP address in the scope with its corresponding subnet mask. In this case, the DHCP server checks to see which scope includes addresses for Subnet 2. If a scope exists that matches this criterion, the DHCP server selects an available address from the matched scope to use in an IP address lease offer response to the client.

4. DHCP Server 1 sends a DHCPOffer message directly to the relay agent identified in the Gateway IP Address field.

5. The relay agent relays the DHCPOffer message to the DHCP client.

   Depending on the value of the Broadcast flag in the DHCPOffer message (which was copied from the DHCPDiscover message), the DHCP relay agent either unicasts or broadcasts the DHCPOffer message.

6. By using a similar process, a DHCPRequest message is relayed from client to server, and a DHCPAck message is relayed from server to client.