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.
It happens. I liked HPKP, which was also tried, and also failed.
> 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...
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.
IPv6 is going to happen (albeit over a longer time horizon than its advocates hoped). 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.
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!
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.
> The current one is not minor.
Maybe not, but I do not know the cause, and you have not proposed one either. Do you have a theory about what happened in late 2023? We’ll have to see if this trend continues; the graphs you linked do show a slight upward turn right at the end of the graphs.
According to that, it's not supported by Chrome, nor Firefox.
Let me know if I've misunderstood your point, and there some other widespread niche usage DANE finds in SMTP.
(For those who don’t know, MTA-STS is basically DANE but for people who hate DNSSEC. And are OK with requiring every mail server to also have a web server running.)
(Also, your test is wrong. It should be “_mta-sts”, not “_mta_sts”.)
When it’s purposefully set up by actual people, I only hear about DANE. It’s only when talking about huge e-mail providers that I hear about MTA-STS. And, as I said previously, those huge providers probably chose MTA-STS not for any reason which benefits their regular users, but for reasons which benefits only themselves, being a huge operator.
If you're wondering why DNSSEC never took off, these kinds of exchanges are illustrative!
I am baffled by this claim. DNSSEC works completely transparently to the user.
Also, we were comparing the specifics of MTA-STS to DANE, not to DNSSEC. Both MTA-STS and DANE solves the same problem, i.e. fake X.509 certificates and/or protocol degradation (SSL stripping). DANE has the potential to solve the same problem for every protocol, not just SMTP, while MTA-STS is both specific to e-mail, and stupidly requires an additional web server on every SMTP server.
> and falling
It’s actually rising again, according to your sources.
In recent years, you seem to have dropped all pretense of arguing against the specifics of DNSSEC, which is good, but you have then resorted to argumentum ad populum. However, this is a bad form of argumentation unless you can explain why DNSSEC is not as popular as it could be. For instance, what happened in late 2023 to cause the dip?