A Wireshark capture of a routine DHCP renewal has exposed just how much network configuration a Windows 11 PC quietly accepts from a DHCP server. Beyond handing out an IP address, the server can push new DNS servers, connection-specific search suffixes, and static routes directly into the operating system’s TCP/IP stack—all without a single prompt or local setting change. The demonstration, first published by MakeUseOf, is a vivid reminder that DHCP is not merely an address vending machine; it’s a full configuration plane that can shape the way your machine routes traffic, resolves names, and even discovers network services.

The experiment, conducted in a controlled VMware Workstation lab with an OpenWrt router and a Windows 11 client, captured the classic four-packet DHCP exchange: Discover, Offer, Request, Acknowledgment—commonly called DORA. But the real payload was in the numbered options tucked inside the final ACK packet. Those options, often overlooked, are where the server defines the client’s network personality.

What the packets actually delivered

When the Windows 11 VM ran ipconfig /release and ipconfig /renew, Wireshark logged the expected address assignment (192.168.24.138 in the test), but also a set of configuration fields that Windows dutifully installed. The IP address itself wasn’t even an option; it sat in a dedicated field called yiaddr (“your IP address”). The real action was in the options:

  • Option 1 delivered the subnet mask (255.255.255.0)
  • Option 3 set the default gateway (192.168.24.254)
  • Option 6 initially pointed DNS at the OpenWrt router, then later was changed to distribute Quad9 (9.9.9.9) and Cloudflare (1.1.1.1)
  • Option 15 supplied the connection-specific domain (“lab.home.arpa”)
  • Option 119 pushed two DNS search suffixes (“lab.home.arpa” and “services.home.arpa”)
  • Option 121 injected two routes: a default route (0.0.0.0/0 via 192.168.24.254) and a route for the 198.51.100.0/24 network via the same gateway
  • Options 51, 58, and 59 governed lease timers (12-hour lease, 6-hour renewal, 10.5-hour rebinding)

Crucially, after these options were changed on the OpenWrt scope and the Windows client renewed its lease, the machine adopted every one of them without a local configuration touch. The DNS servers shown in the adapter properties now listed Quad9 and Cloudflare; the connection-specific DNS suffix was set; a “route print” showed the 198.51.100.0/24 route with a protocol label of “Dhcp.” As MakeUseOf noted, the client’s network personality had been completely rewritten from the server side.

The shopping list your PC sends to the network

Equally revealing was what Windows 11 demanded in its DHCP Discover packet. The client included an Option 55 – Parameter Request List – that reads like a legacy wishlist. It asked for:

  • Essential: subnet mask (1), router (3), DNS servers (6), domain name (15)
  • Advanced: vendor-specific data (43), captive portal info (114), domain search list (119), standard classless routes (121), Microsoft classless routes (249), WPAD proxy discovery (252)
  • Legacy: router discovery and static routes (31, 33), NetBIOS name server, node type, and scope (44, 46, 47)

Windows 11 also identified itself with Option 60 as “MSFT 5.0,” a vendor class identifier that has persisted since the Windows NT era. That means even the most modern Windows client is prepared to be configured by DHCP servers that still believe in WINS and classful routing. For network admins, this list is a clue that the client expects much more than an IP, and it will happily accept whatever the server offers from that menu.

What this means for you (and your PC)

For everyday Windows users, the takeaway is clear: the network you connect to can silently change your DNS servers, your search domains, and your routing tables. If you’re on a coffee shop Wi-Fi or a hotel network, a rogue or misconfigured DHCP server could redirect your traffic by handing out a different DNS resolver or a more specific route. Even your home ISP’s customer-premises equipment (CPE) often pushes ISP-specific DNS servers and sometimes search domains. You might have manually set your preferred DNS to a privacy-focused resolver, but a DHCP renewal overrides those settings unless you take precautions.

Power users and homelab enthusiasts—especially those setting up PXE boot environments, VLAN segmentation, or automated virtual machine provisioning—gain a powerful tool. DHCP can serve as a lightweight configuration management plane. By carefully crafting options on a router like OpenWrt or pfSense, you can automatically provision DNS, NTP, search domains, and static routes to every client that joins the network. That eliminates per-machine configuration and simplifies scaling.

