Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

535 点作者 HelenePhisher8 个月前

30 条评论

kelnos8 个月前

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?

评论 #41572770 未加载

评论 #41572882 未加载

评论 #41574441 未加载

评论 #41576046 未加载

评论 #41573614 未加载

评论 #41574996 未加载

评论 #41577339 未加载

评论 #41572477 未加载

评论 #41579808 未加载

评论 #41576374 未加载

评论 #41574398 未加载

评论 #41574350 未加载

评论 #41572756 未加载

dwighttk8 个月前

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

评论 #41579036 未加载

asplake8 个月前

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

评论 #41573255 未加载

评论 #41574293 未加载

评论 #41573241 未加载

unluckier8 个月前

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". <a href="https://waclaw.blog/macos-firewall-blocking-web-browsing-after-upgrading-to-sequoia/" rel="nofollow">https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...</a>

评论 #41573439 未加载

评论 #41572823 未加载

评论 #41572774 未加载

评论 #41572530 未加载

skrrtww8 个月前

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.

评论 #41572513 未加载

评论 #41572295 未加载

elashri8 个月前

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.

OJFord8 个月前

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?

评论 #41576090 未加载

xyst8 个月前

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)

评论 #41572590 未加载

Legion8 个月前

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

tankenmate8 个月前

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] <a href="https://github.com/folbricht/routedns">https://github.com/folbricht/routedns</a>

hypeatei8 个月前

> After further investigation, we found that this bug has already existed at least since macOS 14.5 SonomaIsn'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.

评论 #41572645 未加载

lapcat8 个月前

Dupe: <a href="https://news.ycombinator.com/item?id=41568128">https://news.ycombinator.com/item?id=41568128</a>

ggm8 个月前

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

egberts18 个月前

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.<a href="https://tailscale.com/blog/sisyphean-dns-client-linux" rel="nofollow">https://tailscale.com/blog/sisyphean-dns-client-linux</a>

jms7038 个月前

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.

Reason0778 个月前

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

评论 #41573206 未加载

spr-alex8 个月前

Plugging <a href="https://www.supernetworks.org/" rel="nofollow">https://www.supernetworks.org/</a> -- 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.

Avamander8 个月前

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?

bradgessler8 个月前

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?

评论 #41572255 未加载

pkilgore8 个月前

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?

评论 #41573731 未加载

theonealtair8 个月前

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

zjp8 个月前

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?

评论 #41573862 未加载

jedisct18 个月前

The standard way to use dnscrypt-proxy is to set the resolver to 127.0.0.1.Does Little Snitch do things differently?

mzs8 个月前

the (complicated) rules:<pre><code> man 5 resolver </code></pre> also try with a domain that exists

PaulDavisThe1st8 个月前

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

gsich8 个月前

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.

gigatexal8 个月前

I wonder if this affects iOS, too

评论 #41576867 未加载

Jemm8 个月前

Apple ignoring standards again.

评论 #41578710 未加载

sleepybrett8 个月前

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

system7rocks8 个月前

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.