The phone rings: "the internet is down." You show up (or remote in) and, naturally, the internet is fine — it's the billing system that won't load. After enough field calls you learn that nearly every "the internet is down" is one of four things: the name doesn't resolve, the machine doesn't answer, the port is blocked, or the problem belongs to someone else — the hosting company, the ISP, the domain somebody forgot to renew. The good news: all four can be checked in minutes, in order, with evidence you can paste straight into a ticket. This guide is that order.
The detective's four questions
Before rebooting anything "just in case," ask the questions in sequence. Each one rules out an entire layer, and each "no" points at a different suspect:
- Does the name resolve? If the domain won't translate to an IP, nothing else matters. Tool:
digor the DNS lookup. - Does the IP answer? A name can resolve perfectly to a machine that's powered off. Tool:
ping. - Is the port open? The machine can be alive with the service dead, or a firewall in the way. Tool: the port tester.
- Who owns it, and how does the path look? If everything on your side checks out, you need to know who to call. Tool: WHOIS / RDAP and
traceroute.
The order isn't cosmetic: if the name doesn't resolve, testing the port is a waste of time; and if the IP answers but the port stays silent, you already know the cable isn't the problem. Troubleshooting is ruling out layers, not guessing.
The full case: from "it won't load" to a ticket with evidence
Let's run the flow on a classic: the branch office reports that billing.example.com "won't open," while the rest of the internet works. Stopwatch running:
- Does it resolve?
dig +short A billing.example.comreturns 203.0.113.80. The answer carries TTL 287 out of the original 300: the resolver cached it 13 seconds ago, meaning someone else just asked the same thing. The name is healthy. Next. - Does the IP answer?
ping -c 4 203.0.113.80: 4 sent, 4 received, 0% loss, average rtt 45.2 ms. The machine is alive and the route works. (If ping stayed silent, careful: that's not conclusive — plenty of firewalls drop ICMP on purpose. Move to step 3 anyway.) - Is the port open? TCP test against 443 with the port tester: the SYN goes out and after 3 seconds… nothing. State: filtered. That is not a dead service — a dead service answers instantly with an RST ("closed"). Total silence is the signature of a firewall dropping packets.
- Who owns it? RDAP on 203.0.113.80: AS64500, "Hosting Ejemplo SpA". It's the right provider — nobody hijacked the IP and the domain didn't expire. The problem sits at their door.
- The ticket. You grab your public IP from My IP (198.51.100.22) and write: "DNS resolves to 203.0.113.80, the IP answers ping at 45 ms, but TCP 443 shows filtered from our IP 198.51.100.22 since 09:40." Four commands, about three minutes, and the provider can't answer with "reboot your router."
$ dig +short A billing.example.com 203.0.113.80 $ ping -c 4 203.0.113.80 4 packets transmitted, 4 received, 0% packet loss rtt min/avg/max = 43.8/45.2/47.1 ms $ nc -zv -w 3 203.0.113.80 443 nc: connect to 203.0.113.80 port 443 (tcp) timed out
The journey of a DNS query
To troubleshoot DNS with any confidence you need to know who asks whom. It works like finding a person in a city you don't know: you ask the front-desk concierge; the concierge doesn't know either, but knows exactly who to ask — and once the answer comes back, writes it down for the next person who asks.
- The stub is your device: all it knows is how to hand the whole question to its configured resolver.
- The recursive resolver (your ISP's, or 1.1.1.1, or 8.8.8.8) is the concierge: it does the legwork and caches every answer.
- The root servers — 13 named identities,
athroughm.root-servers.net, replicated across hundreds of anycast instances worldwide — know exactly one thing: who runs each ending. ".com? Ask the .com registry." - The TLD (.com, .cl) doesn't know your IP either: it knows which servers are in charge of
example.com. - The authoritative server is the homeowner: it holds the zone with the real records and answers with authority.
Here's the detail that kills the industry's favorite myth: every answer travels with an expiry date — the TTL, in seconds. Until it expires, the resolver answers from cache without asking anyone. Which is why the famous "DNS propagation" does not exist: there is no process pushing your new record around the world. There are thousands of caches that stored the old value and will each let it go when their own TTL runs out. "Waiting for propagation" is, quite literally, waiting for the yogurt to expire.
The records you'll actually use
A DNS zone is a table of typed facts. These six cover 95% of an integrator's work — you can query them all from the DNS lookup tool:
| Record | What it answers | Example | Watch out for |
|---|---|---|---|
| A | name → IPv4 | billing → 203.0.113.80 | a high TTL handcuffs your migrations |
| AAAA | name → IPv6 | billing → 2001:db8::50 | if it exists, clients tend to prefer it: test it too |
| CNAME | alias to another name | www → example.com | not allowed at the apex, can't coexist with other records |
| MX | who receives the mail | 10 mail.example.com | lowest priority wins; must point to an A record, not a CNAME or IP |
| TXT | text: SPF, verifications | v=spf1 … | multiple TXT records may coexist, but only one SPF |
| NS | which servers rule the zone | ns1.hosting.net | must match the delegation at the TLD |
| PTR | the reverse: IP → name | 80.113.0.203.in-addr.arpa | managed by the IP's owner (your ISP), not your zone; critical for mail |
PTR deserves one more sentence: it lives in a mirror zone (in-addr.arpa for IPv4, ip6.arpa for IPv6) where the IP is written with its octets reversed — 203.0.113.80 is looked up as 80.113.0.203.in-addr.arpa. If you need to build those names without pain, the reverse PTR zone tool generates them from an IP or CIDR.
example.com) breaks the zone: the standard requires a CNAME to be the only record at that name, and the apex already carries mandatory NS and SOA records. That's why providers invented ALIAS/ANAME or "CNAME flattening." If your control panel let you save it anyway, it's not that it works — it's that the panel doesn't like you.
When two resolvers disagree
You migrated billing.example.com to a new server yesterday, and today half the users still land on the old one. Black magic? No: caches. Ask two different resolvers the same question and compare:
$ dig A billing.example.com @1.1.1.1 +noall +answer billing.example.com. 287 IN A 203.0.113.80 $ dig A billing.example.com @8.8.8.8 +noall +answer billing.example.com. 5100 IN A 198.51.100.7
Cloudflare (1.1.1.1) already has the new IP. Google (8.8.8.8) is still serving the old one — and the middle number tells you exactly how long is left: 5100 seconds, 85 minutes of remaining cache. It isn't "propagating slowly": it cached the record before the change, with the old TTL, and will drop it when that expires. Not one second sooner. The DNS propagation tool runs this comparison against several public resolvers at once — the civilized way to answer "has it propagated yet?": no, Google's yogurt has 85 minutes left.
Mail that lands: SPF, DKIM and DMARC
Half of modern DNS troubleshooting is mail landing in spam. Email was born with zero authentication — anyone can write "From: ceo@example.com" on an envelope — so three layers were bolted on, all published as TXT records in your zone:
- SPF is the guest list: which servers may send mail on the domain's behalf.
v=spf1 include:_spf.provider.com -allmeans "these ones yes, everyone else no." - DKIM is the notarized signature: the sending server cryptographically signs each message and publishes the public key at
selector._domainkey.example.com. Unlike SPF, the signature survives forwarding, because it travels with the message. - DMARC is the policy: it tells receivers what to do with mail that passes neither SPF nor DKIM aligned with the visible From domain — and where to send you reports (
rua) about who's sending in your name.
DMARC is adopted as a ladder, not a switch:
Start at p=none and read the reports for two to four weeks: that's where the CRM, the multifunction printer and that legacy system nobody remembered sends email all show up. Once every legitimate sender passes SPF or DKIM, move up to quarantine (with pct=25 it applies to 1 in 4 messages, so you brake slowly) and finally reject. The SPF/DKIM/DMARC tool fetches and explains all three records for a domain in one pass. And don't forget the PTR from the previous section: plenty of servers flat-out refuse mail from an IP with no coherent reverse.
include: counts, including the ones nested inside your provider's. Going over produces a permerror, and many receivers treat that as invalid SPF: your legitimate mail starts landing in spam right after "adding one more service." Count your lookups before stacking include number six.
Ports: open, closed or filtered
The last link in the flow earns its own section, because the three states of a port tell three different stories. Picture yourself knocking on a door:
- Open: someone opens. The SYN got its SYN/ACK — a service is listening and the firewall lets it through. If the application still fails, the problem lives higher up (TLS, credentials, the app itself).
- Closed: someone yells "nobody's home!" An immediate RST came back — network and firewall work, but no service listens on that port. Dead service or wrong port. In firewall terms: REJECT behavior.
- Filtered: dead silence. The packet died along the way with no reply — the signature of a firewall in DROP mode. For troubleshooting this is gold: it tells you there's a rule in the middle, and the ticket goes to whoever owns the firewall, not the server.
One detail that saves confusion: the port tester looks at your host from the internet. A port can be open on the LAN and filtered from outside (NAT or perimeter firewall), and that's not a bug — it's exactly the difference you want to measure. For the same reason, when you report a block that depends on the source, include your public IP — My IP hands it to you with ASN and organization included.
Next time someone yells "the internet is down," take a breath and run the four questions: name, IP, port, owner. Ten minutes and four tabs — DNS, ping, ports and RDAP — leave you with a defensible diagnosis instead of "looks like the provider's fault." And if the problem is email, same recipe with SPF/DKIM/DMARC: evidence first, policy second.