Note that DoH (and DoT) shipped in iOS 14 and Big Sur, though aren't particularly easy to enable.
Specifically, you must install a properly configured .mobileprofile with HTTPS/TLS in the DNSSettings > DNSProtocol part of the payload (along with DNS server addresses of course). Merely pointing at a DoH/DoT supporting DNS server in the settings GUI won't do it, the OS doesn't do any probing and automatically use it just because it's available. For applications DNS Settings is covered under the Network Extension framework [0].
It's definitely nice Apple now has this built-in, and since they're onboard with Cloudflare/Fastly maybe this new twist will be pretty fast too. But obviously they're going to have to make this more automated for it to really make a widespread difference, ideally it'd simply see if the supplied DNS server (manual or DHCP) could run DoH/DoT and then just use it by default with no interaction required.
----
0: https://developer.apple.com/documentation/networkextension/d...
You can use something like iMazing Profile Editor [1] to create a .mobileprofile (which is just XML) to configure DoH or DoT.
Also, don't 'configuration profiles' require that your Mac have an associated AppleID?
There are several tools that can push configuration profiles to many macOS or iOS devices in one go [1]. It's also the kind of thing you don't want users in managed environments messing with if they don't know what they're doing.
Also, don't 'configuration profiles' require that your Mac have an associated AppleID?
I can't see why they'd be connected; being able to configure network settings isn't a "feature" related to having an Apple ID.
[1]: https://support.apple.com/guide/deployment-reference-macos/w...
> The target [resolver] sees only the [DNS] query and the proxy’s IP address. The proxy has no visibility into the DNS messages, with no ability to identify, read, or modify either the query being sent by the client or the answer being returned by the target. Only the intended target [resolver] can read the content of the [DNS] query and produce a [DNS] response.
> The whole process begins with clients that encrypt their query for the target using HPKE. Clients obtain the target’s public key via DNS, where it is bundled into a [SVCB/HTTPS] HTTPS resource record and protected by DNSSEC.
> Clients transmit these encrypted queries to a proxy over an HTTPS connection. Upon receipt, the proxy forwards the query to the designated target. The target then decrypts the query, produces a response by sending the query to a recursive resolver such as 1.1.1.1, and then encrypts the response to the client. The encrypted query from the client contains encapsulated keying material from which targets derive the response encryption symmetric key.
> ...50% of the time ODoH queries are resolved in fewer than 228ms.
BTW, DNSCrypt supports "oblivious" encrypted DNS queries via what it calls Anonymized Relays https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-D...