7 ms·

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

by kelnos 2y ago

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 the like to do the dirty work. I guess GAI is blocking, so presumably there's some other low-level non-blocking call?

unethical_ban 2y ago
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?
- threeseed 2y ago
  > This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures. https://github.com/apple/swift-async-dns-resolver https://github.com/apple/swift-async-dns-resolver
  - josephcsible 2y ago
    It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.
    - deleted 2y ago
      [deleted]
    - deleted 2y ago
      [deleted]
    - virtue3 2y ago
      no no, it's just "ours is better", "think different", and "it just works". /s
      - masklinn 2y ago
        It kinda is yea: https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf
    - tpmoney 2y ago
      As near as I can tell, Apple doesn't call it a legacy API. The article does, but the article wasn't written by nor does it appear to be quoting Apple.
    - threeseed 2y ago
      You actually think that a Swift developer, developing against Cocoa APIs, targeting Mac and iOS devices cares about a portable API. Because not sure if you know this but the entire software industry is built on high level libraries on top of largely portable code. For example this Swift library wraps c-ares a portable API.
    - kccqzy 2y ago
      Well but the portable API is too low-level and error prone. What is the last time you used getaddrinfo? How often do you actually need to use it? One can make a good technical argument based on the merit of the portable API without immediately resorting to the EEE argument.
      - o11c 2y ago
        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.
        kccqzy 2y ago
        If you are using getaddrinfo directly, you likely wouldn't bother to implement Happy Eyeballs, for example.
        o11c 2y ago
        And for almost all programs, that doesn't matter in $CURRENTYEAR.
    - mzs 2y ago
      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/host/init(_:)?language=swift https://developer.apple.com/documentation/network/nwendpoint...
      - ruthmarx 2y ago
        > 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.
        EraYaN 2y ago
        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.
        ruthmarx 2y ago
        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.
        EraYaN 2y ago
        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.
        ruthmarx 2y ago
        > so it's a moot point and needless paranoia. No it's not. You are misunderstanding my point. I'm not talking about Apple being able to patch the OS and control everything at that level - of course they can, but it seems unlikely. I'm talking about a developer framework, a high level abstraction, where the method of resolving would be more likely to be intercepted - consider for example something like that on an iPhone with the justification being safety or 'for the children' or whatever. That doesn't seem unlikely or improbably at all, and certainly not moot or any kind of paranoia.
    - matheusmoreira 2y ago
      It's not necessarily EEE. Maybe it's just that the old wheel sucks. They want a better wheel and so they reinvented it, hopefully better this time. The corporations making proprietary software are not the only ones who have that attitude. I've resolved to make all my free software Linux-exclusive so that I can use Linux to the fullest. The Linux kernel is packed full of exclusive non-portable features that very few people take advantage of because they're obsessed with portability, POSIX compliance or whatever. I think that's a waste. Portable software is usually sucky lowest common denominator software. We should not limit ourselves to whatever glibc offers.
    - ryandrake 2y ago
      It's the same thing they did with Metal. Portable OpenGL is now "legacy." Straight from the 90s Microsoft playbook.
      - pram 2y ago
        OpenGL is legacy in general, its been on 4.6 for almost a decade.
      - pjmlp 2y ago
        It is also legacy from Khronos point of view.
- roywashere 2y ago
  Yes, this! I even wonder how else you would do this. By the way I worked with many IoT devices that do not use your dhcp dns but just hardcode quad 8 or similar
  - cj 2y ago
    We recently had a developer join our team and he got stuck setting up his dev environment. We use a .dev domain as a localhost alias, and turns out his ISP’s DNS wouldn’t resolve 127.0.0.1 (or whatever it is) for the .dev domain. Changing his resolver at the network level to 1.1.1.1 fixed it. I imagine there are lots of difficult support tickets for app devs, and at a certain point they just hardcode the DNS to remove one variable from the equation when debugging bug reports.
    - X-Istence 2y ago
      Not resolving 127.0.0.1 or RFC1918 addresses or even ULA for IPv6 is done to avoid DNS rebinding attacks. For most end users that is probably the correct move.
      - lxgr 2y ago
        My home router even seems to inspect any UDP/53 traffic and redact any responses containing local/private A entries, so not even switching to a public resolver bypasses the protection. I agree that it’s usually the right behavior.
        cj 2y ago
        Interesting. I hadn’t considered it might be a security feature of his router!
        lxgr 2y ago
        In case you want to look into it further: My router actually allows adding exemptions to this policy on a per-hostname basis! Sometimes I wish it would allow wildcards, but honestly that's probably just another way for users to shoot themselves in the foot (e.g. by adding '*').
