Permission to inspect a domain is not permission to change it. Read-only analysis can identify a likely repair, but a DNS mutation changes the authority other systems rely on. A safe workflow keeps observation, recommendation, approval, execution and verification separate, with a binding between what was approved and what is actually applied.
Define the read and write boundaries
Use read-only credentials for discovery and analysis when the platform supports them. Record the tenant, account, zone and queried names with the observation time. An analyst may produce a proposed before and after diff without applying it. A connected account, a successful read or a business request to investigate does not by itself grant authority to mutate the records.
NIST AC-6 describes least privilege, CM-3 addresses approved configuration changes and their records, and CM-5 addresses restrictions on making changes. These principles support separating analysis from execution. The approval-binding model below is an implementation example, not a complete compliance claim. NIST controls.
Make approval specific enough to enforce
The request should identify the exact account and zone, record name and type, current value, proposed value, reason, affected services, verification plan and recovery conditions. Bind approval to a digest of the relevant current state and the exact proposed diff. Include an expiry and the approver's authorized scope. If the tenant, diff or underlying state changes, stop and obtain a decision covering the new situation.
A matching digest checks content consistency under a defined serialization; it does not prove that the approver is legitimate or that the proposal is safe. Protect the approval record and execution identity through the platform's real access controls. Include all mutable properties that matter, such as TTL and record type, in a production diff. The hypothetical comparison below illustrates a changed baseline; it does not implement a provider write or omit those production properties from the required review.
Compare a stale baseline with a valid scope
Suppose an approval covers one tenant, one DNS owner name and a complete record change including TTL. Before execution, the current TTL differs from the approved baseline. Even if the proposed policy text is unchanged, this recommended workflow stops for reassessment: the reviewed state no longer matches. A second request aimed at a different tenant must not inherit the first tenant’s approval merely because the domain text and intended value look alike.
These are hypothetical decisions, not seven executed cases or an in-memory enforcement test. A real implementation must authenticate the actor, protect the approval record and apply the provider’s concurrency mechanism where supported. A successful local comparison cannot prove atomicity between the later read and write, and an illustrative recovery plan is not a performed rollback.
Verify before declaring success
At execution time, re-read the relevant state and apply a provider-supported conditional update where available. Otherwise manage the race explicitly and stop on conflicting changes. After applying, check authoritative data and the relevant operational outcomes. DNS caching means observations can differ temporarily; distinguish expected propagation from a wrong change using recorded times and resolver context. RFC 1034.
Treat failed verification as an unresolved change, even if the API returned success. Use the approved recovery plan only within its scope and verify recovery independently. Retain the approval, exact diff, execution identity, timestamps and evidence. The final record should state what changed and what was observed, without converting a successful tool call into an unsupported claim of safe mail delivery.