Hacker News Reader

Comment by kisamoto | Hacker News Reader

Mullvad encrypted DNS is also available to all - whether paying for VPN services or not.

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

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.

Doesn't work how? Little Snitch / Lulu don't use the profile? As in DNS traffic is not encrypted?

Little Snitch / Lulu die?

Do you have like a ticket for more explanation?

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.

[0] https://mullvad.net/en/help/dns-over-https-and-dns-over-tls#...

[1] https://git.codeproxy.net/paulmillr/encrypted-dns/issues/13

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).

I guess the solution is to use unbound

Even when I don’t use any firewall app, the DNS profile doesn’t work on macOS. There is a bug that other apps (and even system) can bypass it.

Not like in iOS, DNS profile work very well.

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.

[0] https://blog.cloudflare.com/dns-encryption-explained/

Cant your ISP reverse lookup the IPs you connect to based on your IP headers anyways?

They can, but pretty much everything will reverse lookup to Cloudflare or AWS.

SNI reveals the exact site though

As I understand it, this is now being addressed by ESNI[1] and ECH[2]. Hopefully ECH will continue being more widely deployed.

[1] https://www.cloudflare.com/learning/ssl/what-is-encrypted-sn...

[2] https://blog.cloudflare.com/encrypted-client-hello/

Rather amusingly, the massive centralisation of the internet, which is bad for privacy in every other way, actually protects you here.

Yep, cloudflare dns proxy essentially hides your origin ip addresses.

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.

DNS leaks have historically been a thorn in the side of the Tor project, if I understand correctly.

Sure, you might have a SOCKS proxy configured for the HTTP request, but depending on how the program makes the DNS query, it might bypass that proxy: https://support.torproject.org/misc/check-socks-dns-leaks/

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.)

Obviously, this isn't limited to just Tor.

Your connection is encrypted through https. Your DNS lookups aren’t yet though. Your ISP or network manager could have access to that data.

A vpn reduces speed and battery life

Good point.

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.

Reply on news.ycombinator.com