DXE-3390 Modifying a DNS TXT record with multiple values shows incorrect plan output

[brucep-care]

We are seeing an issue with DNS records where an attempt to modify a list of values fails. Take for example, a TXT record for example.com that contains two distinct values:

$ dig +short example.com TXT
"mandrill_verify.abcdefghijklmnop"
"v=spf1 include:spf.mandrillapp.com -all"

Try to edit one of these entires, say by adding include:mail.zendesk.com into the second value. The resulting plan output is completely wrong. See below for details.

Terraform Version

$ terraform -v
Terraform v1.3.7
on linux_amd64
+ provider registry.terraform.io/akamai/akamai v5.4.0
+ provider registry.terraform.io/hashicorp/aws v3.71.0

Affected Resource(s)

• akamai_dns_record

Terraform Configuration Files

resource "akamai_dns_record" "example_com_TXT" {
    zone = example.com
    recordtype = "TXT"
    target = [ "mandrill_verify.abcdefghijklmnop", "v=spf1 include:spf.mandrillapp.com include:mail.zendesk.com -all" ]
    name = "example.com"
}

Output

Terraform will perform the following actions:

  # akamai_dns_record.example_com_TXT will be updated in-place
  ~ resource "akamai_dns_record" "example_com_TXT" {
        id         = "example.com#example.com#TXT"
        name       = "example.com"
      ~ target     = [
            "mandrill_verify.abcdefghijklmnop",
          - "v=spf1 include:spf.mandrillapp.com -all",
          + "mandrill_verify.abcdefghijklmnop",
        ]
        # (4 unchanged attributes hidden)
    }

Expected Behavior

The first value (mandrill_verify.abcdefghijklmnop) should remain unchanged.
The second value (v=spf1...) should be replaced with a new value containing the desired change.

Actual Behavior

The provider is attempting to add a second copy of the first value, and completely delete the second value.

Steps to Reproduce

1. Create or choose an existing DNS TXT record with two values
2. Edit the HCL to modify one of those values
3. Run terraform plan and observe the proposed changes.

[lsadlon]

Hi @brucep-care

Thanks for reporting that issue, we will investigate it and come back to you.

BR,
Lukasz

[lkowalsk-akamai-com]

Hi @brucep-care we are not able to reproduce this issue. With recent 5.5.0 release we introduced some changes in this area. Please kindly test it with new version and let us know if it is still and issue for you.

[brucep-care]

@lkowalsk-akamai-com well this is something I've never encountered before. We actually use terraform's JSON configuration syntax in-house. We have a suite of our own tools that generates JSON that we then feed to terraform. When I encountered this bug it was while using our JSON environment, but the report I filed included HCL that I put together but didn't actually test, assuming it would generate the same result. Well it doesn't.

Here's the HCL that corresponds to the TXT record for our getgalore-dev.com zone that we use for development work. I've modified the SPF record to add include: example.com to it:

terraform {
  required_providers {
    akamai = {
      source  = "akamai/akamai"
      version = "~> 5.5.0"
    }
  }
}

# Configure the Akamai Provider
provider "akamai" {
  edgerc = "~/.edgerc"
  config_section = "default"
}


resource "akamai_dns_record" "getgalore-dev_com_getgalore-dev_com_TXT" {
    zone = "getgalore-dev.com"
    name = "getgalore-dev.com"
    recordtype = "TXT"
    target = ["\"mandrill_verify.ZFHJUYd75BMLToDmIZWsqg\"", "\"v=spf1 include:spf.mandrillapp.com include:mail.zendesk.com include:example.com -all\""]
    ttl = 1800
}

The above HCL shows that terraform wants to make the correct change:

$ terraform plan
akamai_dns_record.getgalore-dev_com_getgalore-dev_com_TXT: Refreshing state... [id=getgalore-dev.com#getgalore-dev.com#TXT]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # akamai_dns_record.getgalore-dev_com_getgalore-dev_com_TXT will be updated in-place
  ~ resource "akamai_dns_record" "getgalore-dev_com_getgalore-dev_com_TXT" {
        id         = "getgalore-dev.com#getgalore-dev.com#TXT"
        name       = "getgalore-dev.com"
      ~ target     = [
            "\"mandrill_verify.ZFHJUYd75BMLToDmIZWsqg\"",
          - "\"v=spf1 include:spf.mandrillapp.com include:mail.zendesk.com -all\"",
          + "\"v=spf1 include:spf.mandrillapp.com include:mail.zendesk.com include:example.com -all\"",
        ]
        # (4 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Now, this is what the same thing looks like in JSON. This is the current state of the DNS record in question, so terraform plan shows no propsed changes:

$ cat terraform.tf.json
{
  "resource": {
    "akamai_dns_record": {
      "getgalore-dev_com_getgalore-dev_com_TXT": {
        "name": "getgalore-dev.com",
        "recordtype": "TXT",
        "target": [
          "v=spf1 include:spf.mandrillapp.com include:mail.zendesk.com -all",
          "mandrill_verify.ZFHJUYd75BMLToDmIZWsqg"
        ],
        "ttl": 1800,
        "zone": "getgalore-dev.com"
  }  }
  },
  "terraform": {
    "required_providers": {
      "akamai": {
        "source": "akamai/akamai",
        "version": "~> 5.5.0"
      }
    }
  }
}

$ terraform plan
akamai_dns_record.getgalore-dev_com_getgalore-dev_com_TXT: Refreshing state... [id=getgalore-dev.com#getgalore-dev.com#TXT]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

If I edit the JSON file to modify the SPF record as I did with the HCL above then it shows the wrong records being modified:

$ cat terraform.tf.json
{
  "resource": {
    "akamai_dns_record": {
      "getgalore-dev_com_getgalore-dev_com_TXT": {
        "name": "getgalore-dev.com",
        "recordtype": "TXT",
        "target": [
          "v=spf1 include:spf.mandrillapp.com include:mail.zendesk.com include:example.com -all",
          "mandrill_verify.ZFHJUYd75BMLToDmIZWsqg"
        ],
        "ttl": 1800,
        "zone": "getgalore-dev.com"
  }  }
  },
  "terraform": {
    "required_providers": {
      "akamai": {
        "source": "akamai/akamai",
        "version": "~> 5.5.0"
      }
    }
  }
}

$ terraform plan
akamai_dns_record.getgalore-dev_com_getgalore-dev_com_TXT: Refreshing state... [id=getgalore-dev.com#getgalore-dev.com#TXT]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # akamai_dns_record.getgalore-dev_com_getgalore-dev_com_TXT will be updated in-place
  ~ resource "akamai_dns_record" "getgalore-dev_com_getgalore-dev_com_TXT" {
        id         = "getgalore-dev.com#getgalore-dev.com#TXT"
        name       = "getgalore-dev.com"
      ~ target     = [
            "\"mandrill_verify.ZFHJUYd75BMLToDmIZWsqg\"",
          - "\"v=spf1 include:spf.mandrillapp.com include:mail.zendesk.com -all\"",
          + "mandrill_verify.ZFHJUYd75BMLToDmIZWsqg",
        ]
        # (4 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Given this behavior I now wonder if it's a bug in terraform itself that we're running into. I would expect it to ingest the HCL And JSON identically. We're currently on 1.3.7 and it looks like 1.6.6 is the current version.

[brucep-care]

I just tested this with version 1.6.6 of terraform and it's showing the same issue when using JSON:

$ ../terraform -v
Terraform v1.6.6
on linux_amd64
+ provider registry.terraform.io/akamai/akamai v5.5.0

$ ../terraform plan
akamai_dns_record.getgalore-dev_com_getgalore-dev_com_TXT: Refreshing state... [id=getgalore-dev.com#getgalore-dev.com#TXT]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # akamai_dns_record.getgalore-dev_com_getgalore-dev_com_TXT will be updated in-place
  ~ resource "akamai_dns_record" "getgalore-dev_com_getgalore-dev_com_TXT" {
        id         = "getgalore-dev.com#getgalore-dev.com#TXT"
        name       = "getgalore-dev.com"
      ~ target     = [
            "\"mandrill_verify.ZFHJUYd75BMLToDmIZWsqg\"",
          - "\"v=spf1 include:spf.mandrillapp.com include:mail.zendesk.com -all\"",
          + "mandrill_verify.ZFHJUYd75BMLToDmIZWsqg",
        ]
        # (4 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

So I'm back to thinking this might still be a bug in the Akamai provider, just when using JSON input as opposed to HCL input.

[lkowalsk-akamai-com]

Thank you for the additional details. We are still working on this and will let you know once we find a solution.

[mgwoj]

Hi @brucep-care, this issue should be fixed in the recent release.

[brucep-care]

Hi @mgwoj. Thanks for letting me know. I just tested the above and it does appear to be resolved. However there still appears to be an issue. I just tested this out with apex TXT record for our primary domain care.com which is more complex than the one I used when submitting the original bug report.

Please let me know if you'd like me to open a new issue with the details of our care.com zone record or if I should add it as another comment to this one.

Edit: This particular case appears to revolve around a TXT string that is greater than 255 characters. To work around that character limit it's common to quote the string, so in Terraform the target can look something like this:

    target = [... "\"v=spf1 ip4:208.118.226.0/26 include:servers.mcsv.net include:spf.mandrillapp.com include:mg-spf.greenhouse.io include:spf.protection.outlook.com include:_spf.salesforce.com\" \" include:mail.zendesk.com include:_spf.atlassian.net include:318630.spf01.hubspotemail.net ~all\"", "\"docker-verification=a8b7a295-5e0b-40b6-b18d-0cf850efa8ca\"" ...]

That's the part of the terraform record that defines our SPF record , and since it's > 255 characters it's split into two quoted & escaped strings that are enclosed in another set of quotes. This is exactly how the record was generated by the Akamai CLI when I invoked akamai terraform export-zone.

If I delete that line from the terraform configuration then the provider does appear to modify the record properly. With that line in the configuration it results in more invalid changes to the other records.

[mgwoj]

Hello,

Please be so kind a create a new issue