• 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 Plesk postfix DANE

Kulturmensch

Regular Pleskian
Server operating system version
Ubuntu 22.04.2 LTS
Plesk version and microupdate number
Plesk Obsidian v18.0.54
In the recent update to Obsidian this was announced:"Added the ability to add Transport Layer Security Authentication (TLSA) DNS records to domains’ DNS zones in Plesk. Such records are most commonly used to implement DNS-based Authentication of Named Entities (DANE)."
Where can I find more information how to take advantage of it?
 
This is a good place to start:

"Secure email transport (STARTTLS and DANE)"

There has also been some discussion on this forum:
 
In terms of applying trusted TLSA records (which requires DNSSEC and thus the DANE security protocol), all of our DNS records, for all of our hosted domains are managed by us outside of Plesk, so we implemented all of the TLSA config outside of Plesk too (via IONOS Cloud Server Config and plus our own Config).

Therefore, we can't offer advice / feedback from our own experiences with the latest Plesk additions that you're looking at. However, in addition to the very helpful post above from @Maarten. above, we can add some additional test site urls which could be of some use to you as/when you complete this exercise.

For DNSSEC tests:

DNSSEC Analyzer (brief validity)
https://dnsviz.net/ (detailed analysis)

For DANE tests:
https://dane.sys4.de/ (quick, simple e-mail test)
https://www.checktls.com/TestSender (add option DANE within 'Test To' e-mail tests)
https://check.sidnlabs.nl/dane/ (simple domain DANE TLSA record check)
https://www.huque.com/bin/danecheck-smtp (e-mail tests)
https://www.huque.com/bin/danecheck (domain tests)
https://www.huque.com/tools/ (starting point for many related test tools)

There are many more of course, some that can apply combination quick tests;
e.g. DNS / DNSSEC / DANE tests via: https://testconnectivity.microsoft.com/tests/O365DaneValidation/input
However, you should hopefully be able to test almost everything that's needed, at this early stage of TLSA / DANE implementation.
 
Thank you both very much, indeed. So, I have first to learn. If I succeed I will be glad to add here a summary of my efforts and results:)
 
I have now secured my domains with DNSSEC which was also possible direct with Strato (host of server) and passed successfully the tests of the dnssec-analyser. So, I now went through your provided links and I produced the TLSA records for my mail server as needed for DANE. This worked fine but I do not find the right place to install it in my DNS template??

Can I use dns-template-txt-fields instead of missing dns-template-tlsa-fields in the plesk dns-template for this or is it necessarry to buy an abo for the plesk dnssec-extension as I have only a web-admin plesk license? Or is this a completely wrong approach?
 
In terms of applying trusted TLSA records (which requires DNSSEC and thus the DANE security protocol), all of our DNS records, for all of our hosted domains are managed by us outside of Plesk, so we implemented all of the TLSA config outside of Plesk too (via IONOS Cloud Server Config and plus our own Config). Therefore, we can't offer advice / feedback from our own experiences with the latest Plesk additions that you're looking at ~~~
That previous statement ^ means that we can't usefully comment on your Plesk DNS setup, because we don't use it, but, what we can confirm, is that within our IONOS Cloud Server Control Panels and DNS API Access (where all of our DNS etc is configured and managed by us) we needed to create TLSA records (NOT TXT Records) for each area that we wanted DANE coverage to be applied to e.g. _443._tcp / _25._tcp.mail etc etc etc Plus the actual TLSA dataset in each case. It's quite a time consuming exercise & needs lots of verification checks before it's complete. Perhaps the best piece of advice we can offer, is to do absolutely everything on one single domain first, making process flow notes as you do it and then, once that domain is fully tested, verified and 100% DANE functional, then and only then repeat your now authentic process flow on all of the other domains (either manually or maybe write a script if you want and are happy to).
 
Perhaps the best piece of advice we can offer, is to do absolutely everything on one single domain first, making process flow notes as you do it and then, once that domain is fully tested, verified and 100% DANE functional, then and only then repeat your now authentic process flow on all of the other domains (either manually or maybe write a script if you want and are happy to).
Thank you for your quick answer - I will proceed this way and let you know how I proceed!
 
So, first step was successful. I could realize the relevant TLSA-entries for port 25 and 443 in one domain using plesk (my earlier mistake was to look for TLSA entries in the general DNS template but not in the belonging domain istself.)

The next problem is that I use the DNS-Server of my server host (strato). But I saw that at strato I cannot add TLSA records (also not CAA records etc.) . At strato I have enabled DNSSEC for my domains what worked fine. For my own Plesk-DNS-Server I cannot do this as I do not have the DNS-extension by Plesk needed for it.

So I am wondering how to publish the new TLSA records to the DNS-Network? Should I switch my Plesk DNS-Server to master? But what will haben then with the DNSSEC-entries in my strato-account?

Have you any advice?
 
So, first step was successful. I could realize the relevant TLSA-entries for port 25 and 443 in one domain using plesk (my earlier mistake was to look for TLSA entries in the general DNS template but not in the belonging domain istself.)
In our case: It's not just Ports 25 & 443. Those are just two chosen as examples in our post. We posted: "...e.g. _443._tcp / _25._tcp.mail etc etc etc..." It's every area that you want DANE functionality on e.g. _443._tcp.webmail and/or _443._tcp.www etc etc etc ;) These are all examples from our own IONOS Cloud Servers and it maybe a different setup / process when you're implementing DANE / TLSA records directly through Plesk DNS aka Double Check First :)
The next problem is that I use the DNS-Server of my server host (strato). But I saw that at strato I cannot add TLSA records (also not CAA records etc.) .
That ^ might be an issue. We can easily add TLSA records (and CAA rercords) via our Cloud Server Control Panels and DNS API Access at IONOS. We have no feedback on adding TLSA records directly though Plesk DNS (as we don't use it) unfortunately, but, others may have and may post on here for you.
At strato I have enabled DNSSEC for my domains what worked fine. For my own Plesk-DNS-Server I cannot do this as I do not have the DNS-extension by Plesk needed for it. So I am wondering how to publish the new TLSA records to the DNS-Network? Should I switch my Plesk DNS-Server to master? But what will haben then with the DNSSEC-entries in my strato-account? Have you any advice?
Advice? Yes! :) Don't change anything further, until you have some firm advice on utilization of your Plesk DNS setup from people actually using it /support staff. You could raise a Plesk support ticket, which may be the quickest way for you / your setup, but read these links first (if you have not already done so):



 
Finally I got it work for a less important domain. I replaced the name-server of strato with my own plesk ones. Here I could setup the necessary entries (TLSA) and others like CAA. This worked. The denic NAST predelgation check showed the proper function of each of my plesk name-server but as I have currently only one IP-address for the new V-Server I get this marked as an error by denic. Although it works in general I will use the standard name-server now until strato becomes able to provide a 2nd IP. Then I will continue the "DANE/DNSSEC-project" However, up to now it was a good learning_curve;-):) Thank you for your help, indeed!
 
Back
Top