- Terretta 2y ago
  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.
mannyv 2y ago
Yes, things are drastically different on MacOS. There's like a whole nother level of APIs ip there /s
krackers 2y ago
>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 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]
- conradev 2y ago
  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/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-DontLinkElementID_4 https://developer.apple.com/library/archive/documentation/Ne...
  - krackers 2y ago
    I'm actually surprised they suggest getaddrinfo() directly over the async CF wrapper.
  - simscitizen 2y ago
    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).
    - conradev 2y ago
      I actually found it linked from here, which seems current: https://developer.apple.com/support/ipv6/ 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.
jmull 2y ago
> It's a little weird to me that getaddrinfo() is considered a "low-level legacy API" 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.)
pushupentry1219 2y ago
> Maybe things are drastically different on macOS, but getaddrinfo() is the way to resolve names on Linux and I suspect the *BSDs. 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.
ransom1538 2y ago
Wait until you try to get the mac address on an iphone.
ajross 2y ago
Yeah, this report seems a little spun. The essence is basically that the encrypted DNS needs to go through the proxy, and there's resolver code elsewhere in the OS that doesn't use the proxy. It's a bug, sure. It could plausibly have interesting exploits, though none are shown. But it's not a very interesting bug.
matheusmoreira 2y ago
> 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 since I'm working on freestanding software targeting Linux.
- jonhohle 2y ago
  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.
  - matheusmoreira 2y ago
    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.
    - Tepix 2y ago
      Why are you nitpicking? Linux demonstrates a high degree of practical compatibility to run software written against POSIX standards.
      - matheusmoreira 2y ago
        Not nitpicking at all. I just don't like how people see Linux as a "POSIX implementation". It's much more than that. Practical compatibility is not compliance, the manuals document many subtle differences and incompatibilities. The practicality of it mostly comes from glibc which everyone uses and which does strive to be compliant. Even then it's a hit and miss, the so called "Linuxisms" crop up in the most unexpected of places. The executable path that people write in the shebang lines of their shell scripts, for example. It's gotten to the point some BSDs have started emulating Linux system calls instead of porting software. Even Windows did this once upon a time. My point is glibc is not even guaranteed to exist on the system. POSIX is not at all mandatory on Linux. The POSIX interfaces are just one of the ways to interface with the kernel. It's also possible to bypass all the POSIX stuff and interface with it directly. Linux is the only operating system to offer this ability via the stable kernel-userspace binary interface. It's even defined at the instruction set level which makes it programming language agnostic. On Linux you actually can trash all that POSIX stuff and reinvent it all in Rust if you want.
adastra22 2y ago
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 down to BSD or even mach is definitely not what Apple wants you to do.
- raverbashing 2y ago
  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"?
  - adastra22 2y ago
    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.
    - messe 2y ago
      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)
      - egberts1 2y ago
        The UNIX libcompat (a compatibility library for older UNIX functions) was integrated into Mac OS (specifically, macOS) rather than directly into Mach OS. Here’s the breakdown: • Mach OS refers to the Mach microkernel, which primarily focuses on low-level system functions such as task scheduling and memory management. It is not a full-fledged operating system, and thus, libraries like libcompat, which are higher-level UNIX compatibility libraries, would not be integrated directly into the Mach kernel itself. • Mac OS (particularly macOS, formerly OS X) is a complete operating system that includes the Mach microkernel, the BSD layer, and various other components. macOS has a strong Unix heritage, and libcompat is part of the broader Unix-like environment included in macOS to support legacy Unix APIs and applications. Thus, libcompat was integrated into macOS (or its predecessor, NeXTSTEP) as part of its Unix compatibility layer, rather than into the Mach kernel directly
