0

As far as I understand, there should be no problems with using CNAME or DNAME records in connection with DKIM. That is, while the DKIM record for verifiying a mail from someone@example.com wants to be retrieved as a TXTRR under some.selector._domainkey.example.com, it might well be that some redirection occurs, such as

  • some.selector._domainkey.example.com. CNAME another-selector._domainkey.example.net. or
  • _domainkey.example.com. DNAME _domainkey.example.net. or
  • _domainkey.example.com. DNAME bar.example.net.

that is, the DNS resolving might go via a CNAME or DNAME into a completely unrelated domain and even, as the third example clarifies, lead to records that do not involve the well-known DKIM-specific _domainkey part.

Tome, this seems to be totally legit as far as DNS is concerned. And as DKIM is theoretically not restricted to retrieving keys by DNS, any Verifier should not care.

Of course, this does somewhat increase the DNS load and may slow down mail delivery by a few milliseconds. But this technique may come in handy when it is easier to change and update records under example.net than under the main domain example.com.

So my questions are:

  • Is this really "legal"?
  • Is it fully supported, i.e., do (widespread, non-obscure) implementation behave accordingly or are perhaps some known ti "deduct trust points" for such redirections? Or perhaps do some even then reject signatures altogether because they believe they are for the wrong domain?
  • Are there other security considerations that speak against this?
  • Unfortunately DNAME is both rarely used and with edge cases/bad implementation, one point being the consequence of the other or the opposite. You shouldn't have problems with CNAME records but can have with DNAME. All of this have also consequences if you want to use DNSSEC. PS: please stick to RFC2606 when obfuscating names, do not invent others. – Patrick Mevzek Jul 26 at 2:43
1

Yes, it's fully supported and widespread

DKIM doesn't implement DNS itself, but its DNS binding (RFC 6376, 3.6.2) is depending on the DNS, and it's using the namespace selector._domainkey.example.com. for TXT records. As CNAMEs and DNAMEs are specified in DNS RFCs, outside the scope of DKIM, they are followed by the DNS when querying for TXT records. DKIM simply inherits this behavior.

CNAMEs are widely in use on implementations where a third party email provider needs to be able to rotate the DKIM keys independently, e.g. Microsoft O365, AWS, SendGrid, ConvertKit & MailChimp.

There's no so much examples on DNAMEs, but it should work as well. One reason for why DNAMEs aren't used that much is that a purpose of the DKIM selectors is to enable multiple sources to send signed email for the same domain, e.g. both your mail system and your newsletter system. With a DNAME you would make an alias for every selector under _domainkey.example.com., pointing them all to a single service provider. It's simply not that useful.

There's nothing in DKIM specification that would require treating records that are fetched from external domains less trustworthy. And why would they, as it's the domain itself that delegates the trust by publishing such records.

Security considerations

First, it's worth to notice that DKIM is not even designed for strong authenticity, per RFC 6376, 8.5:

8.5. Attacks against the DNS

Since the DNS is a required binding for key services, specific attacks against the DNS must be considered.

While the DNS is currently insecure [RFC3833], these security problems are the motivation behind DNS Security (DNSSEC) [RFC4033], and all users of the DNS will reap the benefit of that work.

DKIM is only intended as a "sufficient" method of proving authenticity. It is not intended to provide strong cryptographic proof about authorship or contents. Other technologies such as OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements.

Regarding DNSSEC, using CNAMEs or DNAMEs to other domains do decrease the security. E.g. if your example.com is a DNSSEC signed zone, but selector1._domainkey.example.com. is a CNAME to Microsoft's selector1-example-com._domainkey.contoso.onmicrosoft.com.. Currently onmicrosoft.com. is not DNSSEC signed. However, DKIM does follow these records, as full DNSSEC chains aren't required.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.