Cloudflare record resource inconsistently handles zone names in DNS record updates

[varunt-git-pb]

Confirmation

• This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
• I have searched the issue tracker and my issue isn't already found.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

• Terraform version: 1.8.2
• Cloudflare provider version: 4.19.0

Affected resource(s)

There appears to be an inconsistency in how the Cloudflare provider handles zone names when updating DNS records. This issue affects the cloudflare_record resource.

Terraform configuration files

resource "cloudflare_record" "example_proxy" {
  zone_id = data.azurerm_key_vault_secret.exampleKV["zone"].value
  name    = !local.is_pb || lower(var.environment) == "prod" ? "proxy" : "proxy.${var.region}"
  type    = "CNAME"
  value   = var.cluster_cname_value
  proxied = true
  ttl     = 1
}

Link to debug output

NA

Panic output

NA

Expected output

The expected behavior would be consistent handling of the zone name. Either:

1. Both sides should include the full zone name:
   "cluster.ie.pointsbet.com" -> "cluster.ie.pointsbet.com"

2. Or both sides should exclude the zone name:
   "cluster.ie" -> "cluster.ie"

so the plan in full should look like below.

cloudflare_record.sf_proxy must be replaced
resource "cloudflare_record" "example_proxy" {
created_on = "2023-05-11T05:40:56.65566Z" -> (known after apply)
hostname = "proxy.ie.pointsbet.com" -> (known after apply)
id = "12345" -> (known after apply)
metadata = {
"auto_added" = "false"
"managed_by_apps" = "false"
"managed_by_argo_tunnel" = "false"
} -> (known after apply)
modified_on = "2023-05-11T05:40:56.65566Z" -> (known after apply)
name = "proxy.ie.pointsbet.com" -> "proxy.ie.ie.pointsbet.com" # forces replacement
proxiable = true -> (known after apply)
- tags = [] -> null
}

Actual output

When updating a DNS record, the provider seems to inconsistently handle the zone name portion of the hostname:

1. For the existing record, it uses the full hostname including the zone name:
   "cluster.ie.pointsbet.com"

2. For the replacement, it drops the zone name entirely:
   "cluster.ie"

This behavior is seen in the plan output:
~ name = "cluster.ie.pointsbet.com" -> "cluster.ie" # forces replacement

This is how it looks currently in a full plan,

Steps to reproduce

1. Create a Cloudflare zone (e.g., "ie.pointsbet.com")
2. Create a DNS record in this zone (e.g., "cluster.ie.pointsbet.com")
3. Attempt to update this record using Terraform

Additional Context

This issue was observed in a Terraform plan output. The inconsistency in handling the zone name could lead to unexpected behavior or errors when applying the Terraform configuration.

Additional factoids

This issue was observed in a Terraform plan output. The inconsistency in handling the zone name could lead to unexpected behavior or errors when applying the Terraform configuration.

References

NA

[github-actions]

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.