I specifically do not want each application having it's own resolver. That's something operating system has to provide and is configured by administrator, for everything. Some systems go even further and do not allow outcoming traffic on port 53 for proces other than system resolver. Masquerading that as 443 opens a new problem.
You don't have to trust anyone, you can run a recursive resolver too. Even some home routers do that already.
Sure, that's fine. I'm just responding to "... something nobody has asked for," and below it, "No, [you didn't want the thing you say you want], you wanted [other thing]."
Not everyone wants the thing I want. But that's different from nobody wanting it.
(However, a system-wide DNS resolver using DNS-over-HTTPS is definitely a thing I want! I've been considering writing an NSS module in Rust for it, as a way to play with writing a loadable module with tokio, to see if that even works.)
Sure, system-wide DNS resolver using DNS-over-HTTPS (and the autodiscovery using DHCP/RA!) would be a good thing; each app going rogue and piercing through your policies/DNS/firewall is not.
In most Linux setups the resolver is the libc which means each application does have it's own resolver (though commonly dnsmasq or systemd-resolved is used as a local resolver/proxy for DNS). Libc also implements all the stuff around /etc/resolv.conf and /etc/hosts.
You might have noticed that Firefox runs in a lot of messed up environments, where, for example, bad installers downloaded by the user have done many bad things to the OS, including installing bogus hosts files which block known anti-virus and anti-malware websites. Firefox had a huge crackdown on malicious toolbars and extensions, and that was a good thing for most people. Do you have a clever suggestion for how Firefox might take your concept of trusting the OS and some administrator, which doesn't exist for most home users, and make it secure against malicious installers?
This is true, but most malware is neither high-effort nor high-quality. It's very easy to edit /etc/hosts. It's a lot harder to inject yourself into the binary in a way that works. It's harder still to inject yourself into the binary in a way that works if the binary is actively trying to not be injected into, or using some security-by-obscurity scheme for signing the config, or whatever. Yes, it's all running at the same privilege level (or lower) and the malware technically has the access, but it's not cost-effective to have battle-hardened automatic reverse-engineering tech built into your malware.
Chrome in particular has a DLL blacklist that seems to work very well in practice: in theory, a DLL blacklist can't possibly work, but in practice, DLLs don't try hard enough to hide their existence from the blacklisting code. https://www.chromium.org/Home/third-party-developers#TOC-Goo...
The fun with malware will only start, once it starts finding it's command and control centers using DNS-over-HTTPS to a shadow DNS served by botnet and you won't be able to filter out it's traffic.
Yes, and configure each app on each computer separately, instead of DHCP or RA, and if you miss some app, it will masquerade it's resolving among the rest of https traffic. Great. That's progress /s.
You don't have to trust anyone, you can run a recursive resolver too. Even some home routers do that already.