Just want simple TLS for your .internal network?

I prefer to assign an external name to an internal device and grab a free SSL cert from LetsEncrypt, but using DNS challenge instead as internal IP addresses aren't reachable by their servers.

Obligatory if DNS validation is good enough, DANE should've been too. Yes, MITM things could potentially ensue on untrusted networks without DNSSEC, but that's perfect being the enemy of good territory IMO.

This would allow folks to have .internal with auto-discovered, decentralized, trusted PKI. It would also enable something like a DNSSEC on/off toggle switch for IoT devices to allow owners to MITM them and provide local functionality for their cloud services.

This would be cool, but I think we're still a far way off from that being an option. DANE requires DNSSEC validation by the recursive resolver and a secure connection from the user's device to that resolver. DoH appears to be the leading approach for securing the connection between the user's device and the resolver, and modern browser support is pretty good, but the defaults in use today are not secure:

> It disables DoH when [...] a network tells Firefox not to use secure DNS. [1]

If we enabled DANE right now, then a malicious network could tell the browser to turn off DoH and to use a malicious DNS resolver. The malicious resolver could set the AD flag, so it would look like DNSSEC had been validated. They'd then be able to intercept traffic for all domains with DANE-validated TLS certificates. In contrast, it's difficult for an attacker to fraudulently obtain a TLS certificate from a public CA.

Even if we limit DANE to .internal domains, imagine connecting to a malicious network and loading webmail.internal. A malicious network would have no problem generating a DANE-validated TLS certificate to impersonate that domain.

[1] https://support.mozilla.org/en-US/kb/dns-over-https#w_defaul...

I'll concede that DNSSEC is not in a good spot these days, but I don't know if that's really due to its design or lack of adoption (it's in similar territory as IPv6 TBH). DoH is (IMO) a poor workaround instead of "fixing" DNSSEC, but it's unfortunately the best way to get secure resolution today.

Putting aside the DNSSEC issues, IMO, DNS should be authoritative for everything. It's perfectly decentralized, and by purchasing a domain you prove ownership of it and shouldn't then need to work within more centralized services like Lets Encrypt/ACME to get a certificate (which seems to becoming more and more required for a web presence). A domain name and a routable IP should be all you need to host services/prove to users that domain.com is yours, and it's something I think we've lost sight of.

Yes, DANE can create security issues, your webmail example is a perfectly valid one. In those situations, you either accept the risk or use a different domain. Not allowing the behavior because of footguns never ends well with technology, and if you're smart enough to use .internal you should understand the risks of doing so.

Basically, we should let adults be adults on the internet and stop creating more centralization in the name of security, IMO.

It is not in similar territory as IPv6. We live in a mixed IPv4/IPv6 world (with translation). IPv6 usage is steadily and markedly increasing. Without asking to be, I'm IPv6 (on ATT Fiber) right now. DNSSEC usage has actually declined in North America in the preceding 18 months, and its adoption is microscopic to begin with.

IPv6 is going to happen (albeit over a longer time horizon than its advocates hoped). DNSSEC has failed.

> DNSSEC has failed.

This is the customary comment by me that this is far from the prevailing view. From my viewpoint, DNSSEC is steadily increasing, both in demand and in amount of domains signed.

Here's .COM and .NET:

https://www.verisign.com/en_US/company-information/verisign-...

Signed domains are increasing where they're done automatically by registrars; where the market has a say, use is declining --- sharply!

As I usually have to point out to you, registrars can’t add DNSSEC to domains. Only DNS server operators can do that. They often have to have the cooperation of the registrar to do it, but not always; sometimes, if the registry supports CDS/CDNSKEY records, the DNS server operator can add DNSSEC all by themselves. And why would DNS server operators add DNSSEC to their domains, unless the domain owners wanted them to?

I'm really not interested in whatever technicality you're trying to argue here. I'm talking about whatever words you want to use for this phenomenon:

https://www.sidn.nl/en/modern-internet-standards/dnssec

Meanwhile: the graphs I posted in the preceding comment are pretty striking. If you haven't clicked through yet, you should. I've pointed out previous, minor drops in DNSSEC deployment in the US. The current one is not minor.