Documentary review: 8 November 2026. No DNS edits or concurrency tests were executed. The sequence, worksheet and fictional example below describe a proposed safe workflow, not measured behavior of an uninspected tenant or client.
Identify the unit that your tool replaces
Two operators can read the same DNS state, prepare different changes and unintentionally erase each other's work. The risk is greatest when a tool writes a whole record set from a stale local copy while its user thinks it is adding one record. Before editing, identify the provider's update unit: an individual value, a complete record set, a transaction or a whole zone import.
Azure DNS documents record sets as collections sharing the same owner name and type. Its PowerShell Set-AzDnsRecordSet operation replaces the existing record set, including its contained records, with the supplied object. Its documented ETag checks protect against overwriting concurrent changes unless explicitly suppressed. That behavior is specific to the documented client and operation; do not assume every DNS editor performs the same checks. Azure record-set operations
A TXT record set can contain several distinct TXT records. One might be SPF while others contain service-verification data. A stale replacement can remove another team's verification record even when the edited SPF string remains valid. Preserve the complete current set and understand the difference between several records and several character strings within one TXT record. DNS TXT representation
Use version-aware writes where the provider supports them
Azure DNS associates an ETag with a zone or record-set resource. In the documented create-or-update REST operation, If-Match accepts the last-seen ETag so a caller can avoid overwriting concurrent changes. Omitting that value permits overwriting the current record set. If-None-Match set to an asterisk permits creation while preventing replacement of an existing set. These controls address different intentions and should not be substituted casually. Azure DNS conditional request headers
An ETag is a provider resource-version marker, not a TXT value to publish. Preserve it with the baseline response and submit it through the supported client mechanism. Do not invent a version number, remove the condition after a conflict or switch to an overwrite option merely because the first request failed.
Azure PowerShell's documented defaults use ETag checks for record-set updates. Its Overwrite option suppresses those checks. A runbook that routinely adds that option loses the protection the default workflow provides. Review the exact tool version and operation used by your team rather than assuming that a portal click, REST request and PowerShell command all have identical concurrency behavior. PowerShell ETag checks
A conditional write on one record set does not establish a transaction across several unrelated sets, nor does it prove that an external sender's configuration changed at the same instant. If a migration requires coordinated changes to multiple names, document the safe intermediate states and provider-supported transaction semantics separately. Do not infer cross-record atomicity from a successful single-resource update.
Handle a conflict as new information
When the provider reports a version conflict, stop using the stale payload. Retrieve the current state and compare three things: the original baseline, the current provider state and the intended change. Identify which values were added, removed or modified by someone else. Ask the responsible owner about an unexplained change before deciding whether to keep it.
Prepare a fresh proposed result that preserves unrelated legitimate work. For TXT data, preserve complete logical record values rather than concatenating unrelated verification strings. For SPF, keep one valid SPF policy at that owner; merging two teams' intentions does not mean publishing two SPF policies. Review the combined authorization and lookup budget before approving it. SPF record selection and limits
Use the newly read version for the next approved write. If another change occurs again, repeat the review rather than looping indefinitely with forced retries. A high-conflict record set may need a single publishing queue or a clearly assigned coordinator. That is a workflow control, not a new DNS protocol feature.
Communication matters even where the API is safe. Record an editing window, owner and change reference for busy authentication records. A compare-and-swap rejection prevents one lost update, but it cannot tell two teams whether their independently valid changes conflict with business intent. The reviewers still need to understand the sender and service dependencies.
Do not confuse DNS caching with edit concurrency
TTL controls how long DNS data may remain in caches; it is not an edit lock and does not reserve the record for one administrator. Lowering TTL does not stop a stale API client from replacing newer data. Similarly, an SOA serial supports zone-version mechanisms but is not automatically the concurrency condition expected by a provider's management API. Use the documented management-plane version control. DNS records and SOA
After a successful management operation, authoritative answers and recursive answers are separate verification stages. A recursive resolver may still return an older positive or negative result. Preserve the provider response and timestamps, then inspect authoritative data before classifying a cache difference as a failed edit. Do not issue another overwrite solely because one cached lookup has not changed. Negative caching
If the write response is lost or times out, its outcome is uncertain. Read the current resource and relevant provider change evidence before deciding whether to retry. A blind retry can repeat or replace a change that already succeeded, especially when the client omitted a version condition. Record the uncertainty rather than declaring either success or failure without evidence.
Make rollback respect later changes
A baseline is essential recovery evidence, but it is not always safe to restore it wholesale. Another team may have made a valid change after your operation. Before rollback, read the current set, identify the specific effects of your change and propose a reverse change that preserves unrelated updates. Use the provider's supported version condition for that recovery operation too.
For a malformed SPF edit, restoring the old complete TXT set may erase a new verification token. For a DKIM migration, deleting a selector may affect queued or still-active messages. Confirm the rollback scope with the sender owner and preserve exact current and proposed data. Authentication semantics still matter after a technically correct concurrency check. DKIM verification dependencies
Concurrent-edit acceptance worksheet
Use this worksheet for each contested or high-risk record set. All fields are proposed and unfilled.
- Resource: provider/zone ___; exact owner/type ___; replacement unit ___; client and operation ___.
- Baseline: complete record set ___; TTL/properties ___; provider version marker ___; retrieval timestamp ___.
- Intent: requested additions ___; removals ___; preserved values ___; approving service owners ___.
- Write protection: supported conditional mechanism ___; condition supplied ___; overwrite behavior avoided ___.
- Conflict: exact sanitized result ___; freshly read state ___; other changes identified ___; reconciled approval ___.
- Outcome: provider operation result ___; uncertain response handling ___; authoritative answers ___; recursive observations ___.
- Recovery: current-state review ___; scoped reverse change ___; later edits preserved ___; rollback owner ___.
Fictional example: one SPF edit, one verification token
This scenario is fictional. Two teams read the TXT set at example.com. The mail team prepares an SPF update. The application team adds a verification token and publishes first. The mail team's stale payload contains the original SPF and older tokens but not the newly added token.
With the documented last-seen version condition, the stale update is rejected instead of silently replacing the newer set. The mail team reloads, confirms the application token is legitimate, prepares one valid revised SPF policy alongside all required verification records and resubmits with the current version after approval. It then verifies authoritative publication and the intended mail workflow.
The example demonstrates a recovery decision, not an executed test. Live client behavior, DNS answers, visual review and accountable owner release remain pending. The central rule is simple: a conflict is a reason to reconcile current state, not a reason to disable the protection that detected it.