[londons_explore]

Browser vendors seem to have shelved all work on DNSSEC for reasons they haven't publically stated. It had such promises to be able to reduce trust in CA's by pinning HTTPS certificates to DNS responses, so was exactly what browsers would have wanted, yet still all work stopped around 2015 or so.

To me, it's as if DNSSEC has some critical and unfixable security vulnerability, and people who make these decisions decided to stop all work on it, but not reveal the vulnerability because doing so would do too much damage.

This is probably the most comprehensive list of reasons not to use it: https://www.imperialviolet.org/2015/01/17/notdane.html

[tssva]

This is not what DNSSEC does. DNSSEC is about signing DNS records to prevent spoofing of records.

DNSSEC has not seen widespread adoption because of complexity in implementing and maintaining DNSSEC and concern over weaknesses in the encryption chosen. The protocol has been around a long time now and the encryption involved is not modern. Some DNS providers are making DNSSEC easier by handling keysigning and rotation with no user involvement. Just check the box that you want it activated.

DANE is the storage and retrieval of certificates via DNS. DANE depends upon DNSSEC to sign the certificate records to determine that haven't been spoofed.

There is no great conspiracy theory needed regarding why DANE has not been implemented in browsers. The browser makers have been pretty open about why they have chosen not to support it. For example code has been written for Chrome but Google has said they haven't shipped it because they don't want to support the 1024-bit RSA required as part of the DNSSEC standard.

[iso1631]

I don't understand why browser vendors should be involved

My browser should ask my OS to resolve DNS

It's my OS's responsibility to do that - maybe sending a request to a remote server, maybe running it's own resolved, maybe using DoT, DoH, DNSSec or not

What business should it be of browser vendors?

[tptacek]

This weird idea of the delineation of responsibilities between the OS and applications has never actually been how things worked. For a very long time, the OS resolver libraries couldn't even reliably do asynchronous resolution, and applications like your browser provided their own. I think the notion that the OS "owns" DNS comes from the fact that people used to get their DNS servers from DHCP, and the OS's libraries automatically knew what servers DHCP had been configured. It's not like some kind of law of system design.

[londons_explore]

The OS resolves DNS names to IP addresses... Except an IP address isn't a security identifier of any kind, so there is no benefit to it not being spoofed.

The relation to browser vendors is that DNSSEC allows DNS to verify/validate certificates for TLS connections, which can be used by web browsers (and other applications, but web browsers would be the main users).

[iso1631]

Shouldn't it be up to my OS to do that validation though, not the browser? After all when I ssh to my.server.com I want the same guarentee as when I https to it.

[ViViDboarder]

That’s not how SSH or HTTP work.

If you ssh to a server your OS will resolve the IP, but your SSH client will request and attempt to verify the server key. Same with browsers and HTTP.

[iso1631]

No, browsers won't do anything of the sort with HTTP. Or ftp. Or SMTP.

HTTPS sure. SMTP when they start a TLS session sure, FTPs too, there's protections at a higher level to ensure MITM isn't working, and you could probably argue that's a reason that DNSSec isn't required at all - after all get the wrong IP and your secure application won't do anything past the initial handshake. That's still leaking information though.

DNSSec, if used, is something that should sit in my DNS resolver, which should be part of my OS, not in my browser or ssh client - after all I might not want to use DNS, I might want to use a different protocol for resolving address lookups.

[londons_explore]

In an alternate universe, an application would call connect('google.com', secure=true), and the OS would make an encrypted connection and verify that the person on the other end of the connection really was google.com using dnssec published keys.

While that might have been a better design, the reality is OS's only provide API's for unencrypted connections and each application builds their own encryption and authentication on top of that.

[skissane]

> In an alternate universe, an application would call connect('google.com', secure=true), and the OS would make an encrypted connection

IBM's mainframe operating system z/OS (formerly known as MVS) has a feature called AT-TLS (Application Transparent TLS).

With AT-TLS, you can configure operating system policies to intercept TCP socket calls from an application, and automatically add TLS to the sockets. That way, some legacy app, which knows nothing about TLS, can have TLS support added to it, without any modifications required.

There is an IOCTL that can be called on the sockets, which can find out whether AT-TLS is enabled, what certificate is being used, etc. So applications can easily be enhanced to detect whether AT-TLS is enabled on a connection and respond differently.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/...

[iso1631]

In reality my browser says "connect to www.google.com on port 80", the the library eventually calling like getaddrinfo to translate the domain name to an IP address.

My OS resolves www.google.com to 123.45.67.8. It's the OS's responsibility to resolve the DNS, not the browser.

[teddyh]

That blog post is five years old, and most of the things it lists are now moot.

[londons_explore]

True, but dnssec is still going nowhere...

The future seems to be HTTPS with domain-validated certificates over insecure DNS, or even dnssec but doing the http challenge over an insecure network.

Great for state actors to inject malware into any site...