Cloudflare Deprecated In-Place DNS Record Type Changes. Here's What Breaks

I manage a few client domains through Terraform, mostly because it's easier to review a DNS change in a pull request than to trust everyone to click the right thing in a dashboard. A few weeks ago, I needed to switch a record from a CNAME to an A record. I ran a plan, expected a small in-place update, and instead saw this:

# cloudflare_dns_record.example must be replaced
-/+ resource "cloudflare_dns_record" "example" {
    name = "test.example.com"
  ! type = "CNAME" -> "A"
    # forces replacement
}

That word "replaced" is doing a lot of work in that sentence. It means Terraform is about to delete the record, then create a new one. Not update it. Delete it, then create it. If this is a record anyone depends on, that's a real gap where the DNS entry simply doesn't exist. Here's why this changed, and how I'd handle it if you run into the same thing.

Cloudflare deprecated in-place record type changes

According to Cloudflare's own API deprecations page, changing the type of an existing DNS record through the API stopped being supported after June 30, 2026. Cloudflare's reasoning is fair, honestly. Swapping a record's type usually means the content needs to change too, and treating that as a simple update was always a bit of a fiction. Their documentation is direct about it: the type change "is not a natural update operation," and the supported path now is to delete the old record and create a new one in its place. The Terraform provider picked this up too. A real report on the provider's GitHub issue tracker shows exactly the behavior I hit. What used to be a quiet update is now a delete-and-recreate, every time.

Why a few seconds of downtime matters more than it sounds like

For a low-traffic record, a brief gap probably goes unnoticed. But if this is your apex domain, your API endpoint, or anything with a short TTL that clients check often, a delete-then-create cycle can produce real DNS resolution failures during the exact window the record doesn't exist. It's not a long outage. It's also not zero. I'd treat any record type change through Terraform as a deliberate, planned action now, not a routine one you bundle in with five other changes and apply without thinking about timing.

How I handle it now

Instead of just changing the type in place and running apply, I add the new record as a separate resource first, apply that, confirm it resolves correctly, and only then remove the old one:

resource "cloudflare_dns_record" "example_new" {
  zone_id = var.zone_id
  name    = "test.example.com"
  type    = "A"
  content = "203.0.113.10"
  ttl     = 300
}

Once that's live and verified, I remove the old CNAME resource in a second, separate apply. This costs a couple of extra minutes. It also means there's never a moment where the record doesn't exist at all, since both can briefly coexist before the old one goes away.

If you're still on the older provider

Worth checking while you're in there. Cloudflare's Terraform provider also renamed its core DNS resource, from cloudflare_record to cloudflare_dns_record, as part of its version 5 release. If your configuration still references the old resource name, you're not just dealing with the type-change behavior above, you're also carrying a separate migration that's worth doing on its own, deliberately, rather than mixed in with an unrelated DNS change.

The simple version, if you don't use Terraform

If you manage DNS by hand through the Cloudflare dashboard, none of this changes your workflow much. You were already deleting and recreating a record to change its type in most dashboard flows anyway. This mostly matters if your DNS is managed as code, where the tool used to paper over that distinction for you, and now it doesn't.

I verified this directly against Cloudflare's official API deprecations documentation and a real Terraform provider issue as of August 2026.