Domains stopped resolving for a high-value downstream customer. The suspected cause was our own recent migration. The real cause was a healthy, symptom-free server nobody had connected to the authority chain.
5 September 2026 · 2 min read
SECTOR
Hosting and DNS provider
SCALE
Cluster-style NS pair, five-figure downstream contract
PLATFORM
Delegated nameservers + Windows Plesk
ENGAGEMENT
Escalated outage
Rollbacks required
Overlooked dependency, found
Resolution restored
Scroll the diagram sideways to see all of it →
The break was one hop upstream of everything anyone had thought to check.
The blame had already landed before we started. A downstream customer of our client reported a production outage. The affected customer represented a five-figure annual contract, so the incident carried immediate commercial pressure alongside the technical one. The initial assumption was that a nameserver IP change our team had completed days earlier had caused it, and the customer’s own in-house team had already traced the fault back toward that change.
The suspected change was clean, so we started again from the outside. We rechecked the earlier DNS migration first and found no implementation fault: the expected records and server-side changes were all correct. So we restarted from the external DNS path and walked the authority chain step by step. That exposed a deeper dependency. The delegated nameserver hostnames used by the affected domains relied on a DNS zone hosted on the customer’s own shared Windows Plesk server. That server was working perfectly. Its own hosted sites were unaffected and did not use the nameservers in question, so it looked operationally unrelated and nobody had thought to check it.
A dependency that produces no symptoms on the machine hosting it is the hardest kind to find.
The break was one hop upstream of everything anyone had checked. The outage was not caused by the earlier nameserver IP migration. The zone on that Plesk server still held the records required for the downstream customer’s nameserver resolution. During phased IP cleanup, legacy IP addresses were removed from it. The server itself carried on without a symptom, but the authority chain it silently underpinned broke, and domains across the customer’s core infrastructure stopped resolving.
Core domains not resolving; a migration our team had completed days earlier was the prime suspect.
Re-verify the suspected change first, then walk the authority chain from the outside in.
Restored with a registrar glue update. The earlier migration was never rolled back.
Repaired at the registrar, not on the servers. We updated the child nameserver IP addresses for the upstream nameserver hostnames in the registrar panel, restoring the authority chain resolvers needed to reach the delegated nameserver layer. We then monitored external resolution until responses stabilised and the remaining impact cleared through normal propagation.
Resolution restored without rolling back the migration. The incident was traced to a hidden dependency on the customer’s own infrastructure rather than an implementation mistake. The work also left everyone with a documented picture of the nameserver dependency chain, which now informs how IP migration and cleanup are scoped.
The record that breaks you is rarely the one you changed. We map the full authority chain before the cleanup, not after the outage.
