Live data from Hacker News

Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

obdev.at

41–50 of 215 posts

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

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

Specifically defined by POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/functions/g...

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

#42
post #35

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.

> could not browse with Safari or Mozilla

FYI, it looks like Firefox fixed this.

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

#43
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's POSIX which Apple generally abides by except for timer_create. macOS is historically officially a UNIX, which would require getaddrinfo.

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

#44
post #35

Earlier quoted context omitted.

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.

> could not browse with Safari or Mozilla FYI, it looks like Firefox fixed this.

So not macOS error?

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

#45
post #21

Earlier quoted context omitted.

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.

As long as I can add exceptions for those apps to my firewall, I’m kind of… okay with that?

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

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

#47
post #32

Earlier quoted context omitted.

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.

>just conducts DNS queries

Queries that will ignore configurations you set.

If I see something ignoring/evading my configured DNS server, that shit is fucking malware.

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

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

Funny how that goes: macOS is POSIX certified but no other desktop BSD or Linux is.

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

#49
post #44

Earlier quoted context omitted.

> could not browse with Safari or Mozilla FYI, it looks like Firefox fixed this.

So not macOS error?

> not macOS error?

It worked before I upgraded to Sequoia. But I don't know enough to point fingers. Just mentioning that turning off the firewall long enough for Firefox to update fixes the problem.

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

#50

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?

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

We recently had a developer join our team and he got stuck setting up his dev environment.

We use a .dev domain as a localhost alias, and turns out his ISP’s DNS wouldn’t resolve 127.0.0.1 (or whatever it is) for the .dev domain. Changing his resolver at the network level to 1.1.1.1 fixed it.

I imagine there are lots of difficult support tickets for app devs, and at a certain point they just hardcode the DNS to remove one variable from the equation when debugging bug reports.

Post reply on HN