Every disaster story in IT has the same shape: a small wrong assumption, copied into a plan, executed on a Friday. This one got stopped by an intern with a browser and a handful of free lookups. The company is invented; the mistakes are not. Every one of them has taken a real business offline at some point.
Week three, and a weekend cutover
Sally had been at Meridian Parts — a mid-size auto-parts distributor — for exactly three weeks. Two things were happening over the weekend. The customer portal, meridianparts.com, was moving to a new hosting provider. And separately, a freight partner was switching on an IP allowlist on Monday at 08:00, so that only traffic from Meridian's office would be allowed to reach the shipping API that prints delivery labels.
Her manager, Dev, gave her the intern's brief: “Sit in on the calls, take notes, don't touch anything.” She took notes. She also had a second monitor open.
First question: what is our IP address?
The allowlist form the partner sent needed one value: Meridian's public IPv4 address. Someone copied it off an internal wiki page that was last edited in 2023. Sally opened What Is My IP on the office Wi-Fi and read the number out loud. It did not match the wiki. The ISP had swapped the office router the previous year and the public address had moved with it; the number on the wiki now belonged to a stranger. If the form had gone in as written, Monday at 08:00 every warehouse scanner that talked to the shipping API would have quietly stopped working, and nobody would have known why until the trucks left without labels.
She noticed something else on the page: a second address, an IPv6 one. The partner's form had a single IPv4 box. Sally flagged it — if the office was now getting IPv6 from the ISP, some traffic could leave the building over v6, skip a v4-only allowlist, and fail intermittently, which is the most miserable kind of failure to debug. “Confirm IPv6 egress, disable it or get it allowlisted too” went on the checklist. (If you ever need to do the reverse and pin down a server's address, see how to find a website's IP address.)
The email that did not smell right
An hour later a message landed in the migration thread. The sender was “hosting-support,” the signature matched the hosting company, and the ask was simple and urgent: the new server is ready, here is its IP address, please update the A record for meridianparts.com today so it propagates before the weekend. Two people replied “thanks, doing it now.”
One detail stuck out to Sally. Every genuine message from the provider used the‑host.com. This one's reply-to domain was thehost‑support.net.
A quick WHOIS, and the weekend changes
She pasted the IP address from the email into IP WHOIS Lookup. It did not come back as the hosting company. It came back as a residential broadband block belonging to a consumer ISP in another country — different ASN, different registered organisation, an abuse contact at a free webmail address. Then she ran the same address through Reverse DNS Lookup. The PTR record was an auto-generated dynamic-looking hostname of the host‑203‑0‑113‑41.dsl.example.net variety, and it did not forward-confirm: the name did not resolve back to the address. Nothing about it looked like professional hosting infrastructure.
Sally screenshotted both results and walked to Dev's desk. Ten minutes later the “update your A record” email was in the security team's inbox, flagged as business email compromise: a lookalike domain, a copied signature, and an IP address that would have pointed meridianparts.com at a server the attacker controlled. Every customer login and password typed into the portal would have gone straight to them, for as long as it took someone to notice the site looked slightly off. The real cutover address, when it arrived a day later, came from the provider's actual domain and checked out cleanly in WHOIS.
Background reading on those two lookups: WHOIS and geolocation are not the same lookup, and PTR records, reverse DNS and FCrDNS explained.
Checking the site that was about to go live
With the fake out of the way, Sally looked at the genuine staging site. She pasted its URL into the HTTP Header Checker, which fetches the page server-side and grades the response headers. It came back a C. No Strict-Transport-Security, so a downgraded connection would never be caught. No Content-Security-Policy. And the Server header spelled out nginx/1.18.0 (Ubuntu) while X-Powered-By helpfully added PHP/7.4 — a precise version list that an attacker can line straight up against known exploits. Three one-line fixes for the sysadmin, filed before launch instead of after an incident.
The firewall rule that was quietly too wide
The migration also needed a firewall rule so the new portal server could reach the customer database. The draft read: allow 10.20.0.0/16 to the database VLAN. “The whole internal range, to be safe,” the ticket said. Sally dropped it into the Subnet Calculator. A /16 is 65,534 usable addresses — the office, the guest Wi-Fi, the warehouse tablets, the meeting-room TVs, all of them able to open a connection to the customer database. The portal server needed exactly one subnet. The rule went in as a /27 — thirty addresses, the segment the app servers actually lived on.
“Hold everything, the internet is slow”
Friday, 16:30. Someone in sales announced that the internet was crawling and maybe the migration should wait. Dev reached for the calendar. Sally ran the Network Health Check first — an honest read of what a browser can actually see: online status, round-trip latency to a server and its jitter, and whether repeated requests all get through. Green across the board. Then the Speed Test for throughput: normal, both directions. The office link was fine. The slow thing turned out to be one overloaded VPN concentrator shared by a dozen remote staff, with nothing to do with the cutover. It went ahead on schedule.
Monday, 08:00
The freight partner's allowlist switched on and nothing broke: the office IP on the form was the real one, and IPv6 egress had been pinned the Friday before. The portal was on its new host with HSTS, a CSP, and a Server header that no longer volunteered its version numbers. The database VLAN accepted connections from thirty addresses instead of sixty-five thousand. The business-email-compromise attempt was a single paragraph in the security team's monthly report.
Dev handed Sally the postmortem to write up. Her first line: “None of this needed special access. It needed someone to check the number instead of trusting it.”
What Sally actually did — and you can too
- Verify an IP address before you build a rule around it. What Is My IP takes five seconds; a stale address in an allowlist is a Monday-morning outage waiting for a date.
- WHOIS any “new server IP” before you change DNS. If IP WHOIS Lookup says the address belongs to a home broadband range while the email says “enterprise hosting,” stop and escalate.
- Check the reverse DNS too. A missing or non-confirming PTR on something that claims to be production infrastructure is a red flag. Reverse DNS Lookup.
- Run a header check before launch, not after. The HTTP Header Checker catches missing HSTS or CSP and leaked version strings in one pass.
- Size subnets on purpose. “The whole range to be safe” is the opposite of safe. The Subnet Calculator turns a CIDR into a host count you can react to.
- Measure before you blame the network. Network Health and the Speed Test turn “the internet is slow” into numbers you can act on.
Frequently asked questions
Can a WHOIS lookup really expose a spoofed vendor email?
It exposes a mismatch. WHOIS tells you which organisation and network an IP address is registered to. If a message claims to be from a hosting company but the IP address it wants you to use is registered to an unrelated consumer ISP in another country, that gap is a strong signal something is wrong. It is not proof on its own — pair it with checking the sender's domain and the reverse DNS — but it is often the fastest tell.
Why did What Is My IP show two addresses?
Most connections today can carry both IPv4 and IPv6, and the page shows whichever it sees — often both. It matters for allowlists: a partner that only records your IPv4 will see intermittent failures whenever your traffic leaves over IPv6 instead.
What is FCrDNS?
Forward-confirmed reverse DNS. You look up the PTR record for an IP address to get a hostname, then look up that hostname and check that it resolves back to the same address. Mail servers use it to judge whether a sending IP is legitimately named. A production server whose PTR does not forward-confirm is unusual, and worth a second look.
Is the network health check the same as a speed test?
No. The Network Health Check measures latency, jitter and whether repeated requests get through — is the connection responsive and stable. The Speed Test measures how much bandwidth you have. Friday's scare needed both to clear the office link.
Related reading: WHOIS vs geolocation, PTR records and reverse DNS, How to find a website's IP address, Password security and 2FA (with a story). · Tools: What Is My IP, IP WHOIS Lookup, Reverse DNS Lookup, HTTP Header Checker, Subnet Calculator, Network Health, Speed Test.