Rrdatas not ordered correctly by Google Cloud DNS

Question

I am setting up a DKIM record which has more than 255 characters, in Google Cloud DNS. I have split it into 2 values as recommended in https://support.google.com/a/answer/173535. This is how it shows in terraform.

$ terraform show
google_dns_record_set.siteground_dkim:
  id = rightleadsio/default._domainkey.rightleads.io./TXT
  managed_zone = rightleadsio
  name = default._domainkey.rightleads.io.
  project = rlautomation-156511
  rrdatas.# = 2
  rrdatas.0 = "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApRvh3MHFry0h4WxY+flc29BDr750WmoaWdwQZwZ56HcdBE+wu6dd849IbMYT6uSCqT3SHpU2D6wVe9B3zlz0H4aZ75GUOTRl72FiTv5Q4Ru+NQ/4s1lwtgcyoJUnfVkxm8fT7qZiRwr+F7Wf7IqvNNVfPG2+0q5QUlgeu2ddXxjipaPMzIv1hxiHF75Pgse85"
  rrdatas.1 = "zb3PdAsa8wHMhyvHMkS6wwXTiW8Mll2KFyLMjtq5RL56VE5ew+aY1wk6CjpKgvoCXbDJGc3pIa2FQQFhiVwNY/HJBEArM4yoM1y98RF7F7VgWYkLYqpvWbnQtaENcS67NGynJ1ViLIELLfINLRHywIDAQAB"
  ttl = 3600
  type = TXT

But, when I query this using dig or mxtoolbox, it shows rrdatas.1 as the first value and rrdatas.0 as the second one, thus not assembling the value correctly.

$ dig +short txt default._domainkey.rightleads.io
"zb3PdAsa8wHMhyvHMkS6wwXTiW8Mll2KFyLMjtq5RL56VE5ew+aY1wk6CjpKgvoCXbDJGc3pIa2FQQFhiVwNY/HJBEArM4yoM1y98RF7F7VgWYkLYqpvWbnQtaENcS67NGynJ1ViLIELLfINLRHywIDAQAB"
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApRvh3MHFry0h4WxY+flc29BDr750WmoaWdwQZwZ56HcdBE+wu6dd849IbMYT6uSCqT3SHpU2D6wVe9B3zlz0H4aZ75GUOTRl72FiTv5Q4Ru+NQ/4s1lwtgcyoJUnfVkxm8fT7qZiRwr+F7Wf7IqvNNVfPG2+0q5QUlgeu2ddXxjipaPMzIv1hxiHF75Pgse85"

Am I doing something wrong? Or is it Google Cloud DNS issue? Is there some way around this without changing the key, since that isn't within my control.

Have you checked if Terraform will do this for you natively? i.e. put the full, long record into Terraform and let it handle things? — ceejayoz, Oct 24 '18 at 15:22
There is a [similar question](https://serverfault.com/q/759849/214507) about SPF. I don't know if the answer for DKIM is going to be the same as it is for SPF. — kasperd, Oct 24 '18 at 15:43
There is no guarantee that DNS records sets for a given name will be served in a particular order. Nameservers round-robin these reponses all the time - in fact, I can see that happening with your record now with my resolver - the 2 records are reversed in the response I get, compared to your example response. Why does it matter what order they are in? — guzzijason, Oct 24 '18 at 15:45
Ah, I think the problem here is that you are creating two separate TXT records, rathe than one TXT with separate string fields, which is *I think* what you want. — guzzijason, Oct 24 '18 at 15:54
This may be a useful example as well of combining records: https://help.blacknight.com/hc/en-us/articles/212512389-Creating-large-SPF-records-with-many-entries — guzzijason, Oct 24 '18 at 15:57
@guzzijason you are right. I just need one rdata with multiple strings, not multiple rdata. And gcloud DNS is accepting that. I've changed that and testing if it works now. — mehulved, Oct 25 '18 at 04:58
@guzzijason I can confirm that is the correct solution. The DKIM check is passing in the email now. Thank you. — mehulved, Oct 25 '18 at 06:32

score 2 · Accepted Answer · answered Oct 25 '18 at 21:32

It does appear that the DKIM value has been added in the wrong way, yes.

It looks like you have added two separate TXT records with one string value each, not one TXT record with both strings. (Yes, TXT records are multi-valued and the length limitation is per value.)

The latter is how the DKIM spec allows for long values, it is defined such that if a TXT record has multiple values these should be concatenated into one long string before it is parsed as a DKIM value.
Multiple separate TXT records however, are not supposed to be combined in any way.

Ie, as the Google Support article says, a long string needs to be split into shorter parts, but these parts should still all be in one single record.
(This is the requirement on the DNS level, in some cases the interface one interacts with abstracts this behavior away.)

In master file format your record would be:

default._domainkey.rightleads.io. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApRvh3MHFry0h4WxY+flc29BDr750WmoaWdwQZwZ56HcdBE+wu6dd849IbMYT6uSCqT3SHpU2D6wVe9B3zlz0H4aZ75GUOTRl72FiTv5Q4Ru+NQ/4s1lwtgcyoJUnfVkxm8fT7qZiRwr+F7Wf7IqvNNVfPG2+0q5QUlgeu2ddXxjipaPMzIv1hxiHF75Pgse85" "zb3PdAsa8wHMhyvHMkS6wwXTiW8Mll2KFyLMjtq5RL56VE5ew+aY1wk6CjpKgvoCXbDJGc3pIa2FQQFhiVwNY/HJBEArM4yoM1y98RF7F7VgWYkLYqpvWbnQtaENcS67NGynJ1ViLIELLfINLRHywIDAQAB"

Not like what you appear to have now:

default._domainkey.rightleads.io. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApRvh3MHFry0h4WxY+flc29BDr750WmoaWdwQZwZ56HcdBE+wu6dd849IbMYT6uSCqT3SHpU2D6wVe9B3zlz0H4aZ75GUOTRl72FiTv5Q4Ru+NQ/4s1lwtgcyoJUnfVkxm8fT7qZiRwr+F7Wf7IqvNNVfPG2+0q5QUlgeu2ddXxjipaPMzIv1hxiHF75Pgse85"
default._domainkey.rightleads.io. 3600 IN TXT "zb3PdAsa8wHMhyvHMkS6wwXTiW8Mll2KFyLMjtq5RL56VE5ew+aY1wk6CjpKgvoCXbDJGc3pIa2FQQFhiVwNY/HJBEArM4yoM1y98RF7F7VgWYkLYqpvWbnQtaENcS67NGynJ1ViLIELLfINLRHywIDAQAB"

As more of a side note, in DNS in general there is no order defined for the records within an RRset (the set of records that have the same owner name, class and type).
It is expected that the order you used when adding records may not necessarily be maintained (as in your example), but this is of no concern in the context of DKIM as the whole DKIM value must be within the same TXT record anyway.

Rrdatas not ordered correctly by Google Cloud DNS

1 Answers1