Can you share data on how much latency this adds to TTFB?

Something to consider in the future is implementing RFC9102[0] which is an experimental TLS extension for embedding the DNSSEC chain this should significantly improve TTFB. It'll still need to request the DS record/trust anchor from the p2p client.

[0] https://www.rfc-editor.org/rfc/rfc9102.html

This standard is DOA.

https://blog.apnic.net/2019/05/27/dns-oarc-30-bad-news-for-d...

An explainer:

https://news.ycombinator.com/item?id=20026572

yeah the initial standard was dropped by tls-wg. RFC9102 is more recent/an independent submission.

> 3. An attacker with a valid certificate can strip dnssec-chain-extension out of a TLS handshake.

That's true but decentralized namespaces are at least starting with a clean slate they could require this extension no CA is issuing names for those anyway.

For names that rely on WebPKI this standard could be less strict about pinning initially (treating DNSSEC as just another CA). Once there's more adoption in a few years browsers should look for it and fallback to querying the DNSSEC chain (could be included with an edns option RFC7901).

Browser vendors (notably Chromium) have already acknowledged that the best they'll be able to do is treat DANE like another CA, which leaves open the question of why they'd bother supporting a TLS extension that doesn't improve the status quo. It's not going to happen.

The "decentralized namespaces" stuff is interesting, because, of course, it gives away that game that a substantial amount of DNSSEC/DANE advocacy is coming from people speculating on a premined crypto-token that purports to replace the DNS, linking to it (after a fashion) with DANE. Also not going to happen (but if it does, I'm going to pre-mine an ARP coin, so I win either way).