🛡️ 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:
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
Автоматизация обновления TLSA-записей для DANE: Интеграция с PowerDNS API
В современной экосистеме электронной почты безопасность доставки сообщений является критически важной. Протокол SMTP, будучи фундаментальным, изначально не был защищен. Для его защиты был разработан механизм SMTP TLS, который обеспечивает шифрование соединения между почтовыми серверами. Однако он уязвим к атакам "человек посередине" (MitM), если злоумышленник может подделать сертификат. Технология DANE (DNS-based Authentication of Named Entities) решает эту проблему, используя DNSSEC в качестве корня доверия. TLSA-запись в DNS связывает доменное имя сервера с его сертификатом или открытым ключом. Получатель почты может проверить, что сертификат отправителя соответствует записи в DNS, защищенной DNSSEC, что делает подделку практически невозможной. Для работы DANE необходимо, чтобы TLSA-записи всегда соответствовали действительным сертификатам на сервере. Этот процесс идеально подходит для автоматизации. На помощь можно использовать: Python-скрипт для автоматического обновления TLSA-записей Представленный Python-скрипт решает задачу автоматического обновления TLSA-записей на авторитативном DNS-сервере PowerDNS при обновлении сертификатов. Это ключевой компонент для поддержания актуальности DANE в инфраструктуре.
🚨 Fixing the PKI Mess: CAA + Your Own CA via DNS 🚨
Right now, any CA can issue a certificate for your domain. Even if you set a CAA record (`issue "letsencrypt.org"`), it only controls *who* can issue, not what cert is valid. This is broken.
🔐 What if we could fix this using DNS?
#Introducing CAA+CA Fingerprint: Self-Sovereign Certificate Authority
Instead of just saying *which CA can issue*, you publish your own CA's fingerprint in DNS. If your CA issues a cert for `awesomecars.com`, browsers should validate it against the DNS-published CA key.
🔥 How It Works
You run your own CA (because why trust the cartel?). You then publish:
1️⃣ A CAA record specifying your own CA (with a fingerprint! 🔥)
2️⃣ A DNS record with your CA’s public key (like DKIM but for TLS!)
🔹 Example DNS Setup for `awesomecars.com`:
```
awesomecars.com. IN CAA 0 issue "pki.awesomecars.com; sha256=abcd1234..."
pki.awesomecars.com. IN CERT 6 0 0 (--BEGIN CERTIFICATE-- ....)
```
Now, only certs signed by your CA are valid for `awesomecars.com`, even if another CA is tricked into issuing a rogue cert. No more CA hijacking!
🚀 Why Is This Better Than the Current CA Model?
✅ Self-Sovereign Identity: If you own the domain, you should own its PKI.
✅ Prevents Rogue Certs: No government or rogue CA can fake a cert for your domain.
✅ Works Like DKIM for Email: Your CA’s public key is stored in DNSSEC-protected records, just like DKIM keys for email signing.
✅ No More External Trust Issues: You control your CA entirely, instead of relying on Google’s CA store.
✅ Perfect for Self-Hosting & Internal Networks: No need for external CA trust—your DNS is your trust model.
🔥 Why Isn’t This a Thing Already?
Big Tech hates this idea because it removes their control:
❌ Google wants Certificate Transparency (CT), where they control which certs are logged.
❌ Commercial CAs make $$$ selling certs. This kills their business.
❌ DNSSEC adoption is intentionally kept low by the same companies who don’t want this to succeed.
Browsers refuse to support TLSA for the same reason—they want centralized CA trust, not self-hosted PKI.
🔗 Who Needs to Implement This?
🚀 Self-hosters & Homelabs: Use this for your own infrastructure.
🚀 Email providers: Stop relying on public CAs!
🚀 Privacy-focused projects (Tor, Matrix, XMPP, Fediverse, etc.): A true decentralized PKI alternative.
🚀 Fediverse devs: Let’s push for DNS-based CA validation!
What do you think? Would you trust your own CA in DNS over some random commercial CA?
🔁 Boost this if you want a decentralized PKI revolution!
🔥 This keeps the focus on self-hosting your own CA, highlights the security flaws of current PKI, and calls out Big Tech’s resistance to decentralized trust.
#PKI #Security #DNSSEC #DANE #TLSA #CAA #SelfHosting #Fediverse #Privacy #Decentralization #dns #linux
Reddit Tech VN Bot
Habr
Christian
Opa Gollum Catuvolcus DN9MS