5 Network Services and Name Resolution
Learn how DHCP and DNS support network access and how to distinguish service failures from connectivity problems.
Separate connectivity from services
A network connection can fail even when the cable, Wi-Fi link, and IP route are working. Separate basic connectivity from network services: supplies configuration, while translates names into addresses. A service may be down, misconfigured, or unreachable over the network; these faults require different checks.
Locate the failure
Begin by comparing what works and what fails, preferably from both an affected device and a known-good device on the same network.
Check the link and IP configuration. Confirm that the adapter is connected and has an address, subnet mask, default gateway, and server. On Windows, use
ipconfig /all.Test by IP address, then by name. If a service is reachable by IP but not by hostname, investigate name resolution. If neither works, investigate the route, firewall, target host, or service.
Test the relevant service directly. A successful ping does not prove that an application service works. ICMP may be blocked, and the application may listen on a different port or interface.
Compare the scope of the problem. One affected client suggests a local adapter or configuration problem. Many clients on one subnet suggest a shared service, relay, VLAN, or gateway issue. Failures across several subnets may point to a central server or upstream path.
A means the needed service is stopped, unhealthy, or not responding correctly. A means packets cannot reach the service or its replies cannot get back. A server process can be running while a firewall, route, incorrect binding, or bad client setting still makes the service unusable.
How assigns configuration
The DORA sequence describes the common IPv4 exchange: the client discovers a server, receives an offer, requests the offered configuration, and receives an acknowledgement. normally uses UDP ports 67 and 68.
A , often called an IP helper, forwards requests when the client and server are on different subnets. Initial address discovery uses broadcasts, so VLAN boundaries, relay configuration, firewalls, and -snooping controls can prevent requests or replies from reaching the client.
Diagnose failures
A missing client address or an automatic link-local address, such as 169.254.x.x on Windows, can indicate that the client did not obtain a usable lease. This alone does not prove that the server is down.
Check the local path first: verify the cable or Wi-Fi association, that the adapter is enabled, that the client is on the correct VLAN, and that it is configured to use . Then confirm that the service is running, serving the correct subnet, has available leases, and is not blocked by a policy, filter, or conflicting static address.
If clients on the server’s subnet succeed but clients on another subnet fail, verify the relay/IP-helper configuration and return path. Also consider whether VLAN boundaries, relay configuration, firewalls, or -snooping controls are preventing requests or replies from reaching the client.
An existing client with a valid lease may continue to communicate for a time while is unavailable. Trouble may therefore appear first when a device joins, reconnects, or renews its lease rather than as an immediate outage for every connected client. Check server logs and available-lease counts to help confirm the suspected cause.
How resolves names
answers queries about names, including requests for host addresses. A client’s resolver typically asks a configured server. That server may answer from authoritative records or cache, or obtain an answer through other servers. queries commonly use UDP port 53, and TCP port 53 is also used.
Diagnose failures
First verify that the client has a valid address and gateway, and that it is using the intended -server address. can supply an incorrect server even when it successfully assigns an IP address.
On Windows, nslookup example.com or Resolve-DnsName example.com tests resolution. A timeout suggests there was no usable response; possible causes include an unreachable server, a stopped service, or a firewall or path problem. A “name does not exist” response indicates that the queried name has no matching data at the server queried. Verify the spelling, domain, and record.
Compare access by name with access by IP. If the destination’s IP address works but its hostname does not, focus on configuration, records, caching, or traffic. If both fail, do not assume is the cause; test routing and the destination service too.
Check servers, traffic, and cached results
When many clients fail, verify that the service is running, listening on the expected interface, and has the required zone records or working forwarders. Determine whether the failure affects internal names, external names, or both.
Confirm that the client is querying the intended server and that traffic is permitted across the path. If needed, capture traffic: a query with no reply points toward the server or path; no query leaving the client points toward client configuration or local software.
results may be cached, and local host-file entries can provide an address without a query. After correcting a record or client setting, test again while accounting for caches and record time-to-live. On Windows, ipconfig /flushdns clears the client .
Apply the checks in order
Suppose a user reports that the internet is down. The computer has a valid address and can reach the default gateway. A known external IP responds, but a website name does not. This pattern points toward rather than a general link failure. Check the configured server, query it directly, and determine whether it answers other clients. If the server cannot be reached, investigate the route or firewall; if it is reachable but does not resolve names, investigate its service, records, or forwarding configuration.
By contrast, if the computer has no usable address and cannot reach its gateway, first investigate the client link and exchange. Testing before the client has working IP configuration is unlikely to identify the underlying fault.
Combine the diagnostic clues
provides IP configuration, and its failures often affect new or renewing clients. Check the client lease, server scope and service, and relay path across subnets.
resolves names to records and addresses. Compare access by name with access by IP, then test the configured resolver and its server-side data. Connectivity faults prevent traffic from reaching a service or returning; service faults involve the service or its configuration. A service can be running yet unreachable.
Compare affected and working clients, test each layer in order, and use logs or packet captures to distinguish a missing service response from a packet that never reaches the service.