Why your Wi-Fi is fine and your DNS is not

Someone hands you a laptop and says the internet is broken. Before you touch anything, notice that they have just made a claim about a system with at least six independent layers, and that they are almost certainly wrong about which one.

This is not a criticism. I do it too. “The internet is down” is a perfectly good description of the experience. It is a terrible description of the fault, and the gap between those two things is where whole evenings go.

The two questions people conflate

“Can packets leave this machine” and “can this machine turn a name into an address” are different questions with different failure modes. Wi-Fi answers the first. /etc/resolv.conf answers the second. They fail independently, and the symptom — a spinner, then a browser page that says something unhelpful about not being able to connect — is identical.

Worse, the second one fails intermittently in ways that look like the first. A resolver that answers in 40ms for cached names and times out for everything else feels exactly like a flaky radio. It is not a flaky radio. It is a resolver, and the radio is sitting there working perfectly while you power-cycle it.

The network is reliable. The network is not reliable. Both statements are load-bearing, depending on which meeting you’re in.

Four commands, in order

Run them in this order and stop at the first one that fails. The order matters more than the commands do — you could substitute your own favourites for any of these, but you cannot substitute the sequence.1

ping -c2 $(ip route | awk '/default/ {print $3}')   # 1. the gateway
ping -c2 1.1.1.1                                    # 2. routing
dig +short cloudflare.com @1.1.1.1                  # 3. resolution, bypassing local
dig +short cloudflare.com                           # 4. resolution, as configured

Ping the gateway

If this fails, nothing downstream is worth testing. It’s the cable, the radio, or the DHCP lease — and in my experience, in roughly that order of likelihood, which surprises people who expect the radio to be the flakiest part. Cables fail quietly and constantly. Radios fail loudly and then recover.

The useful thing about starting here is that it’s the one test whose failure has an obvious physical response. You can go and look at a cable.

Resolve a name you don’t own

The gap between the third and the fourth command is the whole article. If line three works and line four doesn’t, the network is fine and the resolver is lying to you.

One caveat, which I got wrong in the first version of this piece: on hotel or café Wi-Fi, line three can also fail for a reason that has nothing to do with your resolver. Captive portals routinely block outbound port 53 to anything but their own box, so a failure there means “something is eating DNS” rather than “your resolver is fine”. If you’re on a network you don’t control, read lines three and four together rather than separately.

What to tell the person who asked

Not “it was DNS.” Everyone says that, it has become a joke, and jokes don’t transfer skill. Tell them which of the four lines failed and what that line was asking.

People remember a question far longer than they remember an answer. The next time it breaks, someone who was told “it was DNS” will call you. Someone who was told “line one asks whether this machine can reach the box in the hallway” will run line one themselves, and about a third of the time that’s the end of it.

• Line one fails — it’s physical, or it’s the lease.
• Line two fails — it’s routing, or it’s the ISP.
• Line three fails — something is eating port 53, which on a network you don’t control usually means a captive portal.
• Line four fails alone — it’s the resolver. This is the common one.

That’s it. Four lines, one sequence, and a decent chance you never have to hear the phrase “the internet is down” delivered as a diagnosis again.