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.

1. Yes, you can run all four at once. You will also learn less, and you’ll have to reconstruct the order in your head anyway.

What actually breaks

Not what you expect. It is never the SMTP daemon. It is DNS records you set up once and never looked at again, a certificate you renewed by hand in a hurry, and the slow, invisible business of your IP address acquiring a reputation you did not ask for.

dig +short MX example.com
dig +short TXT example.com    # SPF
openssl s_client -starttls smtp -connect mail.example.com:587

Run those three every few months and you will catch most of it before someone tells you their reply bounced.

The part I underestimated

Deliverability is not a technical problem, it is a political one, and you are a very small country. The large providers are not obliged to explain themselves to you and generally will not.

I still think it is worth doing, for the same reason I still think it is worth owning the domain your email arrives at. But do it with a second address somewhere else, and do not find out about an outage from your mother.