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 the like to do the dirty work. I guess GAI is blocking, 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's can internally handle the implementation of happy-eyeballs.
Edit: You can read https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf for their thoughts on why they don't like the getaddrinfo() model [there are speaker notes at the bottom of each slide]
https://developer.apple.com/library/archive/documentation/Ne...
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.
I don't think it is considered legacy. The blog post gets that wrong.
(Whether it's "low-level" or not just depends on your perspective.)
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 since I'm working on freestanding software targeting Linux.
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.
(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.
At least on OpenBSD, all classical/standard DNS functions (getaddrinfo/gethostbyname/...) are wrappers around OpenBSD's libc asr implementation, written by Eric Faurot.
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.
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.
Seems to be badly phrased and meant something else, since macOS is certified to be UNIX - https://www.opengroup.org/openbrand/register/ - contrary to Linux which is not UNIX-certified.
HN posted about this at least once - https://news.ycombinator.com/item?id=29984016
Isn't the Mach kernel based on BSD?
How much of getaddrinfo is in the kernel, how much of it is pure "libc"?
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.
EDIT: maybe not anymore, Sequoia isn't listed yet, https://www.opengroup.org/openbrand/register/xy.htm
* Host file
* Configured DNS server
* App-specific DNS server if it exists
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.
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.
/s
New title from source: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
> After further investigation, we found that this bug has already existed at least since macOS 14.5 Sonoma (maybe even earlier, but we currently don’t have access to an older 14.x system for testing).
You can do a fresh install of an older macOS version whenever you like (you need to enable that option in the rescue system tho).
You can also run older macOS in a VM (the hypervisor framework keeps getting new features that make guest macOS more fully supported).
Name an OS (ok maybe NixOS) that allows you to do clean downgrades out of the box. Also wonder what's gonna happen to your data in e.g. Postgres if you blindly downgrade.
FYI, it looks like Firefox fixed this.
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.
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, your shit is malware and you should reconsider who you write code for.
I also wish people would post the FB numbers and the details of their report when they say they've reported things like this.
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?
Maybe part of this old bug (that I thought was fixed)
I use a stub listener on localhost:53 for local requests and then forward them via UDP QUIC (TLS 0-RTT) requests to Cloudflare (1.1.1.1) with caching for most requests. Fast and reasonably secure.
Isn't this an inherent risk when attempting to do network stuff in userspace? You're at a very high level so hoping that lower level things comply seems risky if DNS encryption is critical to your use case.
this is not "bypass encryption" this is "uses a range of ABI/API bindings in code which don't expose well into a single control point"
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.
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.
I also still haven't figured out how to get SSID-based switching to work, does it even?
TBH I’m too lazy to dig in and find out. Has anybody else run into this issue?
If disabling the firewall (for testing) solves this problem, this is likely your issue.
In other words, it would be unencrypted to the pihole but encrypted when going out to the internet.
Does Little Snitch do things differently?
man 5 resolver
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.
It won't, it was specifically a bug in Little Snitch (which doesn't currently run on iOS, I believe.)
"The problem discussed here turned out to be specific to Little Snitch 6.1 and not a general issue in macOS. It has already been fixed in Little Snitch 6.1.1."
Not really.