> you end up with no clear picture of which browsers support these records to which end.
> Unfortunately even the otherwise ever so useful https://caniuse.com/ does not provide that information
Not quite the same, but Cloudflare's statistics show that 8.1% of all DNS requests to its public resolver are for HTTPS RRs [0], and the statistics on the authoritative DNS server that I run [1] show that only 1.11% of requests were for an HTTPS RR.
I wonder why it’s not 14%, given that that’s the Safari market share, Safari is the only browser that does HTTPS DNS requests in its default configuration, and every https:// request should involve an HTTPS lookup?
A1: it’s naive to assume we’re at 100% https:// adoption? Any http:// URL will not trigger an HTTPS DNS lookup.
A2: site popularity and downstream caching of 1.1.1.1 means CloudFlare see fewer requests for HTTPS DNS than there are https:// connections?
> I wonder why it’s not 14%, given that that’s the Safari market share
That's Safari's market share among _browsers_, but lots of other stuff (IoT devices, mail servers, curl, etc.) can be configured to use 1.1.1.1.
> Safari is the only browser that does HTTPS DNS requests in its default configuration
I've opened [0] in both Firefox and Chromium on Linux, and it shows that ECH is enabled in both (which therefore means that HTTPS RRs are being queried). I don't think that I've changed any settings to enable this, but I was testing out ECH a few months ago, so I might have changed something then and forgotten.
> A1: it’s naive to assume we’re at 100% https:// adoption? Any http:// URL will not trigger an HTTPS DNS lookup
Cloudflare also has statistics on HTTP vs HTTPS [1], but that's going to be biased in favour of HTTPS since CF handles that automatically for sites they host.
> A2: site popularity and downstream caching of 1.1.1.1 means CloudFlare see fewer requests for HTTPS DNS than there are https:// connections?
Yup, but this also applies to A/AAAA records too, so this shouldn't make a difference to the ratio between different RR types.
> Cloudflare also has statistics on HTTP vs HTTPS [1], but that's going to be biased in favour of HTTPS since CF handles that automatically for sites they host.
Firefox has supported HTTPS DNS since v129 (August 6, 2024)
> HTTPS DNS records can now be resolved with the operating system's DNS resolver on specific platforms (Windows 11, Linux, Android 10+). Previously this required DNS over HTTPS to be enabled.
As for Encrypted Client Hello (ECH), the next step in privacy, I think the issue has been with the web servers. NGINX began supporting it a few days ago? Chromium and even Cloudflare supported it since 2023.
> you end up with no clear picture of which browsers support these records to which end.
> Unfortunately even the otherwise ever so useful https://caniuse.com/ does not provide that information
Not quite the same, but Cloudflare's statistics show that 8.1% of all DNS requests to its public resolver are for HTTPS RRs [0], and the statistics on the authoritative DNS server that I run [1] show that only 1.11% of requests were for an HTTPS RR.
[0]: https://radar.cloudflare.com/dns#dns-query-type
[1]: https://ns.maxchernoff.ca/
I wonder why it’s not 14%, given that that’s the Safari market share, Safari is the only browser that does HTTPS DNS requests in its default configuration, and every https:// request should involve an HTTPS lookup?
A1: it’s naive to assume we’re at 100% https:// adoption? Any http:// URL will not trigger an HTTPS DNS lookup.
A2: site popularity and downstream caching of 1.1.1.1 means CloudFlare see fewer requests for HTTPS DNS than there are https:// connections?
> I wonder why it’s not 14%, given that that’s the Safari market share
That's Safari's market share among _browsers_, but lots of other stuff (IoT devices, mail servers, curl, etc.) can be configured to use 1.1.1.1.
> Safari is the only browser that does HTTPS DNS requests in its default configuration
I've opened [0] in both Firefox and Chromium on Linux, and it shows that ECH is enabled in both (which therefore means that HTTPS RRs are being queried). I don't think that I've changed any settings to enable this, but I was testing out ECH a few months ago, so I might have changed something then and forgotten.
> A1: it’s naive to assume we’re at 100% https:// adoption? Any http:// URL will not trigger an HTTPS DNS lookup
Cloudflare also has statistics on HTTP vs HTTPS [1], but that's going to be biased in favour of HTTPS since CF handles that automatically for sites they host.
> A2: site popularity and downstream caching of 1.1.1.1 means CloudFlare see fewer requests for HTTPS DNS than there are https:// connections?
Yup, but this also applies to A/AAAA records too, so this shouldn't make a difference to the ratio between different RR types.
[0]: https://tls-ech.dev/
[1]: https://radar.cloudflare.com/adoption-and-usage#http-vs-http...
> Cloudflare also has statistics on HTTP vs HTTPS [1], but that's going to be biased in favour of HTTPS since CF handles that automatically for sites they host.
Chrome provides graphs of HTTPS adoption, the overwhelming majority of browsing is via HTTPS now: https://transparencyreport.google.com/https/overview?hl=en_G...
I'd bet the reason that Linux usage is lower is developers running local servers
> Safari is the only browser that does HTTPS DNS requests
Chrome does too. At least going by the reports on our subreddit: https://archive.vn/9o6Jc / https://www.reddit.com/r/rethinkdns/comments/1ox7g21
Firefox has supported HTTPS DNS since v129 (August 6, 2024)
> HTTPS DNS records can now be resolved with the operating system's DNS resolver on specific platforms (Windows 11, Linux, Android 10+). Previously this required DNS over HTTPS to be enabled.
https://www.firefox.com/en-US/firefox/129.0/releasenotes/
As for Encrypted Client Hello (ECH), the next step in privacy, I think the issue has been with the web servers. NGINX began supporting it a few days ago? Chromium and even Cloudflare supported it since 2023.
And even with alpn="h3" in my HTTPS RR, Chromium will still refuse without serving over TCP with a Alt-Svc header.
You can, but you may not.
[flagged]
Bad bot.