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

71–80 of 215 posts

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

#71

Post by greyface- »

garyrob wrote: post #35
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.

Were the autofilled DNS servers in RFC1918 private space (10.0.0.0/8, 192.168.0.0/16, etc.)? I had issues after the upgrade with Google Chrome being unable to access hosts in these ranges, and fixed it by going to System Settings -> Privacy & Security -> Local Network and toggling Google Chrome off and on again.

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

#72

Post by Reason077 »

Mainsail wrote: post #53
Reason077 wrote: post #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.

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

They're using Little Snitch as an OS-level DNS proxy, which should intercept all DNS requests from any app and encrypt them. But, depending on what API the app uses for its DNS lookups, some DNS requests do not go via the proxy. Presumably Firefox, in its default configuration with DNS encryption set to OFF ("Use your default DNS resolver"), uses one the affected APIs.

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

#73

Post by mzs »

krackers wrote: post #34
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…

indeed: https://opensource.apple.com/source/Libinfo/Libinfo-222.1/lo...

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

#74

Post by garyrob »

greyface- wrote: post #71
garyrob wrote: 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.

Were the autofilled DNS servers in RFC1918 private space (10.0.0.0/8, 192.168.0.0/16, etc.)? I had issues after the upgrade with Google Chrome being unable to access hosts in these ranges, and fixed it by going to System Settings -> Privacy & Security -> Local Network and toggling Google Chrome off and on again.

No, they weren't local. I have no idea where they came from. I couldn't even delete them, but when I added the Google servers, they autofilled ones were automatically deleted.

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

#75

Post by lxgr »

X-Istence wrote: post #69
cj wrote: post #50

Earlier quoted context omitted.

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

Not resolving 127.0.0.1 or RFC1918 addresses or even ULA for IPv6 is done to avoid DNS rebinding attacks. For most end users that is probably the correct move.

My home router even seems to inspect any UDP/53 traffic and redact any responses containing local/private A entries, so not even switching to a public resolver bypasses the protection.

I agree that it’s usually the right behavior.

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

#76

Post by altruios »

yndoendo wrote: post #40
Dalewyn wrote: 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.

You are describing something that violates system setting for it's own benefit instead of the end user.

You are describing malware. Benign malware is still malicious, even if it does no active harm. Intent (of how the software operates) matters.

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

#77

Post by threeseed »

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.

You actually think that a Swift developer, developing against Cocoa APIs, targeting Mac and iOS devices cares about a portable API.

Because not sure if you know this but the entire software industry is built on high level libraries on top of largely portable code. For example this Swift library wraps c-ares a portable API.

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

#78

Post by troyvit »

cj wrote: post #50
roywashere wrote: post #22

Earlier quoted context omitted.

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

Wayyyy back in 1995 or '96 I was working for a non-profit called "Next Generation Magazine" and our goal was to have young people write content for web sites to get their names out there. Back then it was all local ISPs, so we went to our ISP and asked for ngm.org and were stoked when we got it! We built out the site (Thanks to Building Killer Websites of course) and it looked awesome!

Only problem was that nobody in my family out of state could see it. It took awhile to realize realize that we never bought that domain. Our local ISP just added it to their DNS records, and since we all hooked into them we thought we were live across the 'net.

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

#79

Post by pushupentry1219 »

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…

> Maybe things are drastically different on macOS, but getaddrinfo() is the way to resolve names on Linux and I suspect the *BSDs.

I'm not sure if this is the case in this case, but it might be worth noting that some system functions with the same name have drastically different internal/implementation differences between Linux/*BSD/MacOS. With there being differences between the *BSDs too.

So on some systems one function call is "the way", because its been maintained over the years, but then on another it might actually be old and not useful.

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

#80

Post by kccqzy »

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.

Well but the portable API is too low-level and error prone. What is the last time you used getaddrinfo? How often do you actually need to use it?

One can make a good technical argument based on the merit of the portable API without immediately resorting to the EEE argument.

Post reply on HN