• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Forwarded to devs migration of DNS killed all my DKIM cnames

mr-wolf

Silver Pleskian
Plesk Guru
TITLE:
migration of DNS killed all my DKIM cnames
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Plesk 17.8 6 / CentOS Linux 7.4.1708
PROBLEM DESCRIPTION:
On my Plesk 12.5 server I had several domains with CNAMES containing _domainkey

None of these were migrated.

It's not only the CNAMES with an underscore in the target (for Office365), but also CNAMES for mailchimp.

Code:
k1._domainkey.client.com.               IN CNAME        dkim.mcsv.net.
STEPS TO REPRODUCE:
Create CNAMES for DKIM-keys.

These typically have this format

<selector>._domainkey.domain.com IN CNAME dkim.mcsv.net.

or

selector1._domainkey.plesk.com IN CNAME selector1-plesk-com._domainkey.plesk.onmicrosoft.com.​
ACTUAL RESULT:
On the target server these are "forgotten"​
EXPECTED RESULT:
Have them migrated​
ANY ADDITIONAL INFORMATION:
Beware not to link this 1:1 to the other bug that makes it impossible to create CNAMEs with an underscore in the target.
To start this is a GUI issue..
But also the mailchimp cnames are NOT migrated. These do NOT have an underscore in the target, but only in the source.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Confirm bug
 
The issue with DNS records with an underscore has been reported several years ago and has never been given priority.
All DKIM DNS-records were lost after the migration.

This resulted in mail getting quarantined for all our client's recipients because they were getting signed by Microsoft whilst no public key was published in DNS.
My own DKIM-scheme worked because each hour the DKIM-configuration is checked and signing automatically stopped.

Please correct your past mistake by giving this priority now!

I only need this feature of migrating my DNS-server once in 5 years.
I should have been able to rely on it and it turns out I could not.
I have nothing to gain when it's fixed really as I will not be needing it for a long while.

Still take it serious for your other users and fix everything related to that underscore.
This isn't something that can be moved to a later date. It's the core of what Plesk is about.
I should be able to manage my DNS and use add, migrate any valid record.

The programmer that is writing these sanity checks should check the RFC's better before he's invalidating certain combinations.
 
Last edited:
Thank you for report! Issue was confirmed and request PPPM-7401 was submitted.
 
We second this bug report, its been there for years but had hoped it would be fixed with Onyx 17.5 now that you have DKIM support... We look forward to seeing PPPM-7401 appear on the change log. Its annoying as we have a lot of clients using Office 365 and more and more are requesting us to manually add the required records on the command line.

sample of requested record, it doesn't like the ._ in the value field.
Domain Name Value

example.com.au selector1._domainkey selector1-example-com-au._domainkey.yarralink.onmicrosoft.com
 
Hi @IgorG

I'm glad this bug has been fixed, but as I already wrote earlier it doesn't help me much as I will not be needing this for another 5 years. I don't need to migrate my authoritative DNS-server that often.

I think you're referring to the bug I reported in my first post. The one that skips all the DNS-records upon migration.

I think @burnley is referring to the bug that makes it impossible to use the GUI to make CNAMEs that point to records with an underscore.
Those are needed for Office365

I took this thread to also mention the bug in GUI.

That one is not even fixed in 17.8.6 and it now becomes really annoying.
I can see no reason for such a bug to stay in the package for all those years.
I have probably spent more time writing about this bug than the programmer needs to fix it.

It is rejecting a perfectly normal RFC record and it is also accepted by the CLI.
It just is rejected by the webinterface.

upload_2017-12-20_9-17-38.png
 
Last edited:
But it's not very reasonable that we have to spend time to create workarounds for getting these records each and every time we need to handle such a domain while a Plesk programmer only has to work one morning to fix the mistake he made 5 years ago.
This bug has been reported a long time ago and I've even seen the suggestion to vote for it...... That's cheeky...
It sounds very democratical, but it should not work that way.
Sometimes things need to be fixed just because it's the right way to do it....
 
Back
Top