TLSA- und DANE-Records manuell prüfen: Schritt für Schritt mit OpenSSL
TLSA- und DANE-Records manuell pruefen mit OpenSSL, dig und hash-slinger. Fingerprint-Berechnung fuer Selector 0/1 und Matching-Type 0/1/2 durchgespielt. Nuetzlich wenn ein TLSA-Record nicht validiert und man wissen will warum.https://www.kernel-error.de/2014/05/19/tlsa-dane-record-von-hand-manuel-pruefen/
DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern
DANE und TLSA-Records ermoeglichen TLS-Zertifikat-Schutz via DNSSEC, nicht ueber CA-Zertifikatsketten. Praktische OpenSSL-Befehle zum Hash erzeugen, dig zum Pruefen. Bei mir im Einsatz, funktioniert elegant.https://www.kernel-error.de/2013/08/10/dnssec-und-dns-based-authentication-of-named-entities-dane/
why monitor 9 email protocols when the industry standard is 5
the typical DMARC vendor covers DMARC, SPF, DKIM... sometimes BIMI & MTA-STS...
that was adequate in 2022
in 2026, email security has expanded
each protocol solves a specific failure mode
ignoring any of them means accepting a blind spot
I added them because I kept seeing real failures that the 5-protocol approach couldn't explain
🛡️ We’ve expanded DNSimple's DNS capabilities, TLSA record support is now live for all customers! 🚀
Strengthen your domain security with certificate pinning, DANE protocol, and non-ICANN TLD compatibility.
👀 Watch our video explainer for all the details: https://www.youtube.com/watch?v=B_8Cv6iyruI
Some days ago I renamed one of my MX records to be more streamlined. This prompted me to look at all the DNS records. Only though this, I noticed that only one of my MX records has a suitable #DANE #TLSA record. So it might be a good idea for you to check if they are all how they should be. For me, this means the following:
-=Kernel-Error=-
Meysam
Trusty
Yves Venedey
dmstork
Mynacolmynacol.xyz MX -> mx1.mynacol.xyz, mx2.mynacol.xyz
mx1.mynacol.xyz A/AAAA
_25._tcp.mx1.mynacol.xyz TLSA ... <- This was missing
mx2.mynacol.xyz A/AAAA
_25._tcp.mx2.mynacol.xyz TLSA ...
@kmj I looked into this about a year ago. The situation boils down to this: If the receiving domain has set up #DANE #TLSA and the sender tries to send with DANE and is somewhat RFC compliant, it does use TLS #SNI during STARTTLS, which allows to forward an encrypted connection to the actual destination. If DANE is not used, almost all mail clients don’t use TLS SNI by default. This leaves a reverse proxy with needing to decrypt the connection with a self-signed/bogus certificate or an unencrypted connection to get to know where to forward the mail to. There also seems to be no way to get the intended recipient from the client and then instruct the client to “restart” the sending of the same mail while offering TLS and forwarding it to the correct destination.
I learned at the same time that https://v4-frontend.netiter.com/ by @kasperd does the above thing on port 25. If DANE resp. TLS SNI is used, an encrypted connection is forwarded as-is. All other traffic is decrypted and forwarded to the intended recipient based on the plaintext RCPT TO.
Sử dụng DANE với chứng chỉ tự ký trên máy chủ mail gặp vấn đề với Gmail và Protonmail. Liệu có thể nhận mail từ những nhà cung cấp này với chứng chỉ tự ký và DANE? #DANE #MailServer #SelfSignedCertificate #TLS #MáyChủMail #ChứngChỉTựKý #BảoMật #Security #Email #TLSA
Reddit Tech VN Bot