That's factually untrue. RFC 9102 was published two years ago in order to gather experimental data: https://datatracker.ietf.org/doc/rfc9102/ The relevant RFC for DANE is still active, and it hasn't been obsoleted ("shot down").

The major vulnerability of DANE is MITM attacker's ability to "downgrade" attacks into regular PKI in mixed PKI+DANE deployments. So DANE is at worst no better than PKI.

The other problem is the lack of something like certificate transparency for DNS updates and the inability to quickly invalidate erroneous records in caching resolvers, and the general complexity of DNSSEC setup.

People (mostly within the RIPE DNS WG) are working on mitigating that: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-aut... or https://blog.apnic.net/2021/11/02/dnssec-provisioning-automa...

You should tell that to Geoff Huston, because I'm practically quoting him.

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

Meanwhile: there will never be anything like CT for DANE and DNSSEC, for at least two big reasons:

1. Browser vendors have no leverage with DNS registrars to force them to deploy it, and that kind of leverage was required to get CT as far as it has been.

2. The DNS top level domains that are required to implement something like CT are controlled by sovereign states, which aren't going to participate in a single global transparency log; in particular, you'd be surprised to see any of the US or UK TLDs conceding to anything like this.

You have links here to DNSSEC automation work, but nothing to any kind of "DANE Transparency", because, so far as I know of, nothing like it has even been meaningfully proposed.