IT administrators overseeing enterprise networks must recognize that DHCP is a critical control point. A misconfigured scope option can break connectivity silently, or worse, open security holes. For example, an attacker who sets up a rogue DHCP server on a corporate network could push a malicious DNS suffix or route traffic through a controlled gateway, potentially enabling man-in-the-middle attacks. Auditing DHCP configurations, monitoring for unauthorized DHCP servers, and locking down switch ports are essential practices. Additionally, the dual-stack reality of IPv6 adds complexity: as the experiment showed, changing DHCPv4 DNS options didn’t affect IPv6 DNS resolution because nslookup still preferred the IPv6 resolver advertised by the router’s Router Advertisements. So, for dual-stack networks, both DHCPv4 and DHCPv6/RA must be managed consistently.

How we got here: DHCP’s long configuration history

DHCP was never just about IP addresses. Defined in RFC 2131 and expanded by countless options, it was designed from the start to deliver all the parameters a host needed to operate on an IP network. Windows has a particularly deep history with DHCP options. In the early days of enterprise networking, Microsoft clients relied on DHCP for WINS server discovery, NetBIOS node type settings, and even proxy auto-discovery. Many of those legacy options remain in the Windows 11 request list for backward compatibility, even though most modern networks no longer use them. The presence of both the standard classless static route option (121) and Microsoft’s proprietary variant (249) is a direct legacy of the days when Microsoft’s DHCP server implementations differed from the IETF standard. Today, Windows accepts either, but the client’s request for both highlights the OS’s commitment to working in heterogeneous environments.

The MSFT 5.0 vendor class identifier is another artifact. It tells DHCP servers that the client is a Microsoft Windows machine, which can be used to deliver Microsoft-specific options. In large networks with network access protection or custom provisioning tools, this vendor class allows fine-grained differentiation between device types.

This historical breadth means that a Windows PC arriving on a network is predisposed to trust a wide array of DHCP-delivered configurations. It’s a design that trades security for convenience, and it’s up to network operators and end users to be aware of the trade-off.

How to check and control DHCP-delivered settings

If you want to see exactly what your Windows machine is receiving from DHCP, you can inspect the lease state without installing Wireshark:

  1. Open a Command Prompt or PowerShell and type ipconfig /all. Look for the “DHCP Server” entry, then note the DNS Servers, Connection-specific DNS Suffix, and Lease Obtained/Expires timestamps. If you see DNS servers you didn’t configure, they likely came from DHCP.

  2. Check installed routes: Run route print or Get-NetRoute -Protocol DHCP in PowerShell. Any routes marked with “Dhcp” in the Protocol column were installed by the DHCP server. This can reveal unexpected routing changes.

  3. Force a renewal (ipconfig /release followed by ipconfig /renew) and immediately check the above again to see what the server is pushing right now.

  4. Capture packets yourself with Wireshark if you’re comfortable. Use the filter bootp to isolate DHCP traffic. Look at the ACK packet to see all options the server is sending.

  5. Set manual overrides carefully: If you want to lock down specific settings, you can manually configure DNS servers and a static IP, but be aware that switching back to DHCP will reapply server settings. You can also configure DHCP class IDs or vendor-specific settings on the server side to control what certain clients receive.

  6. For IT admins: Audit your DHCP scopes regularly. Document which options are being distributed and why. Use DHCP server authorization in Active Directory environments to prevent rogue servers. Consider implementing DHCP snooping on switches. For dual-stack environments, verify IPv6 Router Advertisement settings (especially the DNS option) and DHCPv6 configurations to ensure consistency.

  7. For security-conscious users: On untrusted networks, you might consider using a VPN that forces its own DNS, or manually setting DNS servers that are encrypted (DNS-over-HTTPS) within the browser. Tools like DNSCrypt can also provide a local stub resolver that bypasses DHCP-provided DNS.

Looking ahead: DHCP as an automation plane

The homelab experiment that inspired this analysis was driven by a need for PXE boot automation—a scenario where DHCP options are essential. As networks become more software-defined and Zero Trust architectures gain adoption, DHCP’s role is expanding beyond simple address management. Systems like Windows Autopilot and cloud-based provisioning often rely on DHCP options to direct devices to the right management endpoints. In such environments, understanding the full DHCP payload becomes a necessary skill for both builders and defenders.

For Windows 11 users, the message is simple: the next time you connect to a network, remember that your PC is not just asking for an IP address—it’s handing over a shopping list and accepting a delivery of its entire network configuration. Know what’s in the package.