Easily Configure DANE
DANE, short for DNS-based Authentication of Named Entities, primarily used for SMTP and SIP, is a protocol for securely publishing keys and certificates through cryptographically secured DNS using DNSSEC.
If your domain does not have DNSSEC configured - STOP! This is NOT going to work, you will first need to configure DNSSEC, and this example uses the postfix MTA, not sendmail, not exim, and sure as hell not qmail, the DNS is the main part that gets people anyway, your MTA should have a wiki on how to interface with DANE.
I looked at DANE once a couple of years ago, but the documentation was poor, the few detailed articles I found was rambling, made my eyes feel like they were ready to bleed, so I moved on, I, like many of us, don't have hours to read an article that's so in-depth it's more or less like a scientific publication designed to bamboozle the average person, I like small summaries of what something is and does, and bullet points on how to configure it, not remind me of reading War and Peace, so I'll give it to you short and sweet...
The first thing to remember is that if your domain is example.com, but your MX record and your mail server is mail.example.com, then mail.example.com is the name that must have the SSL cert we need to work with, likely you do already since it's pretty much a given when sending and receiving Email, so basically, in all the below examples, replace example.com with your domain, and if you just use your domain name as the MX, then remove references to the preceding mail dot.
Open a console on the server where your MX's certificate is located, if using Lets Encrypt and Acme.sh, it's going to be /root/.acme.sh/example.com/example.com.cer however if your silly enough to still be using certbot, find where ever certbot hides the cert, or change to acme.sh
Next run the following commands which will generate the output needed to add into the primary DNS servers zone file, for example.com that's -
That's the hash we need, open a new window and login to your DNS server, edit your zone file, or add a new entry if you use some third party web interface, in your zone file, add a new entry
Now we can test using dig, just remember to use your host name and name server...
If you do not see an ANSWER section and get, say an AUTHORITY section, something went wrong, double check you didn't include a line break, check logs for any hints as well. If you do see that in an ANSWER section, your 99% sorted, all we have to do now is add or change some settings in your MTA, as I use postfix, add or change the following settings in /etc/postfix/main.cf
run postfix reload and that's it, yes, you really are done, postfix will now validate inbound and your published for receivers to validate your outbound connection, well for those who have figured out already how to do it
Postfix will also fail safe, meaning if there is a problem, mail will still succeed.
Lastly, time for those final tests, I suggest using https://dane.sys4.de and https://www.uriports.com/tools/dane-validator to validate your configuration, and no matter what, monitor your logs for a few days at least, just to be on the safe side
I looked at DANE once a couple of years ago, but the documentation was poor, the few detailed articles I found was rambling, made my eyes feel like they were ready to bleed, so I moved on, I, like many of us, don't have hours to read an article that's so in-depth it's more or less like a scientific publication designed to bamboozle the average person, I like small summaries of what something is and does, and bullet points on how to configure it, not remind me of reading War and Peace, so I'll give it to you short and sweet...
The first thing to remember is that if your domain is example.com, but your MX record and your mail server is mail.example.com, then mail.example.com is the name that must have the SSL cert we need to work with, likely you do already since it's pretty much a given when sending and receiving Email, so basically, in all the below examples, replace example.com with your domain, and if you just use your domain name as the MX, then remove references to the preceding mail dot.
Open a console on the server where your MX's certificate is located, if using Lets Encrypt and Acme.sh, it's going to be /root/.acme.sh/example.com/example.com.cer however if your silly enough to still be using certbot, find where ever certbot hides the cert, or change to acme.sh
Next run the following commands which will generate the output needed to add into the primary DNS servers zone file, for example.com that's -
openssl x509 -in ~/.acme.sh/mail.example.com_ecc/mail.example.com.cer -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256It should give you output like:
(stdin)= 5485485455956854-6klhjy55555xxxx555
That's the hash we need, open a new window and login to your DNS server, edit your zone file, or add a new entry if you use some third party web interface, in your zone file, add a new entry
_25._tcp.mail.example.net. TLSA 3 1 1then paste the hash you just generated (the bits after the equals sign to the end of the line), into your zone file on the same line right after the 3 1 1, so it looks something like this...
_25._tcp.mail.example.net. TLSA 3 1 1 5485485455956854-6klhjy555.....555Remember to increment the zones serial, then save the file and run rndc reload, wouldn't hurt to check the logs for any issues either.
Now we can test using dig, just remember to use your host name and name server...
dig TLSA _25._tcp.mail.example.com @ns1.example.com +dnssecYou should see a bunch of output, the important bit we want to see is the ANSWER section, something along the lines of...
_25._tcp.mail.example.net. 86400 IN TLSA 3 1 1 5485485455956854-6klhjy555 444555
_25._tcp.mail.example.net. 86400 IN RRSIG TLSA 13 5 86400 xxx yyy zzz
If you do not see an ANSWER section and get, say an AUTHORITY section, something went wrong, double check you didn't include a line break, check logs for any hints as well. If you do see that in an ANSWER section, your 99% sorted, all we have to do now is add or change some settings in your MTA, as I use postfix, add or change the following settings in /etc/postfix/main.cf
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtpd_tls_security_level = may
run postfix reload and that's it, yes, you really are done, postfix will now validate inbound and your published for receivers to validate your outbound connection, well for those who have figured out already how to do it
Postfix will also fail safe, meaning if there is a problem, mail will still succeed.
Lastly, time for those final tests, I suggest using https://dane.sys4.de and https://www.uriports.com/tools/dane-validator to validate your configuration, and no matter what, monitor your logs for a few days at least, just to be on the safe side
Related Articles
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded