Live data from Hacker News

Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

obdev.at

21–30 of 215 posts

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

#21

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.

Yep, I wish they would go the full way and block socket access entirely so your own outgoing traffic is always introspectable even with cert pinning. It would make it blatantly obvious when apps try shady shit.

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

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

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?

Yes, this! I even wonder how else you would do this. By the way I worked with many IoT devices that do not use your dhcp dns but just hardcode quad 8 or similar

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

#23

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.

There is no such thing as a remotely cross-platform DNS resolution API that has the system do the lookup and does not utterly suck for asynchronous use.

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

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

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

#25
post #4

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

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.

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

#26

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.

All major browsers now implement the ability to use a browser-defined resolver.

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

#27

Earlier quoted context omitted.

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?

> 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

#28
post #23

Earlier quoted context omitted.

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.

There is no such thing as a remotely cross-platform DNS resolution API that has the system do the lookup and does not utterly suck for asynchronous use.

[deleted]

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

#29

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.

[deleted]
Post reply on HN