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

141–150 of 215 posts

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

#141

Post by adastra22 »

raverbashing wrote: post #140
adastra22 wrote: post #120

Earlier quoted context omitted.

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

Curious about this Isn't the Mach kernel based on BSD? How much of getaddrinfo is in the kernel, how much of it is pure "libc"?

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.

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

#142

Post by jesprenj »

kccqzy wrote: post #130
OJFord wrote: post #109

I was confused at the Little Snitch mention, and then reading further it just seems like a LS bug, that it only works in certain cases. Well, seems this is the LS blog, so only confusion is why this is portrayed as a macOS bug? I'm not saying it's wrong, it's their domain not mine after all, it just doesn't seem to be justified in TFA?

If the OS allows the registration of a DNS proxy, and some calls bypass the proxy, it's squarely an OS bug.

Doesn't getaddrinfo respect /etc/resolv.conf? So LittleSnitch should install itself there if it wants to be used by getaddrinfo.

Besides, apps can always make direct lookups to a resolver of their choice, bypassing any resolver hints of the operating system.

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

#143

Post by messe »

adastra22 wrote: post #141
raverbashing wrote: post #140

Earlier quoted context omitted.

Curious about this Isn't the Mach kernel based on BSD? How much of getaddrinfo is in the kernel, how much of it is pure "libc"?

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)

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

#144

Post by jesse_faden »

gigatexal wrote: post #127

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 goes away when I'm connected on mobile data.

Now I'm guessing that it is bypassing the DNS profile and resolving it using my ISPs DNS or some other way.

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

#146

Post by pjmlp »

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…

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.

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

#147

Post by john_alan »

pjmlp wrote: post #146
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…

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

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

#148

Post by conradev »

simscitizen wrote: post #115
conradev wrote: post #54

Earlier quoted context omitted.

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

I actually found it linked from here, which seems current: https://developer.apple.com/support/ipv6/

It is not best practice to use `getaddrinfo` for DNS resolution, for sure. But it is best practice to use it before connecting to an IP address directly because that address may need to be translated.

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

#149

Post by Tepix »

matheusmoreira wrote: post #136
jonhohle wrote: post #124

Earlier quoted context omitted.

getaddrinfo is defined by POSIX and UNIX. Where the implementation is doesn’t matter. It’s portable, which is why it’s used. The slide deck referenced above talks about better implementations for various platforms, but they are all platform specific. So OP might not be completely accurate, but getaddrinfo is _the_ way to resolve names if you are writing portable POSIX and/or UNIX code.

Linux and the popular Linux distributions are not POSIX compliant to begin with. Only GNU tries to be, and even GNU adds on a ludicrous amount of extensions because the truth is POSIX isn't good enough.

Why are you nitpicking? Linux demonstrates a high degree of practical compatibility to run software written against POSIX standards.

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

#150

Post by Terretta »

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…

TL;DR:

Applications should not use getaddrinfo(). Because for the connect by name, the OS or app SDK can parallelize the entire multi-step lookup and connection process, not just step by step:

“Now, I’m not saying that all implementations of these APIs [Java, Apple Foundation, etc., doing connect by name] necessarily do the right thing today, but if applications are using these APIs, then the implementations can be improved over time.”

“The difference with getaddrinfo() and similar APIs is that they fundamentally can’t be improved over time. The API definition is that they return you a full list of addresses, so they have to wait until they have that full list to give you. There’s no way getaddrinfo can return you a partial list and then later give you some more.”

The deck's position on implementation of happy-eyeballs (which could sound dismissive here but is treated as "you had one job" important by the deck), is finding a way to avoid waiting 5 seconds for either side of IPv4 vs. IPv5 stack to timeout before finishing connection setup and serving the user a web page.

Post reply on HN