Terraform plan with azurerm_dns_a_record fails when parsing existing dns record with azurerm 3.19.1

[stusklinar]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

1.2.7

AzureRM Provider Version

3.19.1

Affected Resource(s)/Data Source(s)

azurerm_dns_cname_record

Terraform Configuration Files

resource "azurerm_dns_cname_record" "cname" {
  name                = "hostbinding.test.com"
  zone_name           = "testZone"
  resource_group_name = "rg"
  ttl                 = 60
  record              = "cname"
}

Debug Output/Panic Output

│ Error: parsing "/subscriptions/ce204445-xxxx-xxxx-xxxx-25677e054a2c/resourceGroups/dev-dns-zones/providers/Microsoft.Network/dnszones/dev.mkmapps.com/TXT/asuid.api-gateway.dev.xxxx.com": parsing segment "staticDnsZones": expected the segment "dnszones" to be "dnsZones"

Expected Behaviour

Terraform plan should finish successfully.
With azurerm 3.18.0 it works fine.
There where no changes to the dns config, aside from upgrading the provider version to 3.19.1

Works fine on some providers - but they were new deployments - this has existing 3.18.0 state

Actual Behaviour

Fails to apply

Steps to Reproduce

Run terraform plan or terraform apply with an existing dns_a_record after upgrading to azurerm 3.19.1

Important Factoids

Seems to affect deployments that have upgraded

References

[Run terraform plan or terraform apply with an existing dns_a_record after upgrading to azurerm 3.19.0

](#18039)

[mattduguid]

issue for us running pipeline with v3.19.x/v3.20.0 and existing state with CNAME record created using earlier version v3.13.0, pinned back to v3.18.0 and worked around for now

[gogonaft]

issue for us running pipeline with v3.19.x/v3.20.0 and existing state with CNAME record created using earlier version v3.13.0, pinned back to v3.18.0 and worked around for now

for me this did not work. I went ahead and changed respected TFSTATE file where "dnszone" resources were and updated "id": "/subscriptions/XXX/resourceGroups/YYY/providers/Microsoft.Network/dnszones/..." to "id": "/subscriptions/XXX/resourceGroups/YYY/providers/Microsoft.Network/dnsZones/...". After that azurerm >=3.19.1 versions work for me.

[gogonaft]

Hashicorp, fix the bug it's ridiculous.

[twink0r]

We build a small script to "fix" this.
In this case, we only use child modules and nothing in root. If you created resources in the root module, you need a small adjustment in the Python Script in Line 17.

[doug2901]

I'm facing this problem too, I changed to v3.18.0, and it seems to be working fine.

[oleksii-goi]

Issue still exist in azurerm v.3.29.1 ##19119

[MarkTallentire]

I have this issue when using terraform import

terraform import "azurerm_dns_zone.example" "/subscriptions/${subId}/resourceGroups/${resourceGrpId}/providers/Microsoft.Network/dnszones/${dnsZone}

parsing segment "staticDnsZones": expected the segment "dnszones" to be "dnsZones"

Version 3.39.1

[tombuildsstuff]

@MarkTallentire as the error message returned from terraform import is suggesting, we're expecting the casing for dnszones to be dnsZones - since Terraform is expecting a given Resource ID format we show the expected format for the Resource ID for each resource in the documentation for that resource, for example for azurerm_dns_zone:

terraform import azurerm_dns_zone.zone1 /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/mygroup1/providers/Microsoft.Network/dnsZones/zone1

As such you should be able to fix this by updating the casing for dnszones to match dnsZones as is being expected at import time here.

Thanks!

[tombuildsstuff]

Taking a look through here, since #18692 adds a state migration to fix the casing for any existing azurerm_dns_zone resources that Terraform is tracking, I believe the original issue is resolved for existing resources and as such I'm going to close this out.

However if you're still seeing issues here I'd recommend double-checking the value being provided here, as Terraform is now validating the Resource ID format matches what we're trying to parse, the error message should be highlighting which segment doesn't match (and how to fix that) - as such updating that segment to the expected casing (also shown in the import section of the documentation for the relevant resource) should fix this.

Thanks!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.