Apple ignoring standards again.
> UPDATE: Spoke too soon… The problem discussed here turned out to be specific to Little Snitch 6.1 and not a general issue in macOS.
Not really.
Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
161–170 of 215 posts
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#162This is why I firewall egress port 53 at the router level.
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#163Earlier 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.
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.
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#164Earlier quoted context omitted.
Good thing you can still see the domain over the network if you control the network.
You can’t control anything if they do DNS over HTTPS to a hardcoded IP they control and cert pin so you can’t MITM the connection, can you?
If the pinned cert is stored on some kind of ROM chip you could probably rewrite it to replace it with your own cert.
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#165Earlier quoted context omitted.
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.
The /etc/resolv.conf system is woefully inadequate. It doesn't have a concept of per-interface customization so you can't customize according to the currently active network interface. It doesn't distinguish between DNS configuration delivered by the network administrator (which can and should be changed remotely) versus set by the computer administrator. It doesn't work very well with VPNs where a specific DNS server is used for resolving addresses on that VPN.
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#166>UPDATE: Spoke too soon… The problem discussed here turned out to be specific to Little Snitch 6.1 and not a general issue in macOS. It will be fixed in an update of Little Snitch later today.
Dang can we get an update to the title to reflect this?
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#167Earlier quoted context omitted.
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 adopti…
I often find this is the case with Apple on a technical level.
For instance, their recent Spatial (stereographic) Video features uses a format that has basically zero current support outside of Apple—which is in fact just standard MV-HEVC [0] (with some extra optional metadata [1]), which is just the H.265 evolution of the standard H.264 MVC that 3D Blu-rays have used for a long time. (AFAIK no 4K 3D Blu-rays have been released, presumably due to space constraints, explaining the lack of usage of MV-HEVC outside Apple).
In piracy world, most re-encoded 3D movies just use objectively inferior composited 2D formats like half-side-by-side or over/under. And without diving in you’d just assume Apple was using some bespoke format to be evil, when in fact they are popularizing what should be the canonical, standardized format for 3D video.
[0] http://hevc.info/mvhevc [1] https://developer.apple.com/av-foundation/HEVC-Stereo-Video-...
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#168Earlier quoted context omitted.
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.
> 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/g... (2017)
* https://pubs.opengroup.org/onlinepubs/9799919799/functions/g... (2024)
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#169Earlier 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.
Your comment above was that it is a glibc function, which is true, but it’s there for reason. It’s also a libc, musl, uClibc, and Windows Sockets 2 function: because it’s defined in POSIX 1.1 and extended in RFC 3493.
I have no opinion on whether it’s good enough (it seems like not if every platform has a connect-by-name implementation), just that calling it a glibc function overly simplifies it’s origin.
It’s also false to say only GNU tries to be POSIX compliant. There are 8 commercial UNIXes that meet some POSIX standard, another 8 that are discontinued (at least one of which was a Linux distro), and dozens that are mostly compatible. POSIX doesn’t care if that compatibility comes from the kernel or user space libraries.
POSIX isn’t good enough at what? Maybe you don’t understand what it’s goal is/was. POSIX exists for portability. It’s a minimal set of functions developers can target to get things done on any UNIX. Any OS will always have something beyond POSIX to differentiate it.
Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
#170Earlier 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.
> Linux and the popular Linux distributions are not POSIX compliant to begin with.
While not (entirely) wrong, not entirely correct either.
Good luck trying to compile and run any kind of software without providing getaddrinfo(), socket(), connect(), etc to userland:
* https://pubs.opengroup.org/onlinepubs/9699969599/functions/g...