brynet 2y ago
> getaddrinfo() is the way to resolve names on Linux and I suspect the *BSDs. At least on OpenBSD, all classical/standard DNS functions (getaddrinfo/gethostbyname/...) are wrappers around OpenBSD's libc asr implementation, written by Eric Faurot. https://man.openbsd.org/man3/asr_run.3 https://man.openbsd.org/man3/asr_run.3 https://github.com/openbsd/src/tree/master/lib/libc/asr https://github.com/openbsd/src/tree/master/lib/libc/asr
inopinatus 2y ago
The correct term is "heirloom".
pjmlp 2y ago
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.
- john_alan 2y ago
  macOS is still certified POSIX UNIX EDIT: maybe not anymore, Sequoia isn't listed yet, https://www.opengroup.org/openbrand/register/xy.htm https://www.opengroup.org/openbrand/register/xy.htm
  - pjmlp 2y ago
    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.
    - throw0101a 2y ago
      > 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/getaddrinfo.html https://pubs.opengroup.org/onlinepubs/9699969599/functions/g... (2004) * https://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/g... (2017) * https://pubs.opengroup.org/onlinepubs/9799919799/functions/getaddrinfo.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/g... (2024)
      - pjmlp 2y ago
        And it is exposed, the code still compiles if one uses it, it just doesn't get additional nice macOS networking features that aren't explicilty required for UNIX certification. Where does it say DNS encryption is required?
egberts1 2y ago
Of course, Apple does not want their app to call `getaddrinfo()` directly, because it would interfere with their internal XDR/NDS/IPS mechanism. 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.
- eptcyka 2y ago
  What's XDR/NDS/IPS?
  - egberts1 2y ago
    https://en.wikipedia.org/wiki/Intrusion_detection_system https://en.wikipedia.org/wiki/Intrusion_detection_system
    - eptcyka 2y ago
      No mention of apple, xdr or nds.
      - efreak 2y ago
        https://en.wikipedia.org/wiki/Extended_detection_and_response https://en.wikipedia.org/wiki/Extended_detection_and_respons... Not sure what nds stands for, but I assume it's something related to network intrusion, possibly the I in NIDS (network intrusion detection system) is missing
      - deleted 2y ago
        [deleted]

by kelnos 2y ago

unethical_ban 2y ago

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?

threeseed 2y ago
> This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures. https://github.com/apple/swift-async-dns-resolver https://github.com/apple/swift-async-dns-resolver
- josephcsible 2y ago
  It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - virtue3 2y ago
    no no, it's just "ours is better", "think different", and "it just works". /s
    - masklinn 2y ago
      It kinda is yea: https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf
  - tpmoney 2y ago
    As near as I can tell, Apple doesn't call it a legacy API. The article does, but the article wasn't written by nor does it appear to be quoting Apple.
  - threeseed 2y ago
    You actually think that a Swift developer, developing against Cocoa APIs, targeting Mac and iOS devices cares about a portable API. Because not sure if you know this but the entire software industry is built on high level libraries on top of largely portable code. For example this Swift library wraps c-ares a portable API.
  - kccqzy 2y ago
    Well but the portable API is too low-level and error prone. What is the last time you used getaddrinfo? How often do you actually need to use it? One can make a good technical argument based on the merit of the portable API without immediately resorting to the EEE argument.
    - o11c 2y ago
      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.
      - kccqzy 2y ago
        If you are using getaddrinfo directly, you likely wouldn't bother to implement Happy Eyeballs, for example.
        o11c 2y ago
        And for almost all programs, that doesn't matter in $CURRENTYEAR.
  - mzs 2y ago
    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/host/init(_:)?language=swift https://developer.apple.com/documentation/network/nwendpoint...
    - ruthmarx 2y ago
      > 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.
      - EraYaN 2y ago
        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.
        ruthmarx 2y ago
        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.
        EraYaN 2y ago
        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.
        ruthmarx 2y ago
        > so it's a moot point and needless paranoia. No it's not. You are misunderstanding my point. I'm not talking about Apple being able to patch the OS and control everything at that level - of course they can, but it seems unlikely. I'm talking about a developer framework, a high level abstraction, where the method of resolving would be more likely to be intercepted - consider for example something like that on an iPhone with the justification being safety or 'for the children' or whatever. That doesn't seem unlikely or improbably at all, and certainly not moot or any kind of paranoia.
  - matheusmoreira 2y ago
    It's not necessarily EEE. Maybe it's just that the old wheel sucks. They want a better wheel and so they reinvented it, hopefully better this time. The corporations making proprietary software are not the only ones who have that attitude. I've resolved to make all my free software Linux-exclusive so that I can use Linux to the fullest. The Linux kernel is packed full of exclusive non-portable features that very few people take advantage of because they're obsessed with portability, POSIX compliance or whatever. I think that's a waste. Portable software is usually sucky lowest common denominator software. We should not limit ourselves to whatever glibc offers.
  - ryandrake 2y ago
    It's the same thing they did with Metal. Portable OpenGL is now "legacy." Straight from the 90s Microsoft playbook.
    - pram 2y ago
      OpenGL is legacy in general, its been on 4.6 for almost a decade.
    - pjmlp 2y ago
      It is also legacy from Khronos point of view.
roywashere 2y ago
Yes, this! I even wonder how else you would do this. By the way I worked with many IoT devices that do not use your dhcp dns but just hardcode quad 8 or similar
- cj 2y ago
  We recently had a developer join our team and he got stuck setting up his dev environment. We use a .dev domain as a localhost alias, and turns out his ISP’s DNS wouldn’t resolve 127.0.0.1 (or whatever it is) for the .dev domain. Changing his resolver at the network level to 1.1.1.1 fixed it. I imagine there are lots of difficult support tickets for app devs, and at a certain point they just hardcode the DNS to remove one variable from the equation when debugging bug reports.
  - X-Istence 2y ago
    Not resolving 127.0.0.1 or RFC1918 addresses or even ULA for IPv6 is done to avoid DNS rebinding attacks. For most end users that is probably the correct move.
    - lxgr 2y ago
      My home router even seems to inspect any UDP/53 traffic and redact any responses containing local/private A entries, so not even switching to a public resolver bypasses the protection. I agree that it’s usually the right behavior.
      - cj 2y ago
        Interesting. I hadn’t considered it might be a security feature of his router!
        lxgr 2y ago
        In case you want to look into it further: My router actually allows adding exemptions to this policy on a per-hostname basis! Sometimes I wish it would allow wildcards, but honestly that's probably just another way for users to shoot themselves in the foot (e.g. by adding '*').
Terretta 2y ago
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.

mannyv 2y ago

Yes, things are drastically different on MacOS. There's like a whole nother level of APIs ip there /s

krackers 2y ago

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

conradev 2y ago
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/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-DontLinkElementID_4 https://developer.apple.com/library/archive/documentation/Ne...
- krackers 2y ago
  I'm actually surprised they suggest getaddrinfo() directly over the async CF wrapper.
- simscitizen 2y ago
  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).
  - conradev 2y ago
    I actually found it linked from here, which seems current: https://developer.apple.com/support/ipv6/ 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.

jmull 2y ago

> It's a little weird to me that getaddrinfo() is considered a "low-level legacy API" 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.)

pushupentry1219 2y ago

> Maybe things are drastically different on macOS, but getaddrinfo() is the way to resolve names on Linux and I suspect the *BSDs. 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.

ransom1538 2y ago

Wait until you try to get the mac address on an iphone.

ajross 2y ago

Yeah, this report seems a little spun. The essence is basically that the encrypted DNS needs to go through the proxy, and there's resolver code elsewhere in the OS that doesn't use the proxy. It's a bug, sure. It could plausibly have interesting exploits, though none are shown. But it's not a very interesting bug.

matheusmoreira 2y ago

> 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 since I'm working on freestanding software targeting Linux.

jonhohle 2y ago
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.
- matheusmoreira 2y ago
  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.
  - Tepix 2y ago
    Why are you nitpicking? Linux demonstrates a high degree of practical compatibility to run software written against POSIX standards.
    - matheusmoreira 2y ago
      Not nitpicking at all. I just don't like how people see Linux as a "POSIX implementation". It's much more than that. Practical compatibility is not compliance, the manuals document many subtle differences and incompatibilities. The practicality of it mostly comes from glibc which everyone uses and which does strive to be compliant. Even then it's a hit and miss, the so called "Linuxisms" crop up in the most unexpected of places. The executable path that people write in the shebang lines of their shell scripts, for example. It's gotten to the point some BSDs have started emulating Linux system calls instead of porting software. Even Windows did this once upon a time. My point is glibc is not even guaranteed to exist on the system. POSIX is not at all mandatory on Linux. The POSIX interfaces are just one of the ways to interface with the kernel. It's also possible to bypass all the POSIX stuff and interface with it directly. Linux is the only operating system to offer this ability via the stable kernel-userspace binary interface. It's even defined at the instruction set level which makes it programming language agnostic. On Linux you actually can trash all that POSIX stuff and reinvent it all in Rust if you want.

adastra22 2y ago

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 down to BSD or even mach is definitely not what Apple wants you to do.

raverbashing 2y ago
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"?
- adastra22 2y ago
  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.
  - messe 2y ago
    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)
    - egberts1 2y ago
      The UNIX libcompat (a compatibility library for older UNIX functions) was integrated into Mac OS (specifically, macOS) rather than directly into Mach OS. Here’s the breakdown: • Mach OS refers to the Mach microkernel, which primarily focuses on low-level system functions such as task scheduling and memory management. It is not a full-fledged operating system, and thus, libraries like libcompat, which are higher-level UNIX compatibility libraries, would not be integrated directly into the Mach kernel itself. • Mac OS (particularly macOS, formerly OS X) is a complete operating system that includes the Mach microkernel, the BSD layer, and various other components. macOS has a strong Unix heritage, and libcompat is part of the broader Unix-like environment included in macOS to support legacy Unix APIs and applications. Thus, libcompat was integrated into macOS (or its predecessor, NeXTSTEP) as part of its Unix compatibility layer, rather than into the Mach kernel directly

brynet 2y ago

> getaddrinfo() is the way to resolve names on Linux and I suspect the *BSDs. At least on OpenBSD, all classical/standard DNS functions (getaddrinfo/gethostbyname/...) are wrappers around OpenBSD's libc asr implementation, written by Eric Faurot. https://man.openbsd.org/man3/asr_run.3 https://man.openbsd.org/man3/asr_run.3 https://github.com/openbsd/src/tree/master/lib/libc/asr https://github.com/openbsd/src/tree/master/lib/libc/asr

inopinatus 2y ago

The correct term is "heirloom".

pjmlp 2y ago

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.

john_alan 2y ago
macOS is still certified POSIX UNIX EDIT: maybe not anymore, Sequoia isn't listed yet, https://www.opengroup.org/openbrand/register/xy.htm https://www.opengroup.org/openbrand/register/xy.htm
- pjmlp 2y ago
  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.
  - throw0101a 2y ago
    > 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/getaddrinfo.html https://pubs.opengroup.org/onlinepubs/9699969599/functions/g... (2004) * https://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/g... (2017) * https://pubs.opengroup.org/onlinepubs/9799919799/functions/getaddrinfo.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/g... (2024)
    - pjmlp 2y ago
      And it is exposed, the code still compiles if one uses it, it just doesn't get additional nice macOS networking features that aren't explicilty required for UNIX certification. Where does it say DNS encryption is required?

egberts1 2y ago

Of course, Apple does not want their app to call `getaddrinfo()` directly, because it would interfere with their internal XDR/NDS/IPS mechanism. 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.

eptcyka 2y ago
What's XDR/NDS/IPS?
- egberts1 2y ago
  https://en.wikipedia.org/wiki/Intrusion_detection_system https://en.wikipedia.org/wiki/Intrusion_detection_system
  - eptcyka 2y ago
    No mention of apple, xdr or nds.
    - efreak 2y ago
      https://en.wikipedia.org/wiki/Extended_detection_and_response https://en.wikipedia.org/wiki/Extended_detection_and_respons... Not sure what nds stands for, but I assume it's something related to network intrusion, possibly the I in NIDS (network intrusion detection system) is missing
    - deleted 2y ago
      [deleted]