• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question CAA-records & using underscores in records

mr-wolf

Silver Pleskian
Plesk Guru
Today I was very happy with the news that Plesk supports CAA-records. This happiness lasted only a few seconds when I realized that our primary DNS-server is running Plesk 12.5
The server can't be upgraded to a higher Plesk as it is running CentOS 5.11
I am already stripping it from tasks and hopefully it will be possible this year.

Will this enhancement reach Plesk 12.5.3 anytime soon?

What is happening with the inability of the GUI to use CNAMEs with underscores?
The GUI is preventing me to add these. Luckily the CLI still can.
Now there are more third parties implementing DKIM in a proper way (Office365).
Instead of giving a TXT-record, they now propose to use 2 CNAMEs
This gives them the ability to rotate their keys from time to time.

Mailchimp for one doesn't do this. I wonder how long it takes to find their 1024 private key?
They use 1 key for all their subscribers.
To be honest I do the same for my clients, but I have rotating keys that rotate each week. Furthermore I have less than 1000 customers.

I've heard a few days for keys that are shorter than that using an Amazon VPS.
If you do you can send DKIM signed messages pretending to be from any Mailchimp subscriber. Interesting as a tool for spearfishing.
They can of course stop business for a day and change their keys when they find out, but as things are now they will use this key for the next 5 years (this is my assumption). If it's used for spearfishing it probably takes very long to find out.

Anyhow. Plesk currently doesn't allow this better practice of using CNAMEs for that (in the GUI). It doesn't accept the underscore in the target part. So "_domainkey" can't be entered fhere. I can imagine there are more scenarios where a CNAME with underscores are needed. Please follow!
 
Last edited:
.....Even more disappointment.
Just read the release notes again and the CAA-support is for the preview of the upcoming release.....
This will be implemented in the other supported Plesk versions?

About the change of the behaviour in DNS..... (the underscore thing)
I expected a very well respected someone (no irony there) to chime in and send me away to the obscure catacombs of the Plesk voting system.

I don't agree....
It seems to be a valid statement to "let the people decide". I do agree with this most of the time, but this is not always the case.
Sometimes a change is needed just because it's the right thing to do even if most people are indifferent to it (indifference is quite often the reason) or against.
In my case I don't expect anyone to be against it, but I do expect a lot of indifference.

Sometimes a change is needed because it is just the right thing to do. And there's more to it.
I'm not talking about the very much welcomed enhancements with LetsEncrypt.
It's about a change that will probably take 20 minutes for a Plesk developer to implement. It will also be not some enhancement, but a correction of a previous made mistake.

Let me clarify this.....
I needed to wait more than 5 years before the Plesk team corrected the mistake they made when implementing the SRV-record.

For years it was impossible to use anything else than _tcp or _udp in the service field although there was NO mention of that anywhere in the RFC
RFC 2052 - A DNS RR for specifying the location of services (DNS SRV)

The clients of mine that were using a hosted exchange needed a record with _tls there and for them I needed to edit the zone file directly.
Whenever there was a change I had to manually change the zonefile again. With some embarassment I told them to remind me of it whenever they asked a change there,
I reported this to Plesk around 2007 but it took years for them to change it.

I think it should have been fixed within a month after reporting it as it's a mistake. This one is reported more than a year ago and it's ridiculous that some voting system is applied to it. I don't agree that we should expect this change (it's a correction, really) to reach us not sooner than 2022
 
Last edited:
Back
Top