Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

[kelnos]

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?

[krackers]

>so presumably there's some other low-level non-blocking call

Correct, CFNetwork is open source so you can check implementation but last I remember it used some variant like `getaddrinfo_async`. But Apple really doesn't want you (the end-user) to use getaddrinfo (or the async variant CF exposes) to resolve an IP and then directly connect() via that ip, everything is geared towards connect-by-hostname since then Apple's can internally handle the implementation of happy-eyeballs.

Edit: You can read https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf for their thoughts on why they don't like the getaddrinfo() model [there are speaker notes at the bottom of each slide]

[jmull]

> It's a little weird to me that getaddrinfo() is considered a "low-level legacy API"

I don't think it is considered legacy. The blog post gets that wrong.

(Whether it's "low-level" or not just depends on your perspective.)

[matheusmoreira]

> getaddrinfo() is the way to resolve names on Linux

Not at all. That's just a glibc function, it's got nothing to do with Linux. People just assume that glibc is how things are done in Linux user space but it doesn't have to be that way. For example, systemd came up with its own resolved mechanism which turned out to be much better than the glibc stuff. I will probably end up inventing my own at some point as well since I'm working on freestanding software targeting Linux.

[brynet]

> getaddrinfo() is the way to resolve names on Linux and I suspect the *BSDs.

At least on OpenBSD, all classical/standard DNS functions (getaddrinfo/gethostbyname/...) are wrappers around OpenBSD's libc asr implementation, written by Eric Faurot.

https://man.openbsd.org/man3/asr_run.3

https://github.com/openbsd/src/tree/master/lib/libc/asr

[pushupentry1219]

> Maybe things are drastically different on macOS, but getaddrinfo() is the way to resolve names on Linux and I suspect the *BSDs.

I'm not sure if this is the case in this case, but it might be worth noting that some system functions with the same name have drastically different internal/implementation differences between Linux/*BSD/MacOS. With there being differences between the *BSDs too.

So on some systems one function call is "the way", because its been maintained over the years, but then on another it might actually be old and not useful.

[adastra22]

Everything in the UNIX compatibility layer is low-level in macOS. Not necessarily "legacy" though.

But this is no different than saying that, for example, calling out platform-specific native OS APIs from Java is "low-level." Which it is, from the perspective of compile-once, run-anywhere Java applets. macOS is a NeXT-compatible non-UNIX API, and you are supposed to use the macOS frameworks for everything. Calling down to BSD or even mach is definitely not what Apple wants you to do.

[pjmlp]

For quite some versions that modern networking APIs on macOS using Objective-C frameworks, starting in 2018.

See WWDC 2018's "Introducing Network.framework, A modern alternative to sockets".

NeXTSTEP might have been a UNIX, and macOS derives from it, but the whole UNIX story has always been to bring UNIX software into the platform, not to make it easier to move elsewhere.

[unethical_ban]

I'll pile on, as someone who has never developed for Apple systems: What APIs are supposed to be used for DNS resolution?

  * Host file
  * Configured DNS server
  * App-specific DNS server if it exists

What "API" is there? Why doesn't an app doing system-wide DNS modifictions just modify the settings for default resolver?

[egberts1]

Of course, Apple does not want their app to call `getaddrinfo()` directly, because it would interfere with their internal XDR/NDS/IPS mechanism.

I can’t blame them but I personally would still have my apps use them, even knowingly that it would be made off-limit to iOS/iPadOS apps … soon.

[inopinatus]

The correct term is "heirloom".

[ajross]

Yeah, this report seems a little spun. The essence is basically that the encrypted DNS needs to go through the proxy, and there's resolver code elsewhere in the OS that doesn't use the proxy. It's a bug, sure. It could plausibly have interesting exploits, though none are shown. But it's not a very interesting bug.

[ransom1538]

Wait until you try to get the mac address on an iphone.

[mannyv]

Yes, things are drastically different on MacOS. There's like a whole nother level of APIs ip there

/s

[dwighttk]

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

[leeter]

Dang can we get an update to the title to reflect this?

[asplake]

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

[taspeotis]

Did they test it ever worked with getaddrinfo? Or did they just see it worked once with CFNetwork and called it a day and then later publish a blog post saying it’s broken?

[TheJoeMan]

It's ridiculous us developers still have to jump through hoops to save around older versions of the OS for testing. There is 0 technical reason why Apple can't let us downgrade.

[mattl]

Which is pretty wild too, considering they're selling the product and the new OS came out yesterday.

[unluckier]

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

[lapcat]

I can't reproduce this. Some people say it has to do with ESET: https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...

[TechRemarker]

Before Sequoia when using OpenDNS for VPN, could be on VPN and iMessage and other apps still work, but since Sequoia, when on VPN iMessage (text messages) etc no longer work. Once I disconnect to VPN all goes through. Is this related at all? Do have macOS firewall enabled. But not block all incoming connections.

[garyrob]

After upgrading to Sequoia, I could not browse with Safari or Mozilla. What fixed it for me was to go to the DNS settings for my Wi-Fi connection, and add Google's DNS servers (8.8.8.8. and 8.8.4.4). They replaced the autofilled DNS servers that were there.

[OptionOfT]

Honestly, I'm fine with that. Applications themselves should not be resolving DNS outside of what I set in settings.

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.

[skrrtww]

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.

[Reptur]

Devil's advocate would say: They could do this and make it look like a bug that never gets fixed in order to avoid backlash. How it gets achieved is flexible if the goal is met.

[pkulak]

Yeah, if it was intentional, it would probably be a hard-coded, encrypted URL. Some devices are starting to do that to get around ad blocking.

[elashri]

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.

[OJFord]

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?

[kccqzy]

If the OS allows the registration of a DNS proxy, and some calls bypass the proxy, it's squarely an OS bug.

[xyst]

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)

[newaccount74]

getaddrinfo() is not a legacy API, it's a standard cross platform API for doing DNS lookups.

[Legion]

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

[tankenmate]

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

[hypeatei]

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

[newaccount74]

Apple removed support for kernel extensions, and instead added a bunch of APIs that allow to do network filtering etc in user space. Unfortunately, some of their networking code just bypasses those network filter extensions (probably because of bugs) -- this is not the first time the developers of Little Snitch publicized a bug like this.

[lapcat]

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

[ggm]

"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"

[egberts1]

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

[jms703]

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.

[Reason077]

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

[Mainsail]

What am I missing here? Reading the article, it appears that Firefox is the browser that seems to be bypassing.

[spr-alex]

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.

[Avamander]

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?

[bradgessler]

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?

[unluckier]

See: https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...

If disabling the firewall (for testing) solves this problem, this is likely your issue.

[pkilgore]

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?

[tpmoney]

No this appears to be if an application registers a DNS resolver proxy on the local system, getaddrinfo doesn't use the proxy, and presumably just hits whatever the network interface's configured DNS server is.

[theonealtair]

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

[zjp]

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?

[rapatel0]

If pihole is using DNS encryption for upstream lookups, the this would only affect you on your local network.

In other words, it would be unencrypted to the pihole but encrypted when going out to the internet.

[jedisct1]

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

Does Little Snitch do things differently?

[mzs]

the (complicated) rules:

  man 5 resolver

also try with a domain that exists

[PaulDavisThe1st]

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

[gsich]

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.

[gigatexal]

I wonder if this affects iOS, too

[jesse_faden]

I would believe so. I have a custom DNS profile setup that redirects a few domains to a server I run. The server has custom SSL certs issued by a private CA. I the certificate installed on iOS as a trusted root certificate.

Everytime I'm connected to my home WiFi I would randomly get `peer closed connection in SSL handshake (104: Connection reset by peer)`. I have absolutely no clue why it does this and this issue goes away when I'm connected on mobile data.

Now I'm guessing that it is bypassing the DNS profile and resolving it using my ISPs DNS or some other way.

[Jemm]

Apple ignoring standards again.

[zimpenfish]

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

Not really.

[sleepybrett]

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

[system7rocks]

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.