There is no such thing as a remotely cross-platform DNS resolution API that has the system do the lookup and does not utterly suck for asynchronous use.
I suspect "cross-platform" is doing a lot of heavy lifting for your claim. Browser engines and application frameworks built on top of them have no trouble using platform-specific APIs under the hood.
I remember 20+ years ago when one of the most commonly seen attacks was malware configuring a proxy server in Internet Explorer which by design overrode the operating system's configuration.
What a lot of software does today by ignoring the operating system in lieu of their own shit is just like the above. If your program doesn't (or can't) respect the operating system, your shit is malware and you should reconsider who you write code for.
If you consider the source of income of what's most likely a considerable portion of the HN community, I think this makes more sense. Apple is one of the only companies interested in preventing tracking, and it hurts, in the billions sort of way [1][2].
At some point in my copious spare time, I plan on writing software to allowlist in my firewall outbound connections only to IPs resolved using my DNS servers.
You could also configure your router to intercept rogue plaintext DNS lookups on your network with responses from a resolver you trust (for example a Pihole, Cloudflare or Google Public DNS, Quad9, PCH, etc). Adding something like Pihole would give you comprehensive blocking and custom internal DNS entries too.
I already redirect DNS queries to my own DNS servers running unbound, and block UDP and TCP ports 25 from machines other than these from going out on the Internet.
This will force machines misconfigured with 8.8.8.8 as default resolver (cough, systemd) from leaking my browsing history to Google, thank you very much, but won't stop DNS-over-HTTPS like Firefox, or more insidious devices like fallback IPs hardcoded in SmartTVs and other IoT devices (they are on their own VLAN with all traffic logged, but it's not as if I have time to inspect their traffic for suspicious behavior. There are blocklists of DoH, but at that point it becomes a whack-a-mole game, and it makes more sense to block anything that is not the result of a legitimate DNS query instead.
This would only be enforced on untrusted machines like Macs, iPhones, Android devices, IoT devices and Ubuntu machines, as opposed to trustworthy OpenBSD and Alpine Linux servers.
How would that work? Do you only access a really small/known set of IPs? Or would you program the firewall to only allow connections to an arbitrary IP if it had seen a DNS query to your preferred servers go out and return that IP within a few seconds prior?
In the latter case, would you have to aggressively disable local DNS caching on devices to make the behavior work (is that even possible on some devices)? How would encrypted DNS fit into this scheme?
The second. The only way untrusted devices connect is to IP addresses that were resolved by my DNS servers so I know what traffic is happening on my network. My DNS servers handle their own encryption via WireGuard to bypass ISP snooping, so I don't need Mozilla's DoH and Apple's and CloudFlare's I do not trust at all.
To avoid race conditions, the trusted DNS servers would add the result IP to the firewall allowlist table before returning it to the client, so either implement it as a Caddy proxy module (I already wrote a DynDNS module for Caddy so I know how to make that work). Or alternatively use unbound's dnstap support. I just need to implement some reliable and secure protocol to send those requests from the DNS server to my OpenBSD firewall running pf.
I am fine with the only Java application I have used in the lease decade not working. I did not even bother putting a JVM on any of the OS I installed in the last 5 years. So yeah, I’d rather have fewer security holes.
I have one browser setup to do DNS differently than another. I don't want to have to set it at a system level and then need multiple systems just to run 2 browsers with different DNS lookup
Yep, I wish they would go the full way and block socket access entirely so your own outgoing traffic is always introspectable even with cert pinning. It would make it blatantly obvious when apps try shady shit.
I had a great Windows firewall like this about 20 years ago. It would pop up a dialog for every network request from an app. You could block or allow based on port or destination, or "block all". It was amazing, because as you say, it made it very obvious when an app was trying shady shit.
I would love to have that back, but I was never able to find a firewall so hostile to the user experience of the general population.
It sounds similar in spirit to Little Snitch, mentioned in the article (on macOS, but which inspired OpenSnitch, which runs on Linux). It is awesome indeed, if a bit overwhelming at first. Most regular users would just uninstall it to avoid the constant barrage of requests initially, and then every time a new piece of software tries to connect to anything.
Shady shit? Not every network request is a call to an HTTP REST API.
Blocking socket APIs would break every app that supports other protocols. Goodbye file transfer apps, VPN apps, file sync apps, database tools, SSH clients, remote desktop clients, audio and video conferencing apps, etc.
The reasons applications do this is to prevent users from blocking telemetry etc. It's my computer, I should have final say on what goes out.