Comment by unethical_ban 3 days 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
> This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures.
It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.
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.
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...
> 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.
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.
It kinda is yea: https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf
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.
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
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.
Wayyyy back in 1995 or '96 I was working for a non-profit called "Next Generation Magazine" and our goal was to have young people write content for web sites to get their names out there. Back then it was all local ISPs, so we went to our ISP and asked for ngm.org and were stoked when we got it! We built out the site (Thanks to Building Killer Websites of course) and it looked awesome!
Only problem was that nobody in my family out of state could see it. It took awhile to realize realize that we never bought that domain. Our local ISP just added it to their DNS records, and since we all hooked into them we thought we were live across the 'net.
That’s incredible!
I remember one of the first times I used the Internet and opened my local radio station’s website from several states away. It was incredible to me that it worked and I also wondered why anyone across the country would care. The early internet was amazing.
Totally, but most IoT customers are not homelab hobbyists, so I think its defensible for IoT vendors to just hard code known good DNS in their devices instead of relying on broken ISP resolvers.
Related story, there was a period of time where my ISP's resolver that would replace hostnames with no DNS record with their own ad filled garbage page.
So you mistype google.com to foofle.com or something and instead of getting "host not found" you get... ads.
Disgusting behaviour IMO.
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.