What DNS does
DNS, the Domain Name System, is the internet's directory. It translates a name you can remember, like example.com, into the numeric IP address your computer actually connects to. Every time you open a site by name, a DNS lookup runs first and quietly hands your machine the address.
If you want the full picture of what DNS is and how a lookup travels from root to authoritative server, start with the companion reference, Understanding DNS, and then come back here.
The key insight: DNS is not required
Read this first
A network does not need DNS to function. Computers route traffic using IP addresses, and DNS is just the convenience layer that lets you use names instead of numbers. You can reach any host directly by its IP address even with DNS completely offline.
That single fact is what makes the whole diagnostic work. If you test a name and it fails, then test a raw IP and it succeeds, you have proven the network is healthy and isolated the failure to name resolution, which is exactly the job DNS does.
Using ping to test
ping is the simplest tool for this. It sends a small ICMP Echo Request to a target and waits for an Echo Reply. If replies come back, the target is reachable.
The trick is what you point it at. When you ping a name, your computer must first resolve that name to an IP address (a DNS step) and only then send packets. When you ping an IP address directly, no DNS is involved at all. Comparing the two tells you whether DNS is in the way.
⚠ Ping caveat: Windows 7 and newer
ping is only a reliable reachability test if the target actually answers ICMP. By default, Windows Firewall blocks inbound Echo Requests on Windows 7 and every version after it. A Windows 7, 10, or 11 host that has not been configured to allow ICMP will show Request timed out even though it is up and DNS is working perfectly.
So a timeout against a Windows machine proves nothing about DNS. That is why this demonstration targets hosts known to answer ping: a public web server and 8.8.8.8, Google's public DNS server. Both reply to ICMP, so a failure against them is meaningful.
Demonstration: two pings
The test is two commands. First we ask for a host by name. Then we ask for a host by raw IP. Watch what changes.
Step 1: Test a name
Check whether the system can resolve and reach example.com.
C:\Users\learner>ping example.com Pinging example.com [93.184.216.34] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 93.184.216.34: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
This time ping had an address to work with, so it sent its four packets. Not one came back. Every request timed out, and Windows tallies the result at the bottom as 100% loss. The traffic left your machine headed for that host and nothing answered.
Step 2: Test a known IP
Now ask for 8.8.8.8 directly, with no name to resolve.
C:\Users\learner>ping 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=14ms TTL=117 Reply from 8.8.8.8: bytes=32 time=13ms TTL=117 Reply from 8.8.8.8: bytes=32 time=15ms TTL=117 Reply from 8.8.8.8: bytes=32 time=14ms TTL=117 Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 13ms, Maximum = 15ms, Average = 14ms
Four replies, zero loss. Traffic leaves your machine, crosses the network, reaches a server on the public internet, and comes back. No DNS was needed because you used a literal address.
On Linux and Kali
The same logic applies, the output just looks different. One difference worth knowing: on Linux, ping runs until you stop it, so you add -c 4 to limit it to four packets, or press Ctrl + C to stop a running ping.
kali@kali:~$ ping -c 4 example.com PING example.com (93.184.216.34) 56(84) bytes of data. --- example.com ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3052ms
kali@kali:~$ ping -c 4 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=14.2 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=13.8 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=15.1 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=14.5 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 13.800/14.400/15.100/0.470 ms
Reading the results
Put the two outcomes side by side.
✗ Failed
ping example.com
A name. It resolved to an address, but that host never replied. Four packets out, zero back.
✓ Succeeded
ping 8.8.8.8
A raw IP. Replies came back, so the network path is healthy end to end.
The contrast is the whole point. Reaching 8.8.8.8 proves your machine can get out to the public internet and back, so the network path itself is healthy. The failure was specific to the named host: an address came back, but nothing at that address answered. Whenever the name path misbehaves while a raw IP works, DNS is the first thing to check, because name resolution is the one step that sits between a name and the address your packets actually use. When names fail but raw IPs succeed, suspect DNS first.
What could cause this
"DNS is down" covers a range of root causes, from your own machine to a server far away. Common culprits, running roughly from the client side to the server side:
- The client is misconfigured: it has the wrong DNS server address, or no DNS server set at all.
- DHCP handed out a bad or unreachable DNS server when the machine joined the network.
- The DNS server itself is down, overloaded, or its service has crashed.
- The network path to the DNS server is blocked by a firewall or a routing problem.
- The local DNS cache is holding a stale or poisoned answer (less common, and easy to clear).
- In a lab, the DNS service was stopped or misconfigured on purpose as part of the exercise.
A few commands to narrow it down:
- See which DNS server you are actually using:
ipconfig /allon Windows, orcat /etc/resolv.confon Linux. - Bypass your configured resolver and ask a known good one directly:
nslookup example.com 8.8.8.8. If that resolves but normal lookups fail, the problem is your configured DNS server, not the internet. - Clear a stale cache on Windows:
ipconfig /flushdns. - Confirm you can even reach your DNS server by pinging its IP address, assuming that server answers ICMP.
In the lab environment
Lab note
If you are seeing this exact pattern in the lab, a failed name lookup followed by a successful ping to 8.8.8.8, it is by design. DNS has been taken out so you can experience an outage firsthand and practice diagnosing it. Work the steps above to confirm what is broken before you try to fix anything.
Before you troubleshoot DNS, make sure you understand what it is and how a lookup actually works. Review the companion reference, then return to these steps.
Understanding DNS →