[aleksejs]

The jabber.ru post referenced here presents clear evidence (in the section titled "Network") that the malicious actor was able to reroute traffic going to the legitimate jabber.ru server. An attacker in this position does not need an RCE to get a cert, they can just get one issued the normal way, because they do effectively control the IP address that the domain is pointing to.

[8organicbits]

One suggestion for anyone concerned about this weakness. You can use the CAA record to pin the domain to a specific certificate authority, issuance method, and account. This is imperfect, as CAA record validation (edit: of CAA extensions) is not mandatory yet. But by March 2027 all the CAs a supposed to have support.

Sprinkle some DNSSEC on the CAA record too, if you'd like.

[cobertos]

Just be careful, if you host your DNS at Cloudflare (maybe others?), they will rewrite your CAA record[0] if you use TLS with them. This is in the name of convenience but it was surprising when I first learned.

[0]: https://developers.cloudflare.com/ssl/edge-certificates/caa-...

[flarzzarp]

Cloudflare is basically MITMAAS for the US Gov. If you are worried about state actor wiretapping, you should avoid them altogether.

[aleksejs]

> This is imperfect, as CAA record validation is not mandatory yet. But by March 2027 all the CAs a supposed to have support.

Is that true? My read of Section 1.2.1 in [1] suggests CAA checking has been mandatory since 2017‐09‐08.

[1] https://cabforum.org/working-groups/server/baseline-requirem...

[mcpherrinm]

CAA checking is mandatory, so you can always restrict to a given CA.

To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type).

Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.

[j16sdiz]

DNSSEC is the weakest link here.

It is too fragile (multiple point of failure). It is high volume (=it need be cacheable).

Puting authentication cert in dns sounds good in theory, but we have never get that reliability

[mcpherrinm]

Even without DNSSEC, the CAA record approach can help, as it requires MITMing between the CA and the DNS server, which may be harder in some cases than just MITMing a target site.

There’s some upcoming attempts at transport security for authoritative DNS servers which might help too: https://datatracker.ietf.org/doc/html/draft-hoffman-deleg-se...

[westurner]

Is there a Transport-Secured-Only flag in a DNS spec? How to ensure that a CAA cert fingerprint is not retrieved over unsecured DNS?

Re: DNS security and NTP and Decentralized DNS/PKI with web standards like W3C DID and DID micro-ledgers for record signing:

"Cert Authorities Check for DNSSEC from Today" (2026-03-26) https://news.ycombinator.com/item?id=47401716

[Hizonner]

> It is too fragile (multiple point of failure).

If your DNS isn't working, you're not going to be making connections anyway. And if you can't keep DNSSEC running, you can't keep certs up to date either. DNSSEC is actually much simpler, with fewer failure points, once you set it up.

> It is high volume (=it need be cacheable).

It is. Unlike certificates. And the cache lifetimes are much shorter than typical certificate lifetimes.

[tptacek]

It is self-evidently not correct that companies that can't keep DNSSEC running can't keep certs running. Entire TLDs have fallen off the Internet because DNSSEC has broken. A certificate never took Slack down for half a day. It's just obviously not true.

[8organicbits]

I have it partially right. The extensions are not yet mandatory.

https://www.feistyduck.com/newsletter/issue_137_acme_caa__ex...

[ValdikSS]

That's right, it's easier to setup such MiTM using an intermediate server, because only getting the private key of the certificate won't get you the user's traffic due to PFS.

You either need to disable PFS on the server, or export TLS master keys for each session in some way, or MiTM.