DHCP Configuration

DHCP Options: The Settings That Make DHCP “Work”

Getting an IP address is only half the battle. DHCP also delivers the configuration that tells a client how to reach other networks and how to resolve names. When options are wrong, the symptom is classic: “I got an IP, but nothing works.”

After this page, you should be able to:

  • Explain what DHCP options are (the “configuration payload” of a lease)
  • Identify the Big 4 options and what breaks when each is wrong
  • Use a simple “specific overrides general” mental model for option precedence
  • Understand why option changes can feel delayed (lease renewal timing)
  • Troubleshoot “got an IP but nothing works” using client-side checks first

What DHCP Options Are

DHCP options are the settings bundled with the lease. They’re the “directions” clients use to function on the network: where the router is, where DNS is, what subnet they’re in, and more.

Important: a client can have a perfectly valid IP address and still be “offline” if the gateway, DNS, or mask options are wrong.

The Big 4 Options (The Ones That Break Networks)

1) Default Gateway (Router)

This is where the client sends traffic destined for other subnets/the internet. If the gateway is wrong, the client may still talk to local devices but nothing beyond the subnet works.

2) DNS Servers

DNS translates names to IPs. Wrong DNS makes the internet “look down” even when routing is fine. You can often still reach things by IP, but not by name.

3) DNS Suffix / Search Domain

In many orgs, internal resources are referenced as short names (e.g., fileserver). The suffix tells the client what domain to append so those names resolve (e.g., fileserver.corp.local).

4) Subnet Mask

The mask tells the client what is local vs what must be routed. Wrong masks create “weird” behavior: ARP storms, intermittent reachability, and traffic going to the wrong place.

Common “Nice-to-Have” Options (Quick Mention)

Many environments deliver extra options. These don’t usually cause “total outage,” but they matter in certain workflows.

  • NTP / Time: time sync for systems, logging, and auth-sensitive workflows
  • PXE / Boot: imaging/OS deployment environments
  • WINS: legacy Windows name resolution (rare, but still seen)

Option Precedence (High-Level Mental Model)

DHCP options can be defined at different “scopes” of control. You don’t need to memorize every rule—use a simple principle:

Rule of thumb:

More specific overrides more general. Device-specific settings beat scope settings, which beat server-wide defaults.

Server-wide

Defaults for everything the server serves (useful when most scopes share settings).

Scope-level

Settings for one subnet/VLAN (most common place to set gateway/DNS for that network).

Reservation / device-specific

Overrides for a specific client (often used with reservations for printers/servers/special devices).

Some platforms also support policies (e.g., “if device matches X, apply options Y”). Treat policies as another layer of specificity—just keep your config predictable and documented.

Why Option Changes Can Feel “Delayed”

Options are delivered with the lease. Many clients won’t pick up new options until they renew, which is why “I changed DNS but some computers still use the old DNS” is a common complaint.

Fastest way to force pickup (Windows):

ipconfig /release
ipconfig /renew

If you’re changing critical options (gateway/DNS), plan for lease timing or explicitly renew clients during maintenance windows.

Troubleshooting: “Got an IP but Nothing Works”

When DORA succeeds but networking still fails, focus on options. Work from the client outward: IP/mask → gateway reachability → DNS resolution.

Wrong default gateway

What you observe: Client can reach local subnet, but can’t reach other networks/internet.

What it usually means: Scope gateway option points to the wrong router or wrong VLAN gateway.

  • What to check next: ipconfig /all gateway value; ping <gateway>

Wrong DNS server(s)

What you observe: IP connectivity works, but websites/internal names don’t resolve.

What it usually means: DNS server option is wrong/unreachable, or DNS traffic is blocked.

  • What to check next: nslookup against the configured DNS servers

Wrong DNS suffix / search domain

What you observe: Short internal names fail (e.g., fileserver), but FQDN works.

What it usually means: DNS suffix/search list isn’t set correctly for that subnet.

  • What to check next: suffix in ipconfig /all; test nslookup fileserver.corp.local

Wrong subnet mask

What you observe: Very inconsistent reachability; things “local” sometimes fail; odd ARP behavior.

What it usually means: Client thinks the local network is larger/smaller than it is, so traffic is misrouted.

  • What to check next: mask in ipconfig /all; confirm scope subnet/mask match the VLAN

Multiple DHCP servers / rogue DHCP handing out wrong options

What you observe: Some devices get correct settings, others get bad gateway/DNS; behavior feels random.

What it usually means: Another DHCP server is responding (router/AP feature, VM, lab device).

  • What to check next: DHCP Server field in ipconfig /all across multiple clients

Split-brain options across scopes (some VLANs right, some wrong)

What you observe: One VLAN works perfectly; another VLAN “has internet issues” despite having IPs.

What it usually means: Options were updated in one scope but not others (gateway/DNS differs).

  • What to check next: compare ipconfig /all across VLANs; validate scope-level options

Option changes not taking (lease timing / caching)

What you observe: You updated options, but some clients keep old DNS/gateway.

What it usually means: Clients update options on renew; they may not renew immediately.

  • What to check next: lease timing; force release/renew; reboot interface if needed

DNS blocked (DHCP works, name resolution doesn’t)

What you observe: Client gets IP/gateway, can ping IPs, but DNS queries time out.

What it usually means: Firewall/security rules block DNS (UDP/TCP 53) to the configured DNS servers.

  • What to check next: try nslookup; test reachability to DNS server IP; check security rules

Hands-on: Verify Options on Windows

1) Inspect what DHCP delivered:

ipconfig /all

Read these fields: Subnet Mask, Default Gateway, DNS Servers, DNS Suffix, and DHCP Server.

2) Sanity check the gateway:

ping <default-gateway-ip>

3) Test DNS directly (internal + external):

nslookup fileserver
nslookup fileserver.corp.local
nslookup google.com

If FQDN works but the short name fails, it’s often a DNS suffix/search domain issue.

Optional (PowerShell):

Resolve-DnsName google.com
Resolve-DnsName fileserver.corp.local

Server-Side Visibility (Brief)

Options typically live at the server, scope, and reservation/device level. When troubleshooting, confirm the expected options at the correct layer for the client’s subnet.

Windows DHCP: look at Server Options and Scope Options (and reservation-specific settings if used).

Next Up: Reservations & Exclusions

Reservations can also deliver device-specific options (useful for printers, scanners, and special systems). Exclusions protect your pool from collisions with static IPs. Next, we’ll cover how to use both without creating conflicts and confusion.

Key Takeaways

  • DHCP options are the “configuration payload” delivered with the lease.
  • The Big 4 (gateway, DNS servers, DNS suffix, mask) explain most “got an IP but broken” cases.
  • More specific overrides more general (reservation/device > scope > server).
  • Option changes can feel delayed because many clients update on lease renewal.
  • Start troubleshooting on the client: validate mask → gateway reachability → DNS resolution.
  • Rogue DHCP is real: confirm which DHCP server issued the lease when behavior is inconsistent.

If DORA works but networking doesn’t, don’t blame “DHCP” generically—blame the options. Get good at reading gateway/DNS/mask quickly and you’ll fix these issues fast.