101–110 of 215 posts
Earlier 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?
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.
> Update 2024-09-17, 7:10 p.m. > 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).
> Update 2024-09-17, 7:10 p.m. > 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).
It's ridiculous us developers still have to jump through hoops to save around older versions of the OS for testing. There is 0 technical reason why Apple can't let us downgrade.
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…
Earlier quoted context omitted.
getaddrinfo isn't its predecessors, there's nothing error-prone about it. The only thing that's nontrivial is falling back if the first server is unresponsive, and even there the obvious calling code is fine for almost all apps.
If you are using getaddrinfo directly, you likely wouldn't bother to implement Happy Eyeballs, for example.
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.
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…
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?
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…
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.