macOS Sequoia 15 may bypass DNS encryption

It's a little weird to me that getaddrinfo() is considered a "low-level legacy API". Maybe things are drastically different on macOS, but getaddrinfo() is the way to resolve names on Linux and I suspect the *BSDs.

Sure, I expect most macOS apps will use something in Foundation or some other NetworkKit-type framework to do DNS queries, but it's odd to me that the code there wouldn't then call down to getaddrinfo() or the like to do the dirty work. I guess GAI is blocking, so presumably there's some other low-level non-blocking call?

>UPDATE: Spoke too soon… The problem discussed here turned out to be specific to Little Snitch 6.1 and not a general issue in macOS. It will be fixed in an update of Little Snitch later today.

> Update 2024-09-17, 7:10 p.m.

> After further investigation, we found that this bug has already existed at least since macOS 14.5 Sonoma (maybe even earlier, but we currently don’t have access to an older 14.x system for testing).

Sequoia also breaks an application's ability to use DNS (or presumably anything UDP-based) if the macOS firewall is enabled, and an app is listed as "Block incoming connections". https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...

The title sort of implies this is intentional or privileged to Apple, while it rather seems more like just a bug.

I also wish people would post the FB numbers and the details of their report when they say they've reported things like this.

I maybe imagining but I feel like deja vu that there will be a problem with DNS that would affect Little snitch., Mullvad and others with new releases of iOS and Mac. If true I would really question what apple is doing during their months long developer and beta testing.

I was confused at the Little Snitch mention, and then reading further it just seems like a LS bug, that it only works in certain cases.

Well, seems this is the LS blog, so only confusion is why this is portrayed as a macOS bug? I'm not saying it's wrong, it's their domain not mine after all, it just doesn't seem to be justified in TFA?

If I recall, Apple deprecated use of certain network apis for third party developers. But Apple’s own apps (App Store) do not have these same restrictions. Thus, when trying to filter network traffic via app firewall via new APIs. It would fail since App Store uses legacy APIs.

Maybe part of this old bug (that I thought was fixed)

I always love the announcements of, "Bug found in new OS release! EDIT: Actually it's been there for a while!"

I use routedns [0] as my local stub resolver so that I can pick and choose which requests go to where and also what transport they use. It can also blocklist, re-write, cache, load balance, and/or handle fall back requests; so it give you lots of control.

I use a stub listener on localhost:53 for local requests and then forward them via UDP QUIC (TLS 0-RTT) requests to Cloudflare (1.1.1.1) with caching for most requests. Fast and reasonably secure.

[0] https://github.com/folbricht/routedns

> After further investigation, we found that this bug has already existed at least since macOS 14.5 Sonoma

Isn't this an inherent risk when attempting to do network stuff in userspace? You're at a very high level so hoping that lower level things comply seems risky if DNS encryption is critical to your use case.

Dupe: https://news.ycombinator.com/item?id=41568128

"Mac OSX has complex paths into name-to-address translation and a single entrypoint is not well enforced."

this is not "bypass encryption" this is "uses a range of ABI/API bindings in code which don't expose well into a single control point"

The battle of DNS resolving ownership rages on: who has the rights to set the DNS nameservers/resolver.

As a long-time DNS security researcher, the ultimate and final end means would be to mirror the root servers, but I assert, for now, popping in your own `resolv.conf` should suffice, … again, for now.

https://tailscale.com/blog/sisyphean-dns-client-linux

I wonder how little snitch sets the dns encryption up. In macOS, you need to setup encrypted dns via a profile System (Settings => General => VPN, DNS & Device Management) and then in the browser. However, I think terminal and appstore still use whatever server is obtained via DHCP and is not encrypted.

> "To protect (DNS lookups) from prying eyes, Little Snitch 6 offers a new feature: DNS encryption."

Browsers such as Firefox have offered this directly for a while. Of course, that only covers DNS lookups made from the web browser, but it doesn't rely on OS-level hooks that (at least in Apple's case) can break.

Plugging https://www.supernetworks.org/ -- when on wifi/vpn all DNS will go up over DNS over HTTPS as plaintext DNS is DNAT'd to CoreDNS which is by default configured to use DoH.

Deploying DNS encryption on macOS is in general really tedious. Applying it as a system or user profile has different results. Switching between providers or temporarily disabling DNS encryption is painful.

I also still haven't figured out how to get SSID-based switching to work, does it even?

I’ve had issues using the Resolv library in Ruby when I’m connecting to the internet via a tethered iPhone. Never ran into that until Sequoia. I wonder if that’s related?

TBH I’m too lazy to dig in and find out. Has anybody else run into this issue?

My read of this is that it shouldn't affect pi.hole given the system's default nameserver would still received by DDNS and thus be the pi.hole? Or do these requests go somewhere that's hard-coded?

This is why I firewall egress port 53 at the router level.

Am I susceptible to this if I redirect all DNS traffic on my network to a pihole, which is the only device I let make external DNS requests?

The standard way to use dnscrypt-proxy is to set the resolver to 127.0.0.1.

Does Little Snitch do things differently?

the (complicated) rules:

  man 5 resolver

also try with a domain that exists

Can some ELI5 why you'd use a proxy rather than reset the server name?

Why is a DNS proxy needed? My assumption is that you configure DoT or DoH (which I interpret as DNS encryption) somewhere in the settings of the OS.

I wonder if this affects iOS, too

Apple ignoring standards again.

macos may bypass LITTLE SNITCH'S encrypted dns proxy, more like it.

Hmm. I use NextDNS for this feature. I think. May have to do some testing to see whether or not it is operational at all.