Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dnsimple_zone_record Error: API returned a Validation Error for: value #165

Closed
arenoir opened this issue Oct 25, 2023 · 11 comments · Fixed by #167
Closed

dnsimple_zone_record Error: API returned a Validation Error for: value #165

arenoir opened this issue Oct 25, 2023 · 11 comments · Fixed by #167
Assignees
Labels

Comments

@arenoir
Copy link

arenoir commented Oct 25, 2023

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
Copy link
Author

arenoir commented Oct 27, 2023

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
Copy link
Member

weppos commented Oct 31, 2023

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
Copy link
Author

arenoir commented Oct 31, 2023

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
Copy link

tzahari commented Nov 2, 2023

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
Copy link

tzahari commented Nov 2, 2023

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
Copy link
Member

weppos commented Nov 2, 2023

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
Copy link
Member

weppos commented Nov 2, 2023

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
Copy link
Member

weppos commented Nov 2, 2023

@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
Copy link
Contributor

AGS4NO commented Nov 2, 2023

@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
Copy link

tzahari commented Nov 6, 2023

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

@arenoir
Copy link
Author

arenoir commented Nov 15, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants