DHCP, DNS, NTP, and IP Addressing Issues
Key Takeaways
- An IPv4 address in 169.254.0.0/16 (APIPA) means the client failed to get a DHCP lease and reached the server's link only.
- DHCP troubleshooting walks scope/pool exhaustion, exclusions, reservations, options 3/6/15/42/66, relay (helper) reachability, and rogue servers.
- Resolution that works by IP but fails by name isolates the fault to DNS; if neither works, suspect the transport or routing path instead.
- Clock skew beyond roughly 5 minutes breaks Kerberos and certificate validation even when ping, DHCP, and DNS all succeed.
- A structured flow verifies client config, service health, path reachability, and recent change before touching infrastructure.
DHCP, DNS, NTP, and IP Addressing
Network services generate most "the network is down" tickets even when the physical layer is healthy. A user can have a clean cable, a strong Wi-Fi signal, and a working switch port yet still fail because the client has no valid address, the wrong gateway, names that do not resolve, or a clock that is badly skewed. Network+ N10-009 Domain 5 (24% of the exam) expects you to separate these service failures from physical and routing failures using observable clues. Remember the exam delivers up to 90 questions in 90 minutes with a 720/900 passing score, so you must read scenarios fast and match the symptom to the right layer.
IP Addressing Clues
Automatic Private IP Addressing (APIPA) uses the 169.254.0.0/16 range and is assigned only when a Dynamic Host Configuration Protocol (DHCP) client gets no answer. APIPA hosts can reach each other on the local link but never a real gateway.
| Symptom | Likely issue |
|---|---|
| 169.254.x.x address on an IPv4 client | DHCP request unanswered; APIPA self-assignment |
| Duplicate IP address warning | Static conflict, stale reservation, or rogue DHCP |
| Reaches local subnet but not remote networks | Wrong, missing, or unreachable default gateway |
| Reaches gateway but not one specific subnet | Route, ACL, firewall, or remote service issue |
| Works by IP but not by hostname | DNS resolution failure |
| Intermittent after a move | Wrong VLAN, leftover static IP, or scope mismatch |
Always read the live client configuration first: IP address, prefix length or subnet mask, default gateway, DNS servers, lease source, and lease expiration. On Windows use ipconfig /all; on Linux/macOS use ip addr and cat /etc/resolv.conf. A /24 host wrongly given a /25 mask, for example, will silently treat half its own subnet as remote.
DHCP Troubleshooting
A valid lease normally delivers an IP, mask, default gateway (option 3), DNS servers (option 6), DNS suffix (option 15), and may add NTP (option 42), TFTP/PXE (option 66), or voice-VLAN settings. Clients reach the server through the four-step DORA exchange: Discover, Offer, Request, Acknowledge.
| DHCP component | Problem clue |
|---|---|
| Scope / pool | Addresses exhausted, or scope on wrong subnet |
| Exclusion | A static device's address handed to a client |
| Reservation | Device receives a different address than expected |
| Option | Has an address but wrong gateway, DNS, or voice VLAN |
| Relay / IP helper | Remote-VLAN clients cannot reach the central server |
| Rogue DHCP server | Clients get unexpected gateway/DNS, often APIPA-adjacent |
Worked scenario: clients on VLAN 30 fall back to APIPA while VLANs 10 and 20 lease fine. Because DHCP Discover is a broadcast that does not cross a router, the VLAN 30 gateway must carry an IP helper-address pointing at the server. A missing or mistyped helper is the classic cause. If every VLAN fails, suspect the DHCP service itself, an upstream firewall, or scope exhaustion. Shorten lease times temporarily on a saturated guest scope to recycle addresses faster.
- One VLAN fails, others work: relay/helper, trunk, ACL, or that scope.
- All VLANs fail: server health, service stopped, or full database.
- Duplicate-address alerts after imaging: a cloned static or an unauthorized server.
DNS and NTP Troubleshooting
The Domain Name System (DNS) maps names to records. Test the IP path separately: if an app works by IP but not by name, DNS is the prime suspect; if neither works, fix transport first. Query deliberately with nslookup or dig against the configured resolver, then an authoritative server.
| DNS clue | Likely issue |
|---|---|
| Wrong IP returned | Stale A/AAAA record, wrong zone, or split-DNS mismatch |
| Internal name fails off VPN | DNS suffix, VPN-assigned resolver, or split-tunnel policy |
| Some users see the old IP | Cache or Time To Live (TTL) not yet expired |
| Reverse lookup fails | Missing or stale PTR record |
| External users cannot resolve | Public zone, delegation, or registrar problem |
Network Time Protocol (NTP) keeps clocks aligned, and lower stratum numbers are closer to the reference clock. Skew beyond about five minutes breaks Kerberos tickets and TLS certificate validation while ping and DNS still succeed.
| Time symptom | Possible impact |
|---|---|
| Workstation clock far off | Kerberos or certificate validation failure |
| Logs out of order | Unreliable incident timeline |
| NTP blocked by an ACL (UDP 123) | Devices drift over time |
| Wrong time zone | Reports and maintenance windows look wrong |
Practical Troubleshooting Flow
- Confirm address, mask, gateway, DNS, and lease source on the client.
- Ping the default gateway, then a known IP, then a hostname.
- Verify DHCP scope, options, helper, and free addresses.
- Query DNS from the same resolver the client uses; compare inside vs outside for split-horizon.
- Check clock skew and UDP 123 reachability for auth or log issues.
Exam Focus
Match clue to service: APIPA points to DHCP; wrong gateway points to addressing or a DHCP option; works-by-IP-not-name points to DNS; certificate or Kerberos errors with skewed clocks point to NTP.
A workstation has an IPv4 address in the 169.254.0.0/16 range and cannot reach the default gateway. What is the most likely issue?
Users can reach an internal web application by IP address but not by hostname. Which service should be checked first?
Match each clue to the likely service or configuration area.
Match each item on the left with the correct item on the right