DHCP vs DNS: What Breaks When Each One Fails

DHCP and DNS are easy to mix up because both are usually provided by the same home router. They solve different problems. DHCP answers the question, 'What network settings should this device use?' DNS answers the question, 'What IP address matches this name?'

A device can have working DHCP and broken DNS, or working DNS settings but no useful DHCP lease. Separating those failures makes troubleshooting much faster.

Quick answer: If the device has no usable IP address, start with DHCP. If the device has an IP address and gateway but names will not load, start with DNS.

Interactive quick reference

DHCP vs DNS: What Breaks When Each One Fails

Use this card as the simple mental model, then use the article sections below for the operational details.

Start simpleVerify the result

1. Join the network

A client connects to Wi-Fi or Ethernet and asks for network settings.

2. Get a lease

DHCP provides an IP address, subnet mask, default gateway, DNS server, and lease time.

3. Resolve names

DNS translates names such as techgeeks.org into IP addresses.

4. Connect

The client uses the resolved IP address and the gateway to reach the destination.

Start Here: The Beginner Foundation

DHCP and DNS solve different setup problems. DHCP gives a client the network configuration it needs for a period of time, commonly an IPv4 address, prefix or subnet mask, default gateway, and DNS resolver addresses. DNS is a distributed naming system: a resolver asks DNS servers for records such as the IPv4 or IPv6 address associated with a name. A home router often provides a DHCP server and forwards or caches DNS queries, but putting both services in one box does not make them the same service.

On a typical IPv4 LAN, a new client can begin without a usable address and exchange DHCP messages to discover a server, request an offered address, and receive an acknowledgment. Because the first messages are broadcasts, a routed network normally needs a DHCP relay to reach a server on another subnet. IPv6 setup is different: router advertisements provide on-link and default-router information, while SLAAC and optionally DHCPv6 provide addresses or other settings. In particular, DHCPv6 is not the source of the IPv6 default route.

Troubleshooting starts by separating configuration from naming. If the client lacks an expected address, prefix, gateway, or lease, investigate link state, VLAN placement, the DHCP scope, and any relay. If those settings are sound, test a destination by numeric address and then query the configured DNS resolver for a known name. A successful numeric connection with failed name resolution points toward DNS, but a failed ping alone does not prove either service is broken because routing, firewall policy, or the target can affect the result.

The Fast Comparison

Service	Primary job	Common symptom	First test
DHCP	Assigns network configuration	169.254.x.x address, no gateway, wrong VLAN, duplicate address	Check ipconfig /all or the router lease table
DNS	Resolves names to addresses	Can ping an IP but websites by name fail	Run nslookup or dig against the configured resolver

Advanced Notes and Design Boundaries

Address assignment and name resolution often share the same router appliance, but they remain separate protocols with different caches, relays, options, logs, ports, and IPv4 or IPv6 failure modes.

• DHCPv4 clients and servers normally use UDP ports 68 and 67; a relay populates relay information such as giaddr so the server can select the scope for the client's subnet.
• When DHCPv4 options T1 and T2 are absent, RFC 2131 defines renewal and rebinding defaults of 0.5 and 0.875 of the lease duration, respectively; clients can therefore keep working while a server is briefly unavailable.
• DHCP option 6 identifies DNS recursive resolver addresses, but those resolvers are not necessarily authoritative for the names a client asks about and may forward, recurse, filter, or cache answers.
• DNS answers are typed and cached: A and AAAA map names to IPv4 and IPv6 addresses, CNAME expresses an alias, and negative responses can also be cached according to DNS rules.
• DHCPv6 can provide addresses, delegated prefixes, and configuration options, but IPv6 neighbor discovery router advertisements establish default-router information; do not diagnose a missing IPv6 default route as a DHCPv6 option failure.

Troubleshooting Workflow

Capture the client's address, prefix, gateway, DNS servers, lease timestamps, and failing query before renewing or flushing anything. Those transient values often identify whether the break is DHCP, DNS, routing, or policy.

1. Confirm the physical or wireless link, expected SSID, and switch access VLAN before changing any DHCP or DNS setting.
2. Record the client's IPv4 and IPv6 addresses, prefix lengths or mask, default routes, DNS resolver addresses, lease times, and interface used.
3. Compare that configuration with the intended subnet and DHCP scope; for IPv4, renew the lease while capturing the result rather than assigning a speculative static address.
4. Test the local gateway and one known reachable numeric address using the correct address family, then inspect routes and firewall policy if either test fails.
5. Query a known name directly against each configured resolver with nslookup, dig, or Resolve-DnsName, and compare the response code, record type, and returned address.
6. If the fault remains, inspect DHCP leases and relay counters plus DNS server logs or packet captures, correlating timestamps, client identifiers, VLAN, and source subnet.

Evidence and Fault-Isolation Method

Evidence status: Protocol behavior is documentation-backed by the current RFC Editor records for DHCPv4, DHCPv6, DNS, and IPv6 Neighbor Discovery, with operational corroboration from ISC material reviewed July 15, 2026. TechGeeks did not reproduce a DHCP or DNS outage, inspect the reader's packets, or benchmark a public resolver for this draft. A successful ping or cached lookup proves only that one path worked at that moment.

• Planned observation: before renewing or flushing, record interface state, IPv4 and IPv6 addresses and prefixes, default routes, DHCP server and lease times, configured resolvers, search suffixes, VPN state, and one exact failing name.
• Isolate: test the local gateway, a permitted known numeric destination, and direct queries to each configured resolver; then correlate client output with authorized packet captures, DHCP leases, DNS logs, relay counters, firewall events, and authoritative records.
• Accept: the client receives the intended network parameters, renews through the correct server or relay, resolves uncached test names through the expected path, and reaches the application without bypassing required filtering or split-horizon policy.

Security, DNS Privacy, Authorization, and Rollback

Rogue DHCP can redirect gateways and resolvers, while malicious or compromised DNS can redirect names; use trusted network controls, authenticated administration, and monitoring rather than treating either service as harmless plumbing. DNS queries reveal browsing and service use, and encrypted DNS changes who can observe them rather than eliminating trust. Browser, VPN, operating-system, and router resolver settings may conflict with family or enterprise filtering. Capture only traffic you are authorized to inspect and protect hostnames, client identifiers, and packet files. Export scopes, reservations, options, zones, forwarding rules, and TTLs before changes. If a replacement service fails, restore the previous configuration, avoid overlapping DHCP servers, account for cached DNS answers and existing leases, and retest from a clean client state.

What a Passing Network Test Does Not Prove

• DHCP does not translate names; it supplies network configuration and may tell a client which DNS resolvers to use.
• Changing to a public DNS resolver cannot repair a missing link, wrong VLAN, invalid client address, or absent default route.
• An address already present on a client does not prove DHCP is currently healthy; the address may be static, self-assigned, or retained from an earlier lease.
• DHCPv6 does not provide the IPv6 default gateway; hosts learn default routers from IPv6 router advertisements.

Real-World Use Cases

• Use DHCP reservations for infrastructure devices that need predictable addresses.
• Use separate DHCP scopes for separate VLANs or subnets.
• Use DNS names for services instead of memorizing IP addresses.
• Document which device provides DHCP and which resolver clients receive.

Failure Patterns to Recognize

• Wrong DHCP scope on the wrong VLAN.
• Missing DHCP relay between VLANs.
• Router hands out ISP DNS when you expected local filtering.
• DNS cache points to an old address after a service moves.

Common Mistakes

• Changing DNS when the client does not even have a gateway.
• Blaming DHCP because one website will not load.
• Using static IP addresses without documenting them.
• Running multiple DHCP servers on the same LAN by accident.

Quick Checklist

• Check IP address, subnet mask, gateway, and DNS server.
• Ping the gateway.
• Ping a public IP such as your resolver.
• Resolve a known domain name.
• Check DHCP leases and DNS logs if available.

Common Questions

Why can I reach an IP address but not a website name?

The client may have working addressing and routing but no usable DNS path. Verify which resolver the client is actually using, query that resolver directly, and note whether the failure is a timeout, SERVFAIL, or NXDOMAIN. Also test the returned A and AAAA addresses because a correct DNS answer can still lead to an unreachable service, and cached answers can differ from current authoritative data.

What does a 169.254.x.x IPv4 address mean?

It is in the IPv4 link-local block commonly used for self-configuration when a host has no suitable configured address. It is a strong clue that the expected DHCP exchange did not complete, but it does not identify the cause. Check link state, Wi-Fi authentication, access VLAN, DHCP scope capacity, relay configuration, and server reachability before blaming the client.

Can DHCP and DNS run on different devices?

Yes. A router, server, firewall, or dedicated appliance can provide DHCP, while entirely different recursive and authoritative DNS systems provide naming. The DHCP scope only needs to advertise resolver addresses appropriate for that client network. Document ownership of each service because restarting the router may affect one, both, or neither in a more advanced design.

Should infrastructure use static addresses or DHCP reservations?

Either can be valid. A reservation centralizes the address assignment while retaining DHCP-delivered gateway, DNS, and lease information. A manually configured address avoids dependence on DHCP for that interface but requires disciplined exclusion from the dynamic pool and accurate local settings. Choose based on recovery requirements and management practice, then document the address, owner, VLAN, and method.

Useful Gear And Buyer Notes

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

Do not buy a replacement router because one lookup fails. First confirm link state, lease behavior, numeric-IP reachability, resolver responses, and whether a VPN, browser secure-DNS setting, filtering service, or split-horizon zone changes the path.

• Amazon search: basic network cable tester
• Amazon search: small managed switch

Related TechGeeks Reading

• Make DNS Keep Working When the Internet Is Down develops the resilience side of local name service.
• Fix DNS Once: Router vs PC vs Browser maps conflicting resolver controls across the stack.
• Homelab DNS Guide covers local names, filtering, and reliable resolver design.

References

• RFC 2131: Dynamic Host Configuration Protocol
• RFC 1034: Domain Names Concepts and Facilities
• RFC Editor: RFC 2131, Dynamic Host Configuration Protocol
• RFC Editor: RFC 8415, Dynamic Host Configuration Protocol for IPv6
• RFC Editor: RFC 1034, Domain Names - Concepts and Facilities
• RFC Editor: RFC 1035, Domain Names - Implementation and Specification
• RFC Editor: RFC 4861, Neighbor Discovery for IPv6

• Internet Systems Consortium: Kea DHCP
• ISC Kea: DHCP-DDNS Component

Fact check completed July 15, 2026. On publication day, recheck the cited RFC status, current resolver and DHCP-server documentation, and any operating-system behavior mentioned for encrypted DNS, IPv6 router advertisements, DHCPv6, lease renewal, or cache controls.