Firefox 83 introduces HTTPS-Only Mode

DNSSEC works I don’t really get that point.

The “root of trust” problem is hard to solve. I kinda hear the DANE guys’ argument, I’d rather trust one authority than a thousand.

I don't like applications that do their own DNS resolution. I use a text-only browser that relies on the OS to do DNS resolution.

But imagine your DNS is filtered. Would you still want only a single source, e.g., your ISP? In that case, wouldn't you want multiple sources?

When in a DNS-filtered environment, e.g., a hotel, DOH outside the browser can actually be useful. For example, I can retrieve all the DNS data for all the domains on HN in a matter of minutes using HTTP/1.1 pipelining from a variety of DOH providers. The data goes into a custom zone file served from an authoritative nameserver on the local network. Browsing HN is much faster and more reliable when I do not need to do recursive DNS queries to remote servers. The third party resolver cache concept is still really popular, but IME most IP addresses are long-lived/static and "TTL" is irrelevant. I rarely need to update the existing RRs in the zone files I create and the number that need to be updated is very small.

DOH servers are not the only alternative source of DNS data.

Ideally, I prefer to avoid third party DNS altogether. Nor do I even need to run a local cache. I wrote some utilities that gather DNS data "non-recursively", querying only authoritative nameservers and never setting the RD bit. It is very fast. The only true "single source" of DNS data is the zone file for the particular RR at the designated authoritative nameserver(s). Everone else is a middleman.

I am not a fan of applications doing their own DNS resolution, even if they use DOH. But I have found the existance of DOH servers, i.e., third party DNS caches served over HTTP, can be useful.

Right, so the question is why we should put a huge amount of effort into implementing and operating a system which doesn't make significant improvements.

> DNSSEC works I don’t really get that point.

It's mostly a layering question: if a new cryptographic algorithm is released or a problem with an old one comes out, browsers can update very quickly. Updating the operating systems and network hardware which implement DNSSEC takes considerably longer. DNSSEC lingered on 90s crypto for ages, key rotations were put off for years, etc. because everyone in this space has to be extremely conservative. That has security implications as well as delaying most attempts to improve performance or usability.

Similarly, browsers can have extensive UI and custom validation logic for HTTPS. A lot of that information isn't present if you use DNSSEC without implementing your own resolver, so you get generic error messages and you don't get control over the policies set by your network administrator. This is especially interesting both as a risk if you don't trust your ISP or for dealing with compromises — if I compromise your DNS server and publish DNSSEC records with a long TTL, your users are at risk until you can get every ISP with a copy to purge the cached records ahead of schedule.

All of those issues can be improved but it's not clear that there's enough benefit to be worthwhile.

> The “root of trust” problem is hard to solve. I kinda hear the DANE guys’ argument, I’d rather trust one authority than a thousand.

This is the best argument for DNSSEC but it's not clear to me how much difference it makes in practice when you're comparing the still nascent DNSSEC adoption to modern TLS + certificate transparency which also catches spoofing and is far more widely implemented.