What Happens When DHCP or DNS Fails? Common Errors and Fixes

 These two failures look nothing alike, and telling them apart takes about ten seconds.

Open a command prompt and run two commands. First ping 1.1.1.1, an IP address that requires no name resolution. Then ping google.com, which does.

• Both fail, and the machine has no sensible address. DHCP problem.
• The IP address responds, the name does not. DNS problem.
• Both work. Your fault is somewhere else entirely.

That test costs nothing and eliminates the most common diagnostic mistake in networking, which is investigating DHCP and DNS errors as though they were the same category of fault. They are not, and the fixes have nothing in common.

When DHCP Fails

The signature is unmistakable once you know it. Run ipconfig /all and look at the IPv4 address.

An address beginning 169.254 means the client asked for configuration and nothing answered. Windows assigns this automatically as a placeholder — the mechanism is called automatic private addressing. The machine can talk to other devices that also failed to get an address, and to nothing else.

What causes it:

• The DHCP server is down, or its service has stopped while the machine itself is running.
• The scope is exhausted. Every available address is leased, and there is nothing left to give.
• No relay agent on this segment. The client is in a VLAN whose gateway has no helper address configured, so the broadcast never reaches the server.
• The port is in the wrong VLAN, placing the client on a network with no DHCP service.
• A firewall is blocking UDP ports 67 and 68 somewhere along the path.
• A rogue DHCP server has responded first with unusable configuration.
• Port security or 802.1X is blocking the port before any traffic passes.

Scope Exhaustion Deserves Its Own Explanation

This one surprises people because the arithmetic seems fine. A /24 subnet has 254 usable addresses and the office has 80 staff, so how can it run out?

Because devices are not people. Each person may bring a laptop, a phone, and a tablet. Visitors connect. Devices that move between wireless access points can consume multiple leases. And crucially, leases persist after a device disconnects — a phone that joined for ten minutes holds its address for the full lease duration, often eight days.

The symptoms build gradually, then arrive all at once. Some devices connect fine, others fail, and which ones varies by who arrived first that morning.

The fixes, in order of how quickly they help:

1. Shorten the lease duration. Going from eight days to eight hours multiplies your effective capacity enormously for transient devices.
2. Separate guest devices into their own scope, so visitors cannot consume staff addressing.
3. Enable conflict detection so the server does not reissue addresses already in use.
4. Expand the subnet, which is the proper fix and the most disruptive.
5. Review reservations and exclusions, which sometimes consume more of the range than anyone remembers.

The Rogue DHCP Server

A particularly confusing failure worth recognising, because the symptoms are chaotic rather than clean.

Someone plugs a home router into a wall socket to get extra ports. That router has DHCP enabled by default. It now competes with your legitimate server, and clients accept whichever offer arrives first.

The result is that some devices receive correct configuration and others receive an address in 192.168.0.0/24 with a gateway pointing at a router that has no route anywhere. Which devices are affected changes every time anything reconnects.

Diagnosing it: check the DHCP server address shown in ipconfig /all on an affected machine. If it is not your server, you have found the problem. Its MAC address, traced through switch MAC address tables, leads you to the physical port.

Preventing it: DHCP snooping on your switches. This feature designates ports as trusted or untrusted, and DHCP server responses arriving on untrusted ports are simply dropped. Only the uplink toward your real server is trusted. It is straightforward to configure and it eliminates this entire category of problem permanently.

When DNS Fails

Here the machine has a perfectly valid address, connectivity works, and nothing usable happens — because almost every action a user takes begins with a name lookup.

The characteristic symptoms:

• Web pages fail while a ping to a numeric address succeeds.
• Some sites load and others do not, depending on what is cached.
• Email clients cannot reach servers.
• Network drives fail to map.
• In a Windows domain, logins fail or Group Policy does not apply.

Common causes:

• The configured DNS server is down or unreachable.
• The client is pointing at the wrong resolver, frequently a public one on a domain-joined machine.
• Forwarders are misconfigured, so internal names resolve and external ones do not.
• A stale cached entry, either on the client or on the resolver.
• A hosts file entry overriding the correct answer.
• Zone records deleted by scavenging set too aggressively.
• DNS service running but its zones failed to load, which produces refusal rather than silence.

What the Windows Errors Actually Mean

Windows produces several distinct messages, and each points somewhere specific:

• "DNS server not responding." The client reached no resolver at all. Check whether the configured server addresses are correct and reachable.
• "The DNS server isn't responding" after the troubleshooter runs. Same condition; the troubleshooter rarely fixes it.
• "Server DNS address could not be found." The resolver answered, and the answer was that the name does not exist. This is a records problem, not a connectivity problem — an important distinction.
• "Your computer appears to be correctly configured, but the device or resource is not responding." Resolution worked, and the target did not answer. Not a DNS fault at all.
• "No such host is known." The name did not resolve. Check spelling, then check whether the record exists.

That third and fourth pair are the ones most often misread. If the resolver is answering, DNS is working — it is telling you something you do not want to hear.

Partial DNS Failure Is the Worst Kind

Complete failures are easy. Partial ones consume days.

The pattern: internal names resolve and external ones do not, or vice versa. Some users are affected and others are not. It works from one office and fails from another.

What produces this:

• One of two DNS servers is broken. Clients using the healthy one work; clients using the other fail, apparently at random.
• Forwarders are failing while local zones remain intact, so internal works and internet does not.
• Split-horizon configuration where internal and external views have diverged.
• Caching masking the fault, so the problem only appears as entries expire.
• One zone failed to load while the rest of the service runs normally.

The tool for this is nslookup used deliberately. Query each resolver explicitly — nslookup example.com 10.0.0.10 — rather than relying on whichever one the client happens to pick. Comparing answers from each server in turn finds the broken one in minutes.

Fix Sequence for DHCP Problems

1. Confirm the symptom with ipconfig /all and check for a 169.254 address.
2. Release and renew: ipconfig /release then ipconfig /renew, and watch what happens.
3. Test another device on the same port and VLAN to separate client from network.
4. Check the server — is the service running, is the scope active, are addresses available?
5. Check the relay configuration on the client's gateway.
6. Look for a rogue server in the client's reported DHCP server address.
7. Assign a static address temporarily to confirm the rest of the path works.

Fix Sequence for DNS Problems

1. Confirm it is DNS by pinging an IP address and a name.
2. Check which resolvers are configured in ipconfig /all and whether they are correct for this machine.
3. Flush the cache: ipconfig /flushdns.
4. Query each server explicitly with nslookup to find which one is failing.
5. Check the hosts file at C:\Windows\System32\drivers\etc\hosts.
6. Test a different resolver temporarily — but remember this breaks domain functionality on a domain member.
7. On the server, verify zones loaded and check whether the record in question exists.

Designing So Failure Hurts Less

Both services are single points of failure by default, and both are straightforward to make resilient:

• Run two DNS servers and distribute both addresses to clients.
• Run DHCP in a failover or split-scope arrangement, so one server failing does not stop address assignment.
• Set lease durations long enough that a DHCP outage during working hours goes unnoticed. Clients keep working on existing leases.
• Monitor both services actively, including scope utilisation, which is the early warning for exhaustion.
• Enable DHCP snooping everywhere.
• Document the addressing scheme, because reconstructing it during an outage is miserable.

The long lease point is worth dwelling on. A network with eight-day leases can survive a DHCP server failure for days without a single user noticing, provided nobody reboots anything unusual. That is resilience obtained for free, purely through a configuration choice — and it is the kind of decision that quietly separates well-run networks from ones that are merely working.