The page
I was doing technical support for broadband customers. A big share of the calls opened the same way: the internet's down. Lights on the router were green, so the line was up. Something else was off.
Triage
I got into the habit of running the same checks in the same order on every call, so the customer and I could rule things out together.
:: what the machine thinks its network looks like, including DNS servers
ipconfig /all
:: can we reach the outside world by IP? (no DNS involved)
ping 8.8.8.8
:: can we resolve a name with the configured resolver?
nslookup example.com
:: same name, but ask a different resolver directly
nslookup example.com 8.8.8.8
:: where does the path stop?
tracert example.com
If ping 8.8.8.8 worked and nslookup example.com failed, the connection was
fine and DNS wasn't. That covered most of these calls.
Root cause
Two things kept coming up. The router was handing out a resolver that wasn't answering, or the PC had been set to a fixed DNS server years ago and that server no longer existed. Either way the browser couldn't turn a name into an address, and to the customer that looks exactly like no internet.
The fix
Per call, the fix was resetting the adapter to get DNS from the router and clearing the cache:
ipconfig /flushdns
ipconfig /renew
The bigger fix was writing the order of checks down so everyone on the team asked "by IP or by name?" before anything else.
What I learnt
Users describe symptoms. "The internet is down" is a symptom. Testing by IP and then by name splits the problem in half in under a minute, and I still start most network issues that way.
What I do now
- Test the path by IP first, then by name. Two commands, half the search space gone.
- Ask a second resolver directly before blaming the first one.
- Write the triage order down. A checklist beats whoever happens to be on shift.
this is the work stage 1 does at scale → see the engagements