DNS drift means the state you expected differs from the state observed on a backend. An unknown outcome means a request was sent but its response did not establish whether the write completed. Investigate the evidence before choosing which records should win.
IN THIS ARTICLE
01 Identify the kind of difference
Compare the Domain Nexus desired record set, the provider's current records and public authoritative answers. These views answer different questions. A cached recursive answer can be old even when the authoritative zone is correct. A provider can hold a correct zone while the registrar delegates to another network.
- Open the affected zone and inspect recent history, changesets and job results.
- Check the provider binding and package master. Confirm that you are comparing the intended account and zone.
- Read the remote records and look for an outside administrator, another automation system or a partially completed migration that explains the difference.
- For an uncertain submitted write, open Lost answers and select Check the server now.
- Choose the recovery action only after the refreshed evidence supports it. The module checks the server again when resolving the result.
02 Choose the intended source
If the outside change was legitimate, preserve it and update the managed plan using a reviewed workflow. If it was accidental, prepare a corrective changeset from a known good snapshot. Avoid automatic replacement of an entire zone when only one record is disputed.
When replication is enabled, inspect every target and the current master. A target permission error or incompatible record type should be fixed directly. Switching masters to make an error disappear can turn an incomplete target into the source for other zones.
Should I retry a DNS write after losing the provider response?
The Lost answers workflow offers an action to record that an already applied change completed and an action to rerun a change that did not land. These actions are guarded by fresh reads. If the server remains unreachable, retain the uncertain state and restore connectivity instead of guessing.
03 Confirm recovery
Check the final provider records, job status and direct authoritative answers. Then verify the affected website, mail delivery or service validation. Save the cause and corrective action in your operational notes.
Reduce recurrence by assigning one management process for the same records, documenting intentional exceptions and rotating only the credentials involved. A DNS record backup helps repair data, but it does not establish who authorised an external change.