FYI the standalone encrypted DNS profiles for macOS (.mobileconfig files) do not work if you're using Little Snitch or Lulu to block unwanted network traffic. This is a limitation of macOS that Apple hasn't bothered to fix.
You can have one or the other active at a time, but not both simultaneously. If you have the DNS profile turned on and then proceed to turn on Little Snitch/Lulu, the DNS profile will get turned off by macOS and whatever other DNS configuration you have will take precedence. It's mentioned in passing by Mullvad in the docs [0]:
> If you have more than one profile added then macOS seems to use only the last one that you installed. If you remove a profile then it appears that it will not use any of the other profiles.
This isn't unique to Little Snitch/Lulu and Mullvad though, you would run into the same problem with any application that creates a network filter by using a profile, see [1] for example. Since the full blown Mullvad VPN app does not use system profiles, it does work in tandem with Little Snitch/Lulu.
As a tangential aside: this limitation on Network Extensions is infuriating. I can understand why it exists, but one of the results is that if you’re using an Endpoint Security extension, it can’t also act as a filter.
I’ve never been able to get CrowdStrike Falcon and Little Snitch to work on the same machine because of this. It would be nice if you could have n filters (and a limit on n isn’t unreasonable).
Can you help me out with the threat model for encrypted DNS?
As I see it, the model is that I need to contact a site, and use DNS to get the IP - but either my ISP or my VPN provider can see I’m visiting that IP whether I looked it up just now, or knew it already.
So unless the model is I’m using a VPN, but am leaking via someone else’s logging DNS, I don’t really get it.
Personally my main motivation is I don't want anyone to snoop what sites I visit and then sell that data, my ISP included, but there are other issues too. To quote Cloudflare [0]:
> Queries could be directed to a resolver that performs DNS hijacking. For example, in the UK, Virgin Media and BT return a fake response for domains that do not exist, redirecting users to a search page. This redirection is possible because the computer/phone blindly trusts the DNS resolver that was advertised using DHCP by the ISP-provided gateway router.
Encrypted DNS isn't a perfect solution, because the request still won't go through the proxy, but at least it won't leak the info to your ISP (assuming you have something else configured as your DNS provider.)
I think it might become a little more useful in some contexts at least once ECH gets wider adoption. In that case afaik only the DNS server and the remote host you’re connecting to would know what FQDN you're connecting to—anyone else would only see the IP of the remote host. If the host serves requests for lots of different FQDNs, that’s less information going around.
One scenario comes to mind: multiple services under the same IP. “cutecats.com” and “hotintercourse.net” might both resolve to the same IP, but a reverse proxy resolves requests differently depending on the host. Then, knowing the IP but not the host, as your ISP does, becomes a meaningful difference.
In addition they also support optional content blocking[1] via blocklists, just set the desired TLS/HTTPS DNS server.
[1] https://github.com/mullvad/dns-blocklists