Facebook
Twitter
-
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
@Dave_G
There is no need to.
I can understand your desire, but DKIM is something that can be activated in a "no worries, mate" mindset: most mail providers, like Google, do not really bother about that.
It is more common (nowadays) to have a good look at SPF and DMARC.
But to answer your question: you can add DNS records via CLI and do some work-arounds, but I would strongly advice against that.
After all, at each update (i.e. micro-update and upgrade) you will risk to encounter severe problems.
In short, my advice: leave as is.
Regards.....
There is no need to.
I can understand your desire, but DKIM is something that can be activated in a "no worries, mate" mindset: most mail providers, like Google, do not really bother about that.
It is more common (nowadays) to have a good look at SPF and DMARC.
But to answer your question: you can add DNS records via CLI and do some work-arounds, but I would strongly advice against that.
After all, at each update (i.e. micro-update and upgrade) you will risk to encounter severe problems.
In short, my advice: leave as is.
Regards.....
Hi Trialotta,
This is for one of our clients.
They have been given a DKIM public key which they need to enter and when they do so from Plesk, it only saves the first 255 characters which is no good.
Consequently, when they try to validate it they are getting invalid RSA key.
This is why I was asking if its possible to enter DNS records manually and bypass the form which is truncating the record.
You mention its possible to add them via CLI, can you let me know which command allows it please.
Regards
Dave.
This is for one of our clients.
They have been given a DKIM public key which they need to enter and when they do so from Plesk, it only saves the first 255 characters which is no good.
Consequently, when they try to validate it they are getting invalid RSA key.
This is why I was asking if its possible to enter DNS records manually and bypass the form which is truncating the record.
You mention its possible to add them via CLI, can you let me know which command allows it please.
Regards
Dave.
Yes , originally this was the case but later changed RFC 4408 to allow multiple strings for a single record. Your own KB articles know about this issue here
So until this issue is resolved, we need to do this manually; hence why I asked if I manually update the database table to allow more than 255 characters and then manually add the record whether it will bypass this issue.
So until this issue is resolved, we need to do this manually; hence why I asked if I manually update the database table to allow more than 255 characters and then manually add the record whether it will bypass this issue.
You can try to do it for dns_recs table but consequences are unpredictable. You can do it on your own risk.
@Dave_G
It seems to be the case that @IgorG answered your question already: just add a TXT record.
Note that you have to add that to the primary nameserver: if Plesk is not your primary nameserver, adding TXT records to Plesk DNS does not make any sense.
For instance, if you manage DNS via the domain registrar, then you should add the TXT record over there.
You stated earlier
and I am a little bit confused now.
Your client has the public key. Who has or where is the private key?
If the private key is not on Plesk, then it should be on a remote mail server: is that remote server on the appropriate domain? That is, a domain to which you are adding the TXT record.
More important, if a remote mail server is used, then any DKIM settings on the Plesk instance are not required, one should only set some appropriate TXT records.
In short, it seems to be the case that you only have to add a TXT record to DNS (on the nameservers that are primary).
In that case, it can be also the case that you can add longer values to the TXT record (depending on the provider of the primary nameservers).
Regards....
It seems to be the case that @IgorG answered your question already: just add a TXT record.
Note that you have to add that to the primary nameserver: if Plesk is not your primary nameserver, adding TXT records to Plesk DNS does not make any sense.
For instance, if you manage DNS via the domain registrar, then you should add the TXT record over there.
You stated earlier
and I am a little bit confused now.
Your client has the public key. Who has or where is the private key?
If the private key is not on Plesk, then it should be on a remote mail server: is that remote server on the appropriate domain? That is, a domain to which you are adding the TXT record.
More important, if a remote mail server is used, then any DKIM settings on the Plesk instance are not required, one should only set some appropriate TXT records.
In short, it seems to be the case that you only have to add a TXT record to DNS (on the nameservers that are primary).
In that case, it can be also the case that you can add longer values to the TXT record (depending on the provider of the primary nameservers).
Regards....
Hi trialotto,
Let me try and explain.
We host a shared Plesk server. One of our clients hosts their own mail server in their office and has generated a DKIM key using a free service on the internet. They key is 2048 bits long (way to long for Plesk to currently handle).
So we had two choices:
1. tell the client we are extremely behind the times and our company does not allow DKIM values of this size or
2. we try to find a way around it.
Just increasing the field length in the database and adding the key manually was not enough for this to work. We also tried using CLI but got the error the record was too long.
So if anyone else needs to do something like this, here is a quick walkthrough (although as Igor has already mentioned it is not recommended to do this).
1. Add the key normally in Plesk.
2. Update the record via database making sure you split the record up in to sections (no 1 part longer than 255 characters)
- example: val='"dsfdfdfedfewetjkjkklnknknjh" "dfgfdgfjkklrekajksklala"';
3. Update the actual bind zone file for the domain and do the same, again making sure the record is split the same way.
4. restart bind.
Dave.
Let me try and explain.
We host a shared Plesk server. One of our clients hosts their own mail server in their office and has generated a DKIM key using a free service on the internet. They key is 2048 bits long (way to long for Plesk to currently handle).
So we had two choices:
1. tell the client we are extremely behind the times and our company does not allow DKIM values of this size or
2. we try to find a way around it.
Just increasing the field length in the database and adding the key manually was not enough for this to work. We also tried using CLI but got the error the record was too long.
So if anyone else needs to do something like this, here is a quick walkthrough (although as Igor has already mentioned it is not recommended to do this).
1. Add the key normally in Plesk.
2. Update the record via database making sure you split the record up in to sections (no 1 part longer than 255 characters)
- example: val='"dsfdfdfedfewetjkjkklnknknjh" "dfgfdgfjkklrekajksklala"';
3. Update the actual bind zone file for the domain and do the same, again making sure the record is split the same way.
4. restart bind.
Dave.
@Dave_G,
The walkthrough you are talking about is based on the assumption that Plesk runs as a primary nameserver, isn´t it?
Quite relevant information for those forum members that think "hey, this might work for me".
In essence, your "work-around" gives me a headache, for many reasons, and I will explain some of them.
First of all, your client is hosting a mail server: why do they not provide the DKIM themselves? It should be on their mail server, not on your (Plesk) server.
Second, they "generated a key using a free service on the internet". Ehm, be aware of the fact that some of these free services are intended to give you some degree of feeling secure, but in the meantime, they are either hacked or they are just intended to pass the keys to spammers in the first place. I am not sure what your client thinks, but there are better ways to generate a DKIM keypair.
Third, a 2048 bit (the current max) key has no use if the verifier is not able to verify a key of that length.
Fourth, a 2048 bit key will have a penalty on performance, in many aspects. This is worrysome, in the sense that spam attacks will be able to shutdown whole systems.
Fifth, your work-around may or may not work with respect to the Plesk database structure, but it will not work for DKIM signing and verifying purposes: a split record is not the same as the record that has been split, i.e. the entire record. In fact, by splitting the key, you are probably ending up with a "broken, effectively less than 1024 bit key".
Sixth, if you have tested your solution and you found that it "works", well, than the key has probably not been verified at all by the verifier.
In summary, I am just trying to say the above, in order to allow you to say to the customer "No, not possible AND the key should be on the mail server side".
By the way, I still do not understand why you do not choose the obvious method: adding the key to the DNS management, as provided by the domain registrar (who is very, very likely to support a TXT record for a 2048 bit key, without any fuss or problem).
Regards.....
The walkthrough you are talking about is based on the assumption that Plesk runs as a primary nameserver, isn´t it?
Quite relevant information for those forum members that think "hey, this might work for me".
In essence, your "work-around" gives me a headache, for many reasons, and I will explain some of them.
First of all, your client is hosting a mail server: why do they not provide the DKIM themselves? It should be on their mail server, not on your (Plesk) server.
Second, they "generated a key using a free service on the internet". Ehm, be aware of the fact that some of these free services are intended to give you some degree of feeling secure, but in the meantime, they are either hacked or they are just intended to pass the keys to spammers in the first place. I am not sure what your client thinks, but there are better ways to generate a DKIM keypair.
Third, a 2048 bit (the current max) key has no use if the verifier is not able to verify a key of that length.
Fourth, a 2048 bit key will have a penalty on performance, in many aspects. This is worrysome, in the sense that spam attacks will be able to shutdown whole systems.
Fifth, your work-around may or may not work with respect to the Plesk database structure, but it will not work for DKIM signing and verifying purposes: a split record is not the same as the record that has been split, i.e. the entire record. In fact, by splitting the key, you are probably ending up with a "broken, effectively less than 1024 bit key".
Sixth, if you have tested your solution and you found that it "works", well, than the key has probably not been verified at all by the verifier.
In summary, I am just trying to say the above, in order to allow you to say to the customer "No, not possible AND the key should be on the mail server side".
By the way, I still do not understand why you do not choose the obvious method: adding the key to the DNS management, as provided by the domain registrar (who is very, very likely to support a TXT record for a 2048 bit key, without any fuss or problem).
Regards.....
If Plesk was not handing primary DNS, then nobody would be looking at this post anyway, as DNS would be disabled and no records could be added.
Whether this gives you a headache or not is irrelevant, we needed a solution for longer DKIM values to be entered, and this has sorted it.
Whether the client is hosting their own mail server or not is also irrelevant, as Plesk is handling DNS - you cannot separate DNS records across multiple destinations unless you create a sub zone file, but in this case the mail server is for the main domain.
The key generated and length is what our client has chosen to do, they had the option to generate it from Plesk - but chose not to do that. This is a free world, and this was their choice.
And just to put you in the clear, the key has been verified and validated to be working fine after the changes made in Plesk. Whether you are a Plesk expert or not, customers should come first. This is what our company strides upon and we try to put them first all the time. Yes, we could have just said "no, we cannot provide DKIM records of this length - and then the customer would go else where.
I am not really sure what you are talking about when stating to do the obvious method? DNS management is provided by Plesk. Registrars only handle name servers - not dns records!
Anyway, this is what our client wanted. We found a way to get around the restriction Plesk had kept within the control panel on adding these records. its not the best solution in the world and it will probably get deleted if anything gets updated. But for now, it works and hopefully will continue to work until Plesk provides a better solution to add larger txt records.
Whether this gives you a headache or not is irrelevant, we needed a solution for longer DKIM values to be entered, and this has sorted it.
Whether the client is hosting their own mail server or not is also irrelevant, as Plesk is handling DNS - you cannot separate DNS records across multiple destinations unless you create a sub zone file, but in this case the mail server is for the main domain.
The key generated and length is what our client has chosen to do, they had the option to generate it from Plesk - but chose not to do that. This is a free world, and this was their choice.
And just to put you in the clear, the key has been verified and validated to be working fine after the changes made in Plesk. Whether you are a Plesk expert or not, customers should come first. This is what our company strides upon and we try to put them first all the time. Yes, we could have just said "no, we cannot provide DKIM records of this length - and then the customer would go else where.
I am not really sure what you are talking about when stating to do the obvious method? DNS management is provided by Plesk. Registrars only handle name servers - not dns records!
Anyway, this is what our client wanted. We found a way to get around the restriction Plesk had kept within the control panel on adding these records. its not the best solution in the world and it will probably get deleted if anything gets updated. But for now, it works and hopefully will continue to work until Plesk provides a better solution to add larger txt records.
@Dave_G,
It seems to be necessary that I explain a little bit about DNS and the possibility to use DKIM.
First, let´s have a look at DKIM and the solution you (essentially) offered to your customer.
There are, in essence, two keys: the private and the public key.
The private key should be on the mail server side and is used to sign mails. Not every signing mail server can or will support 2048 bits keys, the signers are simply not obliged to.
The public key should be in DNS in the form of a TXT record, with the key being in the range of 512 bits to 2048 bits. This is an obligation for verifiers.
Verifiers MAY be able to verify keys of a larger bit size and MUST ignore any signatures using algorithms the verifier does not implement.
The above implies that there are many reasons why a DKIM signature will not work in practice: the verifier and signer have to be "aligned" and that is not always the case.
Furthermore, the algorithms supported (i.e. preferred) by the official guidelines are rsa-sha1 and rsa-sha256.
The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed.
Your work-around fails to satisfy the above requirement: as a result, your signature will be ignored by any verifier.
In conclusion, you have offered your customer a solution that will not work.
Naturally, I can understand your desire to serve the customers requests and for that reason, you must be aware that your solution is void.
In the length of before mentioned desire, I wanted to help you identify a solution that actually can or does work. So let´s proceed.
Second, let´s have a look at DNS and a working solution that you can offer to your client.
We have to work with the fact that your customer works with the rather impractical 2048 bits key.
Normally, you should be able to convince the customer that a 1024 bit key is just as good, but let´s continue with the 2048 bits key.
In essence, Plesk does not allow that 2048 bit key (simply stated), but that is not a problem at all.
After all, domain name resolving is working the following way: a domain name is registered at the domain registrar.
In order to resolve the domain to an IP, the domain registrar maintains it´s own vast and solid network of nameservers, assigning domain names to IPs.
For that reason, almost every domain registrar has a DNS management panel, allowing the domain name holders to manage DNS directly.
Then, you have two options to resolve the domain to a "hosting space" in one of your servers:
a) managing DNS directly via the domain registrar: this is the most practical, flexible and reliable method,
OR
b) adding nameserver records to the domain registrar´s system, with those nameserver records pointing to a Plesk instance: in essence, this results in a domain request being
- served by the domain registrar´s nameserver system, in the sense that the request is directly passed on to the nameservers on the Plesk instance,
- served by the nameservers of the Plesk instance, which nameservers resolve the domain internally (or externally if the nameservers also manages domains on external servers)
and you can see by now that this method involves multiple passes, with some minor penalty on domain resolving performance.
It must be clear by now that you do not actually need the nameservers of Plesk.
It must also be clear that you can always add one record for a specific domain to the DNS management system of the domain registrar, alongside of the nameserver entries.
In essence, adding a TXT record with the appropriate DKIM values is always possible at the domain registrar´s system.
The reason for stating the above is simply the fact that all domain registrars are obliged to allow larger values in the DNS records and most domain registrars have implemented that.
In short, if your domain registrar´s DNS system allows adding huge DNS record values, simply add the DKIM value at the level of the domain registrar.
It is a simple and working solution that actually helps you and your client.
Why does it help you too?
Simply stated, consider your client discovering in the near future that it´s 2048 bits DKIM key does not work and that, for instance, spamming on behalf of the client´s mail server has resulted in extensive blacklisting on DNSBL blacklist, whilst being under the impression that you, as the hosting provider, did offer a working solution.
I certainly would not want to await that situation, in which a very likely conflict between you and the client can exist.
In conclusion, you should try a different solution, if you really want to serve the client´s best interests.
Note that I write all of the above with the best intentions, it is up to you to decide what to do.
Regards....
It seems to be necessary that I explain a little bit about DNS and the possibility to use DKIM.
First, let´s have a look at DKIM and the solution you (essentially) offered to your customer.
There are, in essence, two keys: the private and the public key.
The private key should be on the mail server side and is used to sign mails. Not every signing mail server can or will support 2048 bits keys, the signers are simply not obliged to.
The public key should be in DNS in the form of a TXT record, with the key being in the range of 512 bits to 2048 bits. This is an obligation for verifiers.
Verifiers MAY be able to verify keys of a larger bit size and MUST ignore any signatures using algorithms the verifier does not implement.
The above implies that there are many reasons why a DKIM signature will not work in practice: the verifier and signer have to be "aligned" and that is not always the case.
Furthermore, the algorithms supported (i.e. preferred) by the official guidelines are rsa-sha1 and rsa-sha256.
The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed.
Your work-around fails to satisfy the above requirement: as a result, your signature will be ignored by any verifier.
In conclusion, you have offered your customer a solution that will not work.
Naturally, I can understand your desire to serve the customers requests and for that reason, you must be aware that your solution is void.
In the length of before mentioned desire, I wanted to help you identify a solution that actually can or does work. So let´s proceed.
Second, let´s have a look at DNS and a working solution that you can offer to your client.
We have to work with the fact that your customer works with the rather impractical 2048 bits key.
Normally, you should be able to convince the customer that a 1024 bit key is just as good, but let´s continue with the 2048 bits key.
In essence, Plesk does not allow that 2048 bit key (simply stated), but that is not a problem at all.
After all, domain name resolving is working the following way: a domain name is registered at the domain registrar.
In order to resolve the domain to an IP, the domain registrar maintains it´s own vast and solid network of nameservers, assigning domain names to IPs.
For that reason, almost every domain registrar has a DNS management panel, allowing the domain name holders to manage DNS directly.
Then, you have two options to resolve the domain to a "hosting space" in one of your servers:
a) managing DNS directly via the domain registrar: this is the most practical, flexible and reliable method,
OR
b) adding nameserver records to the domain registrar´s system, with those nameserver records pointing to a Plesk instance: in essence, this results in a domain request being
- served by the domain registrar´s nameserver system, in the sense that the request is directly passed on to the nameservers on the Plesk instance,
- served by the nameservers of the Plesk instance, which nameservers resolve the domain internally (or externally if the nameservers also manages domains on external servers)
and you can see by now that this method involves multiple passes, with some minor penalty on domain resolving performance.
It must be clear by now that you do not actually need the nameservers of Plesk.
It must also be clear that you can always add one record for a specific domain to the DNS management system of the domain registrar, alongside of the nameserver entries.
In essence, adding a TXT record with the appropriate DKIM values is always possible at the domain registrar´s system.
The reason for stating the above is simply the fact that all domain registrars are obliged to allow larger values in the DNS records and most domain registrars have implemented that.
In short, if your domain registrar´s DNS system allows adding huge DNS record values, simply add the DKIM value at the level of the domain registrar.
It is a simple and working solution that actually helps you and your client.
Why does it help you too?
Simply stated, consider your client discovering in the near future that it´s 2048 bits DKIM key does not work and that, for instance, spamming on behalf of the client´s mail server has resulted in extensive blacklisting on DNSBL blacklist, whilst being under the impression that you, as the hosting provider, did offer a working solution.
I certainly would not want to await that situation, in which a very likely conflict between you and the client can exist.
In conclusion, you should try a different solution, if you really want to serve the client´s best interests.
Note that I write all of the above with the best intentions, it is up to you to decide what to do.
Regards....
