Troubleshooting and IT support

Can't reach the service: a DNS and connectivity drill

A user can't open a web app. Find which of four faults is behind it, using real commands on a simulated laptop.

  • Intermediate
  • About 25 minutes
  • Command line
  • Simulation + real-world
  • Published 26 October 2026

The scenario

The ticket says: "I can't open app.example.com." That fits at least four different faults, and each leaves a different fingerprint in the command output. Collect the evidence and name the cause before changing anything.

Before you start

  • Comfortable running basic commands in a terminal
  • Helpful but not required to have done the "Trace a request" lab first

Tools

  • ping
  • dig / nslookup
  • nc
  • curl
  • ip route
  • resolvectl
  • ipconfig /flushdns

You'll be able to

You can split a connectivity problem in half by testing by IP address versus by name, and recognise the output patterns of DNS, routing, firewall and certificate faults.

Try it

Browser simulation. Runs entirely in your browser. Nothing connects to real systems.

This simulation needs JavaScript. Here is a short sample of how a session goes:

$ dig app.example.com
;; communications error to 198.51.100.53#53: timed out
;; no servers could be reached

$ ping -c 2 203.0.113.10
64 bytes from 203.0.113.10: icmp_seq=1 ttl=52 time=24.6 ms
2 packets transmitted, 2 received, 0% packet loss

$ nc -vz 203.0.113.10 443
Connection to 203.0.113.10 443 port [tcp/https] succeeded!

The method: split the problem in half

The fastest way through an “it doesn’t work” ticket is to stop guessing and start halving. Two questions do most of the work:

  1. Does it work by IP address? If the service answers at its IP but not by name, the network is fine and the fault is in name resolution.
  2. Does the port open? If ping works but the TCP connection to the service’s port does not, look for a firewall or a stopped service.

Each answer rules out half of the possible causes. The simulation above picks one of four faults at random. Every command you run gives real-looking output for that fault. Make your diagnosis when the evidence points one way, then try a new mystery.

Fault fingerprints

Fault By name By IP TCP 443 HTTPS
DNS resolver down Fails: name resolution Works Works by IP Fails: can’t resolve host
Wrong default gateway Fails Fails: host unreachable Fails: no route Fails
Firewall blocks HTTPS Works Works Times out Times out
Expired certificate Works Works Works Fails: certificate error

Look at the wrong-gateway row closely. DNS also fails there, but not because DNS is broken: the resolver is simply on the far side of a gateway the laptop can’t reach. Testing by IP is what tells the two apart.

Real-world DNS checks

Once the evidence points at DNS on a real machine, these are the next commands to run.

Which resolver am I actually using?

resolvectl status          # Linux with systemd-resolved
cat /etc/resolv.conf       # Linux, the traditional file
Get-DnsClientServerAddress -AddressFamily IPv4   # Windows

A surprise here, such as an old resolver address, a VPN’s resolver, or none at all, often explains everything.

Ask a different resolver directly

dig example.com @1.1.1.1
nslookup example.com 9.9.9.9

If a public resolver (Cloudflare’s 1.1.1.1 or Quad9’s 9.9.9.9) answers but yours doesn’t, the problem is your resolver or the path to it. Bear in mind that internal company names only resolve on internal DNS servers, so test public names this way.

Clear stale answers

DNS answers are cached for as long as their TTL allows, so a changed record can look “wrong” for a while.

ipconfig /flushdns          # Windows
resolvectl flush-caches     # Linux with systemd-resolved

Check for local overrides

The hosts file is consulted before DNS on most systems, and a forgotten entry can send a name to the wrong address.

  • Windows: C:\Windows\System32\drivers\etc\hosts
  • Linux and macOS: /etc/hosts

Read the error, not just the failure

  • Timeout / no servers could be reached: the resolver isn’t answering, or the path to it is broken.
  • NXDOMAIN: the resolver answered and says the name does not exist. Check spelling, the DNS zone, and whether the name is internal-only.
  • An unexpected address: stale cache, a hosts-file entry, or split DNS (different answers inside and outside a VPN).

Expected result

You should be able to diagnose all four simulated faults from command output alone, and explain why “test by IP” separates DNS problems from routing problems.

Going further

Run the same checks automatically with the script in Automate the checks.

Key lessons

  • Test by IP address and by name. If the IP works and the name does not, it is DNS.
  • A timeout and "connection refused" mean different things: something dropping traffic versus nothing listening.
  • Collect evidence before changing anything. Most tickets fit several causes until you test.

Keep going