[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.