A device can run normally for days, then lose its leased address if renewal and rebinding fail and the lease expires. Your laptop might reconnect with a different IP address, or a printer might disappear from a shortcut that still uses its old one. A local DNS service might get the blame when names stop resolving as expected. These symptoms can be related. They aren't the same problem.
Dynamic Host Configuration Protocol, or DHCP, gives a network client its address and other settings for a limited period. DNS turns a name into an address; an application then has to reach the service at that address. If a lease doesn't renew, changing DNS first can hide useful evidence and give you a second variable to track. The checks below follow a narrow order for a network you own or are authorized to administer.
A record of the symptoms before a restart
Start with the affected device. Write down the time, the network name or wired port it used, its current IP address if one is shown, and the address or hostname another service expected. Note whether the device has no network connection, can't reach one local service, or just appears under a new address.
Each case raises a different question. Without an address, a device can't use ordinary IPv4 network services. With a new address, it may have completed DHCP successfully, while an old shortcut, firewall rule, or local record still points somewhere else. If it can reach an address but not a hostname, you may have a DNS problem even though the lease is fine. Don't lump all of these together as “the network is broken.”
Avoid deleting leases, rebooting the router, and changing a DNS setting in one attempt. A restart can clear a temporary condition, but it can also erase volatile logs and other timing evidence. If you need to reboot to keep things running, write down what you observed first and treat the state afterward as a new observation.
Separate checks for DHCP, DNS, and the application
DHCP normally supplies more than an IP address. It can also provide a subnet mask, default gateway, DNS server addresses, and a lease duration. RFC 2131, the DHCP protocol specification, describes the messages clients and servers use to obtain and renew a lease. The related option definitions, including DNS server information, are in RFC 2132.
That gives you a useful order for checking things:
- Does the client have an address and network settings from the expected network?
- Does the DHCP server show a current lease or a recent lease attempt for that client?
- If the client has an address, can it reach a known local address on the same permitted network?
- Once you've checked those, does the intended name resolve to the expected current address?
- Is the named service actually listening and authorized to accept the connection?
Menu labels vary across routers, firewalls, and dedicated DHCP servers. Look for a page or log called DHCP leases, clients, address assignments, or DHCP events. A router's “known devices” display may mix old and current information. Use the lease state, expiration time, or event timestamp instead when one is available.
The network path between client and server
Before you treat a missing renewal as a server failure, compare the client's network with the DHCP server that's supposed to serve it. Guest Wi-Fi, an IoT VLAN, a mesh-node backhaul, and a downstream router can be separate broadcast domains. Broadcast discovery and rebinding need either a server in the same broadcast domain or a configured DHCP relay. Renewal normally uses unicast and requires a working path to the original server; ordinary routing can carry it across subnets without a DHCP relay. The main router's lease table isn't necessarily authoritative for a device behind a second router.
Find the device's current network in its usual administration screen or network status page. Then check the relevant router, access point, or DHCP server instead of scanning broad ranges or probing networks you don't administer. For a device on a managed work network, ask the responsible administrator for the lease and event information.
Check for more than one DHCP service, too. A spare router connected as a router instead of an access point can hand out its own settings. So can a lab appliance or an incorrectly configured virtual-network service. With two servers, the symptoms can look intermittent: one client gets a usable lease from one server, while another gets different DNS or gateway settings from the other. Don't disable a suspected service until you understand its role and which segment it's connected to. You could disconnect other devices.
Client identity and lease state
Find the relevant lease and compare the current IP address, client identifier or MAC address, hostname if shown, start or renewal time, and expiration time. A MAC address helps you match an interface, but it isn't always a permanent device identity. Phones and laptops can use private Wi-Fi addresses. A computer with multiple interfaces has different addresses for Ethernet and Wi-Fi, so a reservation tied to the wrong interface may never match the client requesting a lease.
An expired lease isn't automatically an error. A device that was asleep, powered off, or away from Wi-Fi may return later and get another valid address. DHCP uses time-limited bindings; it doesn't give a device permanent ownership of an address. What matters is whether an expected address changed after a normal new lease or the client repeatedly failed to get any usable configuration.
If the DHCP server has logs, focus on the smallest relevant time interval. Look for the client's request, any offer or acknowledgment, and an error message if there is one. A log entry tells you about that event. It doesn't prove the device's application works. And a missing entry may mean you're checking the wrong DHCP authority or network segment, rather than that the client did nothing.
One reversible test at a time
Once you've identified the correct DHCP authority, choose the least disruptive test that suits the device and what it's doing. On a noncritical client, reconnecting to the same authorized network through a documented procedure can cause it to request configuration again. For a server, NAS, or device running a backup, wait for a maintenance window and follow the vendor-supported network procedure. Don't keep renewing, rebooting, or factory-resetting a device just to make the lease table update.
Run one test, then compare the result with your earlier notes:
- Did the device get an address in the expected subnet?
- Does the lease record match the interface that actually connected?
- Are the gateway and DNS server details the ones intended for this network?
- Is an old IP address or hostname still in a client shortcut, integration, or access rule?
- Is the remaining failure DNS resolution, or does resolution succeed and leave a service-level problem?
If a device really needs a predictable address, a DHCP reservation can be appropriate once you've confirmed the right DHCP server and network interface. A reservation tells that server which address to offer that client in the future. It won't generally fix a missing route, weak Wi-Fi, a stopped DNS service, or an unavailable application. Keep a short note beside each reservation naming the device and interface so you can audit a later change.
Conclusions supported by the evidence
A useful conclusion is specific: “the client received a new lease from the expected server,” “the expected hostname still referred to the old address,” or “the client did not appear in the DHCP server for its VLAN during this interval.” Each points to the next check without claiming the whole network is healthy.
If you need a longer record for comparison, DeviceShelf can be one source of local observations for networks you administer. Compare its device observations with the DHCP authority and the affected service. A device record alone doesn't prove a DHCP renewal, DNS result, or application response.
Check whether the client has a valid configuration before changing name resolution. By checking DHCP, DNS, and the application separately, you make a recurrence easier to explain and avoid turning one unclear lease event into several configuration changes.