Routelearn.net
Course menu

Unit 14: Network TroubleshootingLesson 14.8 (8 of 10 in this unit)80 of 84 in the Network Fundamentals course

DNS problems

When the network works but names don't: how to prove it and fix it.

Beginner · 6 min read

A DNS (Domain Name System) problem is a fault in name resolution: hosts can be reached by IP address, but names fail or resolve to the wrong address because of a wrong or unreachable DNS server, a wrong record or a stale cache. Testing the same destination by IP address and by name separates a DNS fault from a connectivity fault.

In simple terms: If a site works when you use its IP address but not its name, the network is fine. The problem is the “phone book” that translates names into IP addresses.

A real-life situation

“The internet is down!” says a user. But their chat app is still connected, and you can ping a public IP address from their PC. The browser just shows “server not found” for every site. The network is fine. The PC simply can't translate names into IP addresses.

What DNS does, and what breaks

DNS (Domain Name System) translates a name such as www.example.com into an IP address. Your PC sends the question to a DNS resolver: the DNS server set in its network settings, usually provided by DHCP. If that step fails, almost every app fails with it, which is why DNS faults look like “everything is down”.

Step 1 of 3 · Query
Name first, then the connection
PC
192.168.10.40
DNS resolver
192.168.10.5
Web server
203.0.113.80

Why the "IP versus name" test proves it

Ping the same destination twice: once by IP address, once by name. The two results together tell you where the fault is.

Ping by IPPing by nameConclusion
WorksWorksThe network and DNS are fine. Look at the application.
Works"could not find host"DNS problem.
FailsFailsA network problem. Fix that before you look at DNS.
FailsName resolves to an address, then times outDNS works. The problem is the path or the target (or ICMP is filtered).
✕ link downPCSW1Office DNS192.168.10.5R1Old DNS192.168.99.5 (removed)
  1. 1. Wrong server: the PC was set by hand to use a DNS server that no longer exists. Every query times out.
  2. 2. Server down or blocked: the right server is set, but the DNS service has stopped, or a firewall blocks UDP and TCP port 53.
  3. 3. Stale or wrong record: DNS answers, but with an old address, either from the server or from the PC's own cache.

How to verify

Example output · typical of Windows, written for this lesson, not captured from a real computer
C:\> nslookup www.example.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.99.5

DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out
What to look for: Address: 192.168.99.5 is the DNS server the PC is asking, and DNS request timed out means it doesn't answer. (Server: UnKnown only means nslookup couldn't look up that server's own name.) Compare the address with the DNS server listed in ipconfig /all and with what it should be.
nslookup www.example.com 192.168.10.5

Ask a specific DNS server. If this works but the default one doesn't, the PC is set to use the wrong server.

Example output · typical of Windows, written for this lesson, not captured from a real computer
C:\> nslookup nosuchhost.example.com 192.168.10.5
Server:  dns1.example.com
Address:  192.168.10.5

*** dns1.example.com can't find nosuchhost.example.com: Non-existent domain
This is different: the server answered, and the answer is “that name does not exist” (NXDOMAIN). The DNS server works, so check the spelling of the name, and whether the record was ever created.

On Linux and macOS, dig www.example.com gives more detail, and resolvectl status (Linux) or scutil --dns (macOS) shows which DNS resolver is in use. After a record is fixed, clear old answers from the PC's cache with ipconfig /flushdns on Windows or resolvectl flush-caches on Linux with systemd-resolved. A DNS resolver that cached the old answer keeps it until the record's TTL (time to live) expires, unless its cache is cleared too.

A Cisco router needs DNS too, for example to ping a device by name. The commands below are based on Cisco documentation, not run on a lab device.

Example output · based on Cisco documentation; exact format varies by platform and software version
R1(config)#ip name-server 192.168.10.5
R1(config)#ip domain lookup
R1(config)#end
R1#ping www.example.com
Translating "www.example.com"...domain server (192.168.10.5) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.80, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/11/12 ms
What to look for: domain server (192.168.10.5) [OK] shows that the router asked 192.168.10.5 and got an answer, and the ping went to the resolved address 203.0.113.80. ip domain lookup is on by default; if it has been turned off, the router can't resolve any names.

Check yourself

Predict · scenario 1

From a user's PC, ping 203.0.113.80 works, but ping www.example.com says 'could not find host'. Where is the fault?

Predict · scenario 2

A user can't open a new intranet site. nslookup gets 'Non-existent domain' from your normal DNS server. What does that tell you?