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

111–120 of 215 posts

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

#111

Post by matheusmoreira »

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…

Thanks for that link, it's a very convincing presentation that very clearly explains the shortcomings of getaddrinfo.

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

#112

Post by matheusmoreira »

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.

It's not necessarily EEE. Maybe it's just that the old wheel sucks. They want a better wheel and so they reinvented it, hopefully better this time.

The corporations making proprietary software are not the only ones who have that attitude. I've resolved to make all my free software Linux-exclusive so that I can use Linux to the fullest. The Linux kernel is packed full of exclusive non-portable features that very few people take advantage of because they're obsessed with portability, POSIX compliance or whatever. I think that's a waste.

Portable software is usually sucky lowest common denominator software. We should not limit ourselves to whatever glibc offers.

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

#113

Post by ryandrake »

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.

It's the same thing they did with Metal. Portable OpenGL is now "legacy." Straight from the 90s Microsoft playbook.

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

#114

Post by SOLAR_FIELDS »

matheusmoreira wrote: post #111
krackers wrote: post #34

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

Thanks for that link, it's a very convincing presentation that very clearly explains the shortcomings of getaddrinfo.

Yeah, I went in thinking that it was going to be some case of Apple wanting to bend the Unix philosophy to their will for their own desires and steer implementations in their direction, but no - they are simply pointing out a clear flaw in the design of the function in question for a usecase that does not apply only to Apple. Basically all OS vendors need to be doing something like this usecase to support IPv6 adoption.

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

#115

Post by simscitizen »

conradev wrote: post #54
krackers wrote: post #34

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

That’s not the current documentation, as evidenced by the “archive” in the URL.

If you want to stay at a lower level the recommendation these days is to use Network.framework. If you want something higher level then use CFNetwork (probably through the classes exported by Foundation like NSURLSession).

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

#116

Post by pram »

ryandrake wrote: post #113
josephcsible wrote: post #27

Earlier quoted context omitted.

It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.

It's the same thing they did with Metal. Portable OpenGL is now "legacy." Straight from the 90s Microsoft playbook.

OpenGL is legacy in general, its been on 4.6 for almost a decade.

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

#117

Post by nomel »

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.

I had a great Windows firewall like this about 20 years ago. It would pop up a dialog for every network request from an app. You could block or allow based on port or destination, or "block all". It was amazing, because as you say, it made it very obvious when an app was trying shady shit.

I would love to have that back, but I was never able to find a firewall so hostile to the user experience of the general population.

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

#118

Post by nomel »

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

> Seeing this getting downvoted is fucking wild.

If you consider the source of income of what's most likely a considerable portion of the HN community, I think this makes more sense. Apple is one of the only companies interested in preventing tracking, and it hurts, in the billions sort of way [1][2].

[1] https://www.forbes.com/sites/kateoflahertyuk/2022/10/08/appl...

[2] https://www.forbes.com/sites/timbajarin/2022/07/26/apples-do...

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

#119

Post by RulerOf »

lxgr wrote: post #99
cj wrote: post #98

Earlier quoted context omitted.

Interesting. I hadn’t considered it might be a security feature of his router!

In case you want to look into it further: My router actually allows adding exemptions to this policy on a per-hostname basis! Sometimes I wish it would allow wildcards, but honestly that's probably just another way for users to shoot themselves in the foot (e.g. by adding '*').

> Sometimes I wish it would allow wildcards

pfSense for example uses unbound, and while it doesn't have a switch for disabling rebind protection, it does allow injecting arbitrary unbound config, which can disable rebind protection for any depth of a DNS zone or IP space. E.g.:

    server:
    private-address: 192.168.0.1/24
    private-domain: plex.direct

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

#120

Post by adastra22 »

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…

Everything in the UNIX compatibility layer is low-level in macOS. Not necessarily "legacy" though.

But this is no different than saying that, for example, calling out platform-specific native OS APIs from Java is "low-level." Which it is, from the perspective of compile-once, run-anywhere Java applets. macOS is a NeXT-compatible non-UNIX API, and you are supposed to use the macOS frameworks for everything. Calling down to BSD or even mach is definitely not what Apple wants you to do.

Post reply on HN