Live data from Hacker News

Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

obdev.at

151–160 of 215 posts

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

#151
post #146

Earlier quoted context omitted.

For quite some versions that modern networking APIs on macOS using Objective-C frameworks, starting in 2018. See WWDC 2018's "Introducing Network.framework, A modern alternative to sockets". NeXTSTEP might have been a UNIX, and macOS derives from it, but the whole UNIX story has always been to bring UNIX software into the platform, not to make it easier to move elsewhere.

macOS is still certified POSIX UNIX EDIT: maybe not anymore, Sequoia isn't listed yet, https://www.opengroup.org/openbrand/register/xy.htm

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.

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

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

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?

The Apple deck linked elsewhere in this thread suggests the developer's goal generally isn't "DNS resolution", the dev's goal is usually establishing a connection to a host/server/endpoint to start doing something.

So, usually devs should use the Java or Apple or whatever higher level OS API gets you connected the fastest, and that API is free to implement the connection however most quickly gets to the point of able to return data to the user (app or end user).

The API that returns a list of addresses is stuck doing that, instead of being able to parallize the entire "get connected" data flow.

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

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

> getaddrinfo() is the way to resolve names on Linux Not at all. That's just a glibc function, it's got nothing to do with Linux. People just assume that glibc is how things are done in Linux user space but it doesn't have to be that way. For example, systemd came up with its own resolved mechanism which turned out to be much better than the glibc stuff. I will probably end up inventing my own at some point as well s…

You're probably aware of c-ares, if not then check it out unless you really want to write your own.

(As an administrator I'm getting a bit tired of working around the differing bugs and behaviour of different resolver implementations).

glibc also has an async getaddrinfo_a function for asynchronous name resolution, with completion notification.

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

#154
post #84

Earlier quoted context omitted.

That's what you use to create a utility like nslookup in swift, Apple does not want you to do any resolving yourself, just pass a hostname instead: https://developer.apple.com/documentation/network/nwendpoint...

> Apple does not want you to do any resolving yourself Which honestly sounds like a good reason to make sure you do do it yourself.

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.

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

#156

Earlier quoted context omitted.

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.

According to https://www.opengroup.org/openbrand/register/ macOS 15 is not certified.

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

#157

I wonder if this affects iOS, too

I would believe so. I have a custom DNS profile setup that redirects a few domains to a server I run. The server has custom SSL certs issued by a private CA. I the certificate installed on iOS as a trusted root certificate. Everytime I'm connected to my home WiFi I would randomly get `peer closed connection in SSL handshake (104: Connection reset by peer)`. I have absolutely no clue why it does this and this issue go…

Oh this is not good. I hope the vpn providers chime in, the MullVads and ExpressVPNs etc

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

#158
post #62
post #47

Earlier quoted context omitted.

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

At some point in my copious spare time, I plan on writing software to allowlist in my firewall outbound connections only to IPs resolved using my DNS servers.

How would that work? Do you only access a really small/known set of IPs? Or would you program the firewall to only allow connections to an arbitrary IP if it had seen a DNS query to your preferred servers go out and return that IP within a few seconds prior?

In the latter case, would you have to aggressively disable local DNS caching on devices to make the behavior work (is that even possible on some devices)? How would encrypted DNS fit into this scheme?

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

#159
post #154

Earlier quoted context omitted.

> Apple does not want you to do any resolving yourself Which honestly sounds like a good reason to make sure you do do it yourself.

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.
Post reply on HN