dnsimple_zone_record Error: API returned a Validation Error for: value

[arenoir]

First thanks for maintaining a terraform provider to the dnsimple service. We have been using it for over a year. We did recently upgrade from 0.11.1 to 1.3.0 but have not run into any issues until today.

We use the dnsimple provider to add the necessary txt records to our dns server in our CI/CD pipeline.

Today we received the following error when trying to apply our configuration to a new workspace (every PR creates a new terraform workspace).

Error: API returned a Validation Error for: value
Txt must be wrapped between double-quotes ("")

The thing is nothing has changed with the configuration and the value is wrapped in double quotes.

resource "dnsimple_zone_record" "outbound_messaging_spf_record" {
  zone_name = var.domain
  name      = var.messaging_host
  value     = "v=spf1 include:spf.mandrillapp.com ?all"
  type      = "TXT"
  ttl       = 3600
}

Terraform Version

Terraform v1.6.2 on linux_amd64

• provider registry.terraform.io/dnsimple/dnsimple v1.3.0
• provider registry.terraform.io/hashicorp/google v5.2.0

Affected Resource(s)

• dnsimple_zone_record

Terraform Configuration Files

resource "dnsimple_zone_record" "outbound_messaging_spf_record" {
  zone_name = var.domain
  name      = var.messaging_host
  value     = "v=spf1 include:spf.mandrillapp.com ?all"
  type      = "TXT"
  ttl       = 3600
}

Debug Output

Error: API returned a Validation Error for: value

   with dnsimple_zone_record.outbound_messaging_spf_record,
   on main.tf line 320, in resource "dnsimple_zone_record" "outbound_messaging_spf_record":
   320:   value     = "v=spf1 include:spf.mandrillapp.com ?all"

Txt must be wrapped between double-quotes ("")

Expected Behavior

Terraform should apply all changes and the txt record should be created

Actual Behavior

Terraform exits on apply and the txt record is not created.

Steps to Reproduce

1. terraform apply

[arenoir]

Here is a response from DNSimple Customer Service

Apologies!

We are rolling out new validation schemes for DNS records to enhance our adoption of industry-standard formats.

In this case, TXT record contents containing whitespace characters must be wrapped between double quotes as per RFC 1035.

However, we have just rolled out an enhancement that will normalize your content to add the wrapper double quotes for you, so you should be able to provision that record now without having to modify anything on your end.

Please let me know if you need further assistance.

Don't know if this is correct but it does appear to be a server validation error.

[weppos]

Hi @arenoir, thanks for your feedback. We're making some internal changes on how we store TXT/SPF records, to enhance our RFC compliance. In theory, the correct value for the TXT record (when DNS-serialized, which is what we accept there as input) is a quoted string:

"v=spf1 include:spf.mandrillapp.com ?all"

hence your code should be:

value     = "\"v=spf1 include:spf.mandrillapp.com ?all"\"

Truth is, we've historically accepted both. We should continue to accept both for the foreseeable future. The team is investigating.

[arenoir]

Hi @weppos

Thanks for the follow up. I assumed double quotes meant " opposed to single quotes '. Anyhow I went ahead and tried escaping the second quote and have received the following error.

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ dnsimple_zone_record.outbound_messaging_verification_record, provider
│ "provider[\"registry.terraform.io/dnsimple/dnsimple\"]" produced an
│ unexpected new value: .value: was
│ cty.StringVal("mandrill_verify.22UeG0R4VF96iltuQk132Q"), but now
│ cty.StringVal("\"mandrill_verify.22UeG0R4VF96iltuQk132Q\"").
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

Any thoughts or workaround would be greatly appreciated.

Thanks

[tzahari]

Same issue here. we set the TXT record to: value = "v=spf1 include:amazonses.com -all"

But the value is in the dnsimple portal now: "v=spf1 include:amazonses.com -all" and should be without the "

What can I do?

[tzahari]

It seems that the dnsimple API and the webfrontend works now differently as before. We have an old TXT record without " and new TXT records gets additionally " in the value field.

[weppos]

Hi @tzahari,

But the value is in the dnsimple portal now: "v=spf1 include:amazonses.com -all" and should be without the "

Actually, this behavior is correct. As per RFC, the RData of a TXT record should be encoded in quotes. If you look at the response from a dig query, that's more evident:

dig TXT example.com

;; ANSWER SECTION:
example.com.        86400   IN  TXT "v=spf1 -all"
example.com.        86400   IN  TXT "wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn"

it is unfortunately common (and convenient) for TXT records (and a few others, such as HINFO and SPF) to colloquially refer to the non quoted version. And this leads to TXT implementations being notably inconsistent.

We used to accept both quoted and non quoted version, and normalize the data behind the scenes with a best effort. But this led to some transformation ambiguity, and subtle bugs.

Therefore, we are currently working to standardize the process and normalize values upfront so that what ends up being stored in the database, and transmitted to the public, is what our name servers will serve. This is the most common approach adopted by various DNS libraries and providers.

We have decided for the time being to continue accepting a non well-formed value. Which means you can still provide us a quoted or non quoted version. But in either cases, we'll normalize it to the RFC-compliant, quoted version.

We're working to publish additional documentation, and emails will go out this week to inform about some upcoming validation changes.

[weppos]

We have an old TXT record without " and new TXT records gets additionally " in the value field.

Correct. New records are now being explicitly normalized to be RFC compliant. We'll be applying this normalization to all existing entries in the upcoming weeks, but before taking any actions we'll be sending out emails to inform customers.

The only change we made so far is to make sure that new values are RFC compliant even if the input is not.

[weppos]

@tzahari @arenoir regarding this particular report, we agree the change of behavior is a bug and we have identified the issue that is dependent to some Terraform expectations.

The team is working to address the issue, and release a version that will continue to accept both well formed and non-well formed TXT values. We'll post updates on this ticket as soon as it's ready. We are on it right now.

[AGS4NO]

@arenoir @tzahari Thanks for the report. Record normalization has been addressed in #167 and released as v1.3.1

Please let us know if you encounter any other issues.

[tzahari]

Hi @AGS4NO, it is now woking as expected! Thank you Best Regards Thomas

[arenoir]

Hi @AGS4NO thanks for the quick fix! Everything is back in working order.