Live data from Hacker News

Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

obdev.at

51–60 of 215 posts

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#51

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

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.

I have one browser setup to do DNS differently than another. I don't want to have to set it at a system level and then need multiple systems just to run 2 browsers with different DNS lookup

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#52
post #5

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)

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

it is apparently on Mac and arguably with good reason. See this comment https://news.ycombinator.com/item?id=41572770

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#53

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

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

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#54
post #15

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…

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

If you do need the lower-level control, Apple does still recommend `getaddrinfo`. It handles NAT64 translation for IPv6-only carrier networks:

https://developer.apple.com/library/archive/documentation/Ne...

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#55
post #3

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

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

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#56
post #3

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

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?

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#57

Earlier quoted context omitted.

> This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures. https://github.com/apple/swift-async-dns-resolver

It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.

no no, it's just "ours is better", "think different", and "it just works". /s

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#59

Earlier quoted context omitted.

> This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures. https://github.com/apple/swift-async-dns-resolver

It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.

As near as I can tell, Apple doesn't call it a legacy API. The article does, but the article wasn't written by nor does it appear to be quoting Apple.

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#60

Earlier quoted context omitted.

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

If you do need the lower-level control, Apple does still recommend `getaddrinfo`. It handles NAT64 translation for IPv6-only carrier networks: https://developer.apple.com/library/archive/documentation/Ne...

I'm actually surprised they suggest getaddrinfo() directly over the async CF wrapper.
Post reply on HN