Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

obdev.at

Post reply on HN
Print view View original

31–40 of 215 posts

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

#31

Post by newaccount74 »

Spivak wrote: post #21
OptionOfT wrote: post #19

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.

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.

Shady shit? Not every network request is a call to an HTTP REST API.

Blocking socket APIs would break every app that supports other protocols. Goodbye file transfer apps, VPN apps, file sync apps, database tools, SSH clients, remote desktop clients, audio and video conferencing apps, etc.

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

#32

Post by Dalewyn »

OptionOfT wrote: post #19
unluckier wrote: post #6

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.

Seeing this getting downvoted is fucking wild.

I remember 20+ years ago when one of the most commonly seen attacks was malware configuring a proxy server in Internet Explorer which by design overrode the operating system's configuration.

What a lot of software does today by ignoring the operating system in lieu of their own shit is just like the above. If your program doesn't (or can't) respect the operating system, your shit is malware and you should reconsider who you write code for.

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

#33

Post by mannyv »

kelnos wrote: 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…

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

/s

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

#34

Post by krackers »

kelnos wrote: 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'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]

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

#35

Post by garyrob »

unluckier wrote: post #6

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

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.

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

#36

Post by TechRemarker »

unluckier wrote: post #6

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

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.

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

#37

Post by [deleted] »

josephcsible wrote: post #27
threeseed wrote: post #20

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]

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

#38

Post by 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?

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

#39

Post by jmull »

kelnos wrote: 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…

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

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

#40

Post by yndoendo »

Dalewyn wrote: post #32
OptionOfT wrote: post #19

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.

Seeing this getting downvoted is fucking wild. I remember 20+ years ago when one of the most commonly seen attacks was malware configuring a proxy server in Internet Explorer which by design overrode the operating system's configuration. What a lot of software does today by ignoring the operating system in lieu of their own shit is just like the above. If your program doesn't (or can't) respect the operating system,…

Those ideas are not isomorphic.

One malicious overrides universal network communication while the other just conducts DNS queries limited to a single application domain.

Post reply on HN