A host can have a working cable and still fail because it received no address, the wrong default gateway, or the wrong Domain Name System (DNS) answer. Those are different faults. This Quick Review focuses on choosing the next useful check instead of making several configuration changes at once.
The CCNA 200-301 v2.0 blueprint addresses Dynamic Host Configuration Protocol version 4 (DHCPv4) client, server, and relay troubleshooting in objective 1.7 and DNS record diagnosis in objective 4.4. The full domain guides teach the broader configuration. Here we compare symptoms, commands, and conclusions.
Fast rule: First ask whether the client received usable IP settings. If it did, distinguish IP reachability from name resolution. A successful ping to an IP address does not prove DNS works; a successful DNS lookup does not prove the application is reachable.
1. Start with the failing step
- Check the client: Is the link up? Which IPv4 address, subnet mask, default gateway, and DNS server did it actually receive?
- Prove the local path: Is the switchport in the right virtual local area network (VLAN), and is the Layer 3 gateway interface usable?
- If addressing failed: Follow the DHCP request through client, relay, path, pool, and reply. Do not assume the server is at fault.
- If addressing succeeded: Test the gateway and a reachable service by IP before investigating names.
- If only names fail: Query the intended DNS resolver for the specific record type and compare its answer with the required service.
- If DNS returns the right address: Move to access control lists (ACLs), routes, transport ports, the application, and the return path.
For example, a Windows client showing 169.254.18.22 suggests it did not obtain an ordinary DHCPv4 lease and assigned itself a link-local address. That narrows the search; it does not identify whether the cause is a bad VLAN, failed relay, blocked DHCP reply, or unavailable server.
2. DHCP client, relay, and server solve different problems
The usual initial DHCPv4 exchange follows Discover, Offer, Request, Acknowledgment (DORA). A new client commonly starts with a local broadcast because it does not yet have a usable IPv4 configuration. A router does not ordinarily carry that broadcast into another subnet.
- Client: Requests settings and later uses the assigned address, gateway, DNS, and lease information. An IOS interface can be a DHCP client using
ip address dhcp. - Relay: Receives the client broadcast on its client-facing Layer 3 interface and forwards it to a configured remote DHCP server. Cisco IOS uses
ip helper-addressfor this function. - Server: Chooses the appropriate scope or pool, checks availability, and supplies options such as the default gateway and DNS resolver addresses.
The relay's gateway address field helps a remote server determine the client's subnet. If the server has no matching available pool or cannot return a reply, a correct helper address alone will not produce a usable lease.
3. Relay evidence: inspect the client-facing interface
Consider a client VLAN using 192.0.2.0/24, with the gateway at 192.0.2.1 and a DHCP server on a different subnet at 198.51.100.10. A typical relay configuration is:
interface Vlan20
ip address 192.0.2.1 255.255.255.0
ip helper-address 198.51.100.10
The helper belongs on the Layer 3 interface where the client broadcast arrives, not simply whichever interface points toward the server.
show ip interface brief
show running-config interface Vlan20
show ip interface Vlan20
show ip route 198.51.100.10
Read those checks in order:
show ip interface briefconfirms the gateway interface's address and state.show running-config interface Vlan20shows whether the helper is configured on the correct interface.show ip interface Vlan20can confirm IP interface details, including helper addresses on supported IOS platforms.show ip route 198.51.100.10checks the route toward the DHCP server. Server reachability and the return path must also work.
If only VLAN 20 clients fail while a nearby VLAN receives leases, inspect VLAN 20's gateway, helper, policies, and matching server pool before resetting the server. A shared DHCP service can be healthy for one subnet and broken for another.
4. Server evidence: pool, bindings, conflicts, and options
Run the following commands on a Cisco device acting as a DHCP server. They are not proof of remote-server activity when entered on a relay-only router.
show ip dhcp pool
show ip dhcp binding
show ip dhcp conflict
show running-config | section ip dhcp
show ip dhcp pool: Is there a matching network pool? Are addresses still available?show ip dhcp binding: Which leases has this IOS DHCP server issued?show ip dhcp conflict: Which addresses are withheld because conflicts were detected?show running-config | section ip dhcp: Does the configured pool specify the intended network, gateway, and DNS servers? Check global exclusions separately if needed.
If a client receives a valid address but the wrong gateway or DNS resolver, check the server-supplied options, not just the available-address count. For example:
ip dhcp pool USERS
network 192.0.2.0 255.255.255.0
default-router 192.0.2.1
dns-server 203.0.113.53
These lines supply endpoint settings from the IOS DHCP pool. They do not configure the router's own DNS lookup server or relay the client broadcast. Verify the actual lease on the endpoint after correcting the source.
5. When DHCP snooping changes the answer
On a switch that uses DHCP snooping, server-originated DHCP messages arriving on untrusted ports can be dropped. An address pool may be healthy, and the relay may be configured, yet the reply may never reach the client.
show ip dhcp snooping
show ip dhcp snooping binding
Use the first command to check enabled VLANs and trust state. The binding table contains learned information used by features such as Dynamic ARP Inspection (DAI). A missing binding on its own does not prove that a DHCP server exhausted its addresses or that a relay is misconfigured.
Do not solve every failed lease by trusting a port. Trust only the path intended to receive authorized DHCP server or relay messages. For the switch-side control decisions, see the Layer 2 Security Controls Quick Reference.
6. Three DNS settings that are easy to confuse
These settings answer separate questions:
ip helper-addresson a client-facing Layer 3 interface: Where should the router relay supported client broadcasts, including DHCP requests?dns-serverinside an IOS DHCP pool: Which DNS resolver address should the DHCP server offer to its clients?ip name-serverin IOS global configuration: Which DNS server should the Cisco device itself query for hostname resolution?
A laptop can receive the correct address and gateway while getting the wrong DNS resolver from DHCP. Fixing ip name-server on the gateway would affect that Cisco device's name lookups, not automatically fix the resolver address in existing endpoint leases.
An IOS router resolving app.example.test successfully therefore does not prove that connected workstations have the correct DNS settings. Test from the affected client or query the resolver it actually uses.
7. Choose the DNS record that matches the service
| Record | What it supplies | Diagnostic clue |
|---|---|---|
| A (address) | Name to IPv4 address | A web hostname returns an old or incorrect IPv4 address. |
| AAAA (IPv6 address) | Name to IPv6 address | An IPv6-capable client selects a broken IPv6 destination. |
| CNAME (canonical name) | Alias to another canonical name | An application alias targets the wrong hostname. |
| MX (mail exchanger) | Mail exchanger and preference | Other mail servers cannot find the expected receiving mail host. |
| NS (name server) | Authoritative name servers for a zone or delegation | A delegated zone is referred to the wrong servers. |
| PTR (pointer) | IP address to hostname in reverse DNS | A reverse lookup returns an unexpected or missing hostname. |
The first clue is what the application needs: an IPv4 address, an IPv6 address, an alias, mail routing, delegation, or reverse-name information. Do not choose an MX record to repair a normal website's A record or use a PTR record as a replacement for forward DNS resolution.
8. Query the resolver used by the affected client
Start from an endpoint that exhibits the failure. Compare its configured resolver with the expected value, and request the specific record type.
ipconfig /all
nslookup app.example.test
nslookup -type=AAAA app.example.test
nslookup -type=MX example.test
ipconfig /all is a Windows example. On systems where dig is installed, use dig A app.example.test, dig MX example.test, or dig -x 192.0.2.80. Different tools and platforms have different defaults, so specify the record type when it matters.
On a Cisco IOS device, show hosts can show its DNS lookup settings and cached host entries. A hostname-based ping may help confirm the router's own name resolution, but the router and the user's computer may use different resolvers.
Ask these questions before changing records:
- Did the client query the intended resolver, or is its DHCP-provided DNS address wrong?
- Did the resolver return an answer, no such name, or no response?
- Is the record type and returned target correct for the application?
- Does the destination answer by IP, and is the required service port reachable?
- Is a cache masking a recent authoritative DNS change? Compare authoritative information before blaming propagation.
A DNS answer is evidence of resolution, not proof that HTTPS, mail, or another application works end to end.
9. Scenario comparisons: what to check next
Scenario 1: One VLAN gets link-local addresses. VLAN 20 clients show 169.254.x.x; VLAN 10 clients work. Check VLAN 20's gateway interface and helper, route to the DHCP server, matching server pool, and any DHCP snooping policy. Do not infer that the whole DHCP server has failed.
Scenario 2: Clients get valid addresses but no working DNS. A user receives 192.0.2.41/24 and gateway 192.0.2.1, and can reach 198.51.100.80 by IP. The hostname lookup fails. Read the endpoint's DNS resolver setting, inspect the DHCP pool's dns-server option if IOS supplied the lease, and query the intended resolver for the A or AAAA record.
Scenario 3: DHCP server shows an available pool, but no leases. Check whether a relay is needed, whether the helper is on the client-facing interface, whether the remote server has a pool for that relayed subnet, and whether replies can return. Available addresses on one server do not confirm packets are reaching it.
Scenario 4: The website works by name, but incoming mail fails. An A record working for a website does not confirm mail routing. Examine the MX record, its target hostname, and the target's address records, then examine connectivity to the mail service.
Scenario 5: The router resolves a name, but the client cannot. Inspect ip name-server only for the router's own lookup. On the client, inspect the resolver learned through DHCP and test the exact resolver and record type. Two devices can have different DNS configurations.
10. Common CCNA exam traps
- Confusing a relay and a server:
ip helper-addressforwards supported broadcasts; it does not create leases or fix an exhausted pool. - Checking bindings on the wrong router:
show ip dhcp bindingreflects the local IOS DHCP server, not every lease from a remote server. - Assuming DHCP failed because DNS failed: A client may have valid addressing and only an incorrect resolver or record.
- Treating all DNS records as interchangeable: A, AAAA, CNAME, MX, NS, and PTR perform different jobs.
- Misplacing the helper: Configure the relay where the client broadcast arrives, on the relevant Layer 3 interface.
- Trusting a DHCP snooping port without evidence: Confirm the authorized server/relay path and configured trust boundaries first.
- Testing the wrong host: Router-based
show hostsor hostname pings prove the router's view, not the affected endpoint's configuration. - Changing settings before isolating the fault: Check the observed state, the intended design, and the evidence that separates the likely causes.
11. Rapid review grid
| Symptom or question | First useful evidence | Avoid assuming |
|---|---|---|
| No usable lease | Client address, port/VLAN, gateway interface, helper, pool | The DHCP server is down. |
| Helper configured, but still no lease | Client-facing placement, server route and return path, matching pool | The helper alone completes DHCP. |
| IOS pool suspected empty | show ip dhcp pool, then bindings and conflicts | A binding table on the relay shows remote leases. |
| IP works; name fails | Client DNS configuration and record-specific nslookup | IP routing is broken. |
| Only the router resolves a name | show hosts and the client's separate resolver settings | Endpoints use the router's resolver. |
| Mail delivery lookup fails | MX record and its target address records | A healthy web A record proves mail works. |
Use the CCNA IOS Verification Commands reference when you need to confirm the exact command and output. Check platform-specific syntax because Cisco IOS and IOS XE commands and output can vary by software and device family.