[unethical_ban]

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?

[Terretta]

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]

> 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

[josephcsible]

It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.

[matheusmoreira]

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.

[tpmoney]

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.

[mzs]

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

[ruthmarx]

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

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]

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.

[threeseed]

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.

[virtue3]

no no, it's just "ours is better", "think different", and "it just works". /s

[masklinn]

It kinda is yea: https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf

[ryandrake]

It's the same thing they did with Metal. Portable OpenGL is now "legacy." Straight from the 90s Microsoft playbook.

[pram]

OpenGL is legacy in general, its been on 4.6 for almost a decade.

[pjmlp]

It is also legacy from Khronos point of view.

[kccqzy]

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]

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]

If you are using getaddrinfo directly, you likely wouldn't bother to implement Happy Eyeballs, for example.

[o11c]

And for almost all programs, that doesn't matter in $CURRENTYEAR.

[roywashere]

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]

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.

[troyvit]

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.

[jonhohle]

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.

[X-Istence]

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]

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]

Interesting. I hadn’t considered it might be a security feature of his router!

[lxgr]

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 '*').

[admax88qqq]

Most isp resolvers are shit and broken

[egberts1]

That’s why it is imperative (at least, for a homelab hobbyist) to host your own DNS servers in your own VSP.

[admax88qqq]

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.