A user says, “The network is down.” A useful troubleshooting question asks for more detail. Does the device have an address? Can it reach a known destination by IP? Does the problem appear only when a hostname is used? Those observations help separate configuration, connectivity and name resolution.
DHCP and DNS are related services, but their jobs differ. DHCP can supply host configuration, including an address and DNS-server information. DNS resolves names using its records. Cisco documents their interaction in its DHCP introduction. The following lab situations are original exercises for CCNA study.
Situation one: no expected address
A newly connected client has not obtained the expected address for its subnet. Begin by inspecting the actual interface configuration and link state. Then investigate the DHCP exchange, server availability, address pool and any required relay path.
Changing a DNS record does not explain why the client failed to obtain its expected configuration. DNS might become relevant later, but the first observed failure concerns addressing.
Do not assume every device must use DHCP. A statically configured host requires a different initial check. The stem must establish how the host is supposed to receive its settings before “restart DHCP” becomes a reasonable response.
Situation two: IP connectivity works, names fail
A client reaches a known internal server by IP, but a name lookup for that server fails. In a simplified lab, this directs attention toward name resolution: the configured DNS server, reachability of that server and the relevant record.
It does not prove that every part of the network is healthy. It gives you a narrower hypothesis to test. Check the name lookup directly instead of immediately changing the default gateway or replacing the cable.
Also avoid using an arbitrary website’s numeric address as definitive proof. HTTPS certificates, virtual hosting and application configuration can make that comparison misleading. Use a controlled test target whose expected behavior you know.
Situation three: local access works, remote access fails
A host communicates with devices on its own subnet but cannot reach a known remote network. Check the mask, default gateway and routed path. An incorrect mask can change which destinations the host considers local, so a correct-looking address alone is not enough.
For each situation, record the observation, your hypothesis and one test that could disprove it. The CCNA IP services practice questions can help you practice that sequence when an exam item offers several plausible checks.
Build evidence before changing settings
In a lab, save the original configuration before making a correction. Change one relevant variable, repeat the same test and note the result. If several settings change together, a successful connection may leave you unsure which fault you fixed.
Use the CCNA IP services study guide to connect DHCP and DNS with subnetting, gateway behavior and routing. The goal is to choose a check because it addresses the observed symptom, then update the hypothesis when the evidence changes.