Do not treat a Cloudflare DNS batch transaction as atomic global propagation

A successful database transaction can still reach the distributed DNS layer record by record.

Source facts

Cloudflare states that a DNS batch executes in one database transaction, while propagation through its distributed key-value system is not atomic. Batch operations run in delete, patch, put, then post order. Patches preserve unspecified fields; puts reset unspecified fields to their defaults. A failed operation prevents the database changes and returns the first error.

Source: Cloudflare — Batch record changes.

Applicability

This concerns the Cloudflare batch-record API and its documented commit and propagation semantics.

DSE recommendation

DSE recommends designing coordinated record changes to tolerate a transition with mixed old and new answers. Use patch versus replacement semantics intentionally and preserve an export of the prior records. Review operation order where names or record types conflict. Keep the batch small enough to inspect and match it to an approved change set rather than relying on a single success response as the full acceptance evidence. Ask the application owner to approve a mixed-answer transition before submitting the batch. Include operation order and patch-versus-put intent in the reviewed request description. Keep rollback values for each affected record so a successful database transaction is not mistaken for a service-wide atomic cutover.

Verification

In a controlled zone, apply a representative batch and inspect returned results, stored fields, and authoritative answers over time. Confirm unspecified settings stayed unchanged for patches and match intended defaults for replacements. Test the dependent service during the transition and retain the exact before-and-after records without exposing API credentials.

Official reference

Cloudflare — Batch record changes. Reviewed October 20, 2026.