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.
Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
51–60 of 215 posts
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#52If 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.
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.
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#54It'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…
https://developer.apple.com/library/archive/documentation/Ne...
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#55> 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).
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#56> 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).
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#57Earlier 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.
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#58Does Little Snitch do things differently?
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#59Earlier 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.
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#60Earlier 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...