Common mistakes that take clients offline
Four failure patterns that show up across MSPs year after year. Each has a recognisable early signal in the ticket description.
The cardinal sins are a checklist of don’t do this. The common mistakes are a checklist of watch for this. They’re the failure modes that show up across multiple MSPs, multiple clients, year after year.
Pattern-matching the symptoms quickly lets you stop the damage before it spreads, or recognise that an in-flight ticket is heading toward a known cliff.
The four common mistakes
| Mistake | Early signal in the ticket | First diagnostic |
|---|---|---|
| 1. Missed renewal | ”Our website is suddenly down and we didn’t change anything” | whois example.com → check status flags (redemptionPeriod, pendingDelete) |
| 2. NS change without dual-provisioning | ”Right after we moved DNS to a new provider” | dig NS example.com to confirm current NS, then query the new host directly for records |
| 3. DNSSEC mishandled at transfer | ”Some networks see it, others don’t” (validating vs non-validating split) | dig DS example.com and dig +dnssec A example.com @8.8.8.8 |
| 4. Deleted-and-rebuilt SPF or MX mid-flow | ”Right after we updated email records, mail broke” | Compare current SPF / MX to recent change history |
The right after we did X pattern is the strongest single signal. A working domain that broke immediately after a specific change usually had something done in that change.
Reading the signals in detail
Missed renewal. Auto-renew fails (expired card, card removed, billing email not received). Domain enters grace, then redemption, then pending delete. The client doesn’t notice because services keep working through grace. Then redemption hits and everything stops.
NS change without dual-provisioning. The tech changes nameservers at the registrar to a new DNS host before the new host has the zone built. Resolvers query the new host, get nothing, services stop as caches expire.
DNSSEC mishandled at transfer. The tech doesn’t notice DNSSEC is on, changes nameservers (or disables DNSSEC without the DS-TTL wait). The zone goes dark at every validating resolver. Some networks but not others is the validating vs non-validating fingerprint.
Deleted-and-rebuilt SPF or MX. The tech is cleaning up mail records and decides to delete before adding the new ones. While there’s no SPF, receivers see unauthenticated mail and score harshly. While there’s no MX, inbound mail bounces. Both effects are immediate.
What this is NOT
- “These won’t happen to me; I’m careful.” They happen to everyone eventually. The protection is the reflex to check before clicking, not the intent to be careful.
- “The signal will be obvious.” The signal is often masked by what the client thought happened. We didn’t do anything usually means I don’t remember doing anything.
- “Recovery is always possible.” For redemption, partially — at significant cost. For pending delete, no. For some others, recovery is hours of degraded state.
Decision walkthrough
When the diagnostic confirms DNSSEC mishandled (DS records still at the registrar from the old host’s keys, new host signing with different keys), the fastest recovery is removing the DS records at the registrar immediately. Within the DS TTL, validating resolvers stop expecting signed responses and the zone resolves normally again. DNSSEC can be re-enabled later at the new host as a separate signed-off operation.