5 ms·

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 serv

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.

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.