Chromium's Impact on Root DNS Traffic

Re:Chromium's Impact on Root DNS Traffic by londons_explore on Friday August 21, 2020 @11:14AM (#24235554)

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.

[ Parent | on HN ]

Re:Chromium's Impact on Root DNS Traffic by skissane on Friday August 21, 2020 @01:20PM (#24236896)

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

[ Parent | on HN ]

Re:Chromium's Impact on Root DNS Traffic by iso1631 on Friday August 21, 2020 @11:39AM (#24235764)

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.

[ Parent | on HN ]