Live data from Hacker News

Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

obdev.at

171–180 of 215 posts

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

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

Of course, Apple does not want their app to call `getaddrinfo()` directly, because it would interfere with their internal XDR/NDS/IPS mechanism.

I can’t blame them but I personally would still have my apps use them, even knowingly that it would be made off-limit to iOS/iPadOS apps … soon.

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

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

Of course, Apple does not want their app to call `getaddrinfo()` directly, because it would interfere with their internal XDR/NDS/IPS mechanism. I can’t blame them but I personally would still have my apps use them, even knowingly that it would be made off-limit to iOS/iPadOS apps … soon.

What's XDR/NDS/IPS?

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

#173
post #143

Earlier quoted context omitted.

No, mach is a microkernel, like L5. It was developed for the purpose of replacing the BSD kernel, by having a small amount of functionality in the kernel itself, and the rest of the BSD-compatibility layer implemented in user space. macOS' frameworks are then a layer on top of that.

IIRC most of the BSD compat was moved to kernel space for performance reasons (either just on macOS, or the version of Mach they built on top of)

The UNIX libcompat (a compatibility library for older UNIX functions) was integrated into Mac OS (specifically, macOS) rather than directly into Mach OS.

Here’s the breakdown:

• Mach OS refers to the Mach microkernel, which primarily focuses on low-level system functions such as task scheduling and memory management. It is not a full-fledged operating system, and thus, libraries like libcompat, which are higher-level UNIX compatibility libraries, would not be integrated directly into the Mach kernel itself. • Mac OS (particularly macOS, formerly OS X) is a complete operating system that includes the Mach microkernel, the BSD layer, and various other components. macOS has a strong Unix heritage, and libcompat is part of the broader Unix-like environment included in macOS to support legacy Unix APIs and applications.

Thus, libcompat was integrated into macOS (or its predecessor, NeXTSTEP) as part of its Unix compatibility layer, rather than into the Mach kernel directly

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

#174

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

Most isp resolvers are shit and broken

That’s why it is imperative (at least, for a homelab hobbyist) to host your own DNS servers in your own VSP.

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

#175
The battle of DNS resolving ownership rages on: who has the rights to set the DNS nameservers/resolver.

As a long-time DNS security researcher, the ultimate and final end means would be to mirror the root servers, but I assert, for now, popping in your own `resolv.conf` should suffice, … again, for now.

https://tailscale.com/blog/sisyphean-dns-client-linux

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

#176
post #151

Earlier quoted context omitted.

Regardless, even if they renew the certification, they aren't obliged to expose in the classical POSIX APIs more than what the certification requires in features, or happens to be optional, implementation defined. As anyone that has painfully tried to write POSIX portable code across big iron UNIX is aware of.

> Regardless, even if they renew the certification, they aren't obliged to expose in the classical POSIX APIs more than what the certification requires in features, or happens to be optional, implementation defined. getaddrinfo() is part of POSIX, so it would be necessary to expose it: * https://pubs.opengroup.org/onlinepubs/9699969599/functions/g... (2004) * https://pubs.opengroup.org/onlinepubs/9699919799/functions…

And it is exposed, the code still compiles if one uses it, it just doesn't get additional nice macOS networking features that aren't explicilty required for UNIX certification.

Where does it say DNS encryption is required?

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

#177
post #163

Earlier quoted context omitted.

It also means if you do it the 'Apple' way they might choose to intercept or modify responses. That seem in line with Apple's practices as a company even if they are not doing it yet. I feel anything they might do like that might be less likely to extend to what the article refers to as a legacy API.

But you are already on their OS, so they would always be able to do that. They make the kernel, the hardware and it's firmware, so it's a moot point and needless paranoia. Might as well use the API that gives a better user experience.

> so it's a moot point and needless paranoia.

No it's not. You are misunderstanding my point.

I'm not talking about Apple being able to patch the OS and control everything at that level - of course they can, but it seems unlikely.

I'm talking about a developer framework, a high level abstraction, where the method of resolving would be more likely to be intercepted - consider for example something like that on an iPhone with the justification being safety or 'for the children' or whatever.

That doesn't seem unlikely or improbably at all, and certainly not moot or any kind of paranoia.

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

#178
post #117
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.

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

Zonealarm?

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

#179
post #154

Earlier quoted context omitted.

Not at all actually, passing hostnames means they can fully handle happy eyeballs for you and all other performance optimizations that you can do if you resolve and connect in one call.

It also means if you do it the 'Apple' way they might choose to intercept or modify responses. That seem in line with Apple's practices as a company even if they are not doing it yet. I feel anything they might do like that might be less likely to extend to what the article refers to as a legacy API.

If you were writing a Java application, would you do your own DNS resolution, or would you make a new socket address object and give it a hostname and let the api resolve the hostname for you? If you don’t hand roll your own dns protocol lookups, how do you know the OS, or Java or your socket library aren’t intercepting and modifying request out from under you? Heck, even if you use getaddrinfo directly how do you know your libc implementation isn’t intercepting and modifying the lookups on you? If the threat model you’re coding for is “Apple is a hostile actor intercepting and modifying dns queries” then you really can’t trust their provided posix calls either.

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

#180
post #67

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

I can't reproduce this. Some people say it has to do with ESET: https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...

It's easily reproducible with a fresh macOS install. Yes, ESET has its own issue. But this is a problem in and of itself. https://imgur.com/a/Nr7Gk6c
Post reply on HN