During a DNS provider outage, first determine whether the problem affects the management API, authoritative DNS answers or both. An unavailable API can prevent changes while existing DNS continues to answer. A public DNS outage requires a different response from a queue of delayed record edits.
IN THIS ARTICLE
01 Establish the impact
- Record the affected provider connection, zones, task references and first observed time.
- Check whether other connections to the same provider are affected. Compare the provider's current status information with your own observations.
- Query the existing authoritative nameservers for a known record. Separately inspect the module's connection or task error.
- Pause new bulk work under your operational procedure so the queue does not fill with repeated attempts at the same change.
- Preserve the desired record set and a last-known provider snapshot. Do not replace failed reads with an assumed empty zone.
02 Recover the management path
When access returns, read the actual provider state before resubmitting uncertain work. A provider may have accepted a write even though its response never reached WHMCS. Use reconciliation and the existing task's recovery path to decide whether the change is already present, still pending or genuinely failed.
For a package replicated across multiple servers, inspect each target's result. One healthy target does not prove every target is current. Keep the intended master and delegation under review; do not remove a failing target's remote zone just to clear a status message.
Should I immediately change the domain's nameservers?
Only a prepared replacement with complete records and a reviewed DNSSEC plan offers a sound migration path. Changing delegation to an empty backup can turn a management incident into a website and mail outage. Resolver caches also mean a delegation change is not instant failover.
What evidence should support receive?
Provide the connection label, affected domain, approximate time, task or request identifier and observed authoritative answers. Include the provider error code when available. Keep tokens, full authenticated URLs and secret-bearing request headers out of tickets. Describe whether an operation was submitted once or retried, so the outcome can be reconciled accurately.