Hacker News Reader

Comment by unethical_ban | Hacker News Reader

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?

View on HN

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.

> 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

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.

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.

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.

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.

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.

If you were writing a Java application, would you do your own DNS resolution, or would you make a new socket address object and give it a hostname and let the api resolve the hostname for you? If you don’t hand roll your own dns protocol lookups, how do you know the OS, or Java or your socket library aren’t intercepting and modifying request out from under you? Heck, even if you use getaddrinfo directly how do you know your libc implementation isn’t intercepting and modifying the lookups on you? If the threat model you’re coding for is “Apple is a hostile actor intercepting and modifying dns queries” then you really can’t trust their provided posix calls either.

> If you were writing a Java application, would you do your own DNS resolution,

Java isn't known to nanny the users of apps developed in it's language. It's never even tried IMO.

> If the threat model you’re coding for is “Apple is a hostile actor intercepting and modifying dns queries” then you really can’t trust their provided posix calls either.

Sure, but that isn't the threat model. I described the threat model above, which is closer to "I don't trust a company famous for trying to nanny not to try to nanny if using their preferred developer frameworks, while I kind of trust they won't for a legacy API they barely pay attention to".

> Java isn't known to nanny the users of apps developed in it's language. > It's never even tried IMO.

I think anyone who's run into java keystore / cert problems would beg to differ.

> Sure, but that isn't the threat model. I described the threat model above, > which is closer to "I don't trust a company famous for trying to nanny not to > try to nanny if using their preferred developer frameworks, while I kind of > trust they won't for a legacy API they barely pay attention to".

Sorry, this just makes no sense to me. You have a threat model that thinks Apple is a malicious actor and will interfere with the implementation of DNS resolution in higher level APIs because they "nanny" their users and developers. But you equally think they won't bother to do such nannying at a the lower levels because they "barely pay attention to [those legacy APIs].

But we're talking about the same apple that implemented SIP which locks out even root (and by extension sudo) from being able to make changes to "system" directories like `/bin`, and necessitated things like homebrew having to migrate their entire deployment hierarchy from `/usr/local/` to `/opt/homebrew/`. The same Apple who replaced init scripts in BSD with their own proprietary `launchd`. The same Apple who swapped `bash` for `zsh` to avoid GPL3 licensing stuff. The same Apple that last OS update changed what signals were sent when doing illegal memory access, breaking a mess of java/docker things in the process. This is the Apple you think would impose hidden DNS interception and replacement at the swift library level but wouldn't bother to either change libc too or point getaddrinfo() at their own internal interceptor.

You are of course free to have whatever threat model you like, but surely you can see why other people find it a little inconsistent?

> Sorry, this just makes no sense to me. You have a threat model that thinks Apple is a malicious actor and will interfere with the implementation of DNS resolution in higher level APIs because they "nanny" their users and developers. But you equally think they won't bother to do such nannying at a the lower levels because they "barely pay attention to [those legacy APIs].

I don't think this is a crazy position at all. Higher level frameworks often do things a particular way, often in a way that benefits the company pushing.

I'm pretty sure there are examples of Microsoft doing some slightly dodgy things via the .NET framework or similar but leaving the base win322 APIs untouched.

> but surely you can see why other people find it a little inconsistent?

Not really. I think people are dismissing it before really considering it because they think it's a moot point because the OS vendor could do anything, but I explained in other comments why I think that's flawed reasoning and not really relevant.

I appreciate your reply though, thank you.

I would feel far more concerned that an arbitrary application that decided to do its own DNS resolution would be doing so for nefarious reasons, or might mess up the process (such as not supporting encrypted DNS in this case).

If you genuinely cannot trust the OS vendor, you don't try to tinker around in user space but you stay off their platform. Personally, this is why I don't have any machines with a Microsoft OS, and why I don't have a Playstation.

The concern isn't that Apple controls the OS and so could do nefarious rootkit type stuff, but rather they may try to nanny through the framework they prefer and push for all apps for their platform to be developed in.

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.

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

Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way? As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults.

(And further, assuming arguendo that there was DNS meddling happening but somehow getaddrinfo() was exempt - now the user has one app that behaves differently to all their others, which is worse in every practical sense.)

> Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way?

Nothing, I already acknowledge they have the power to do rootkity things if they wanted to, but I don't consider that likely.

I do consider it likely they might do that kind of a thing at a framework level and try to push most developers to use it.

> As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults.

I responded to that as I'm responding here, by pointing out that isn't relevant to the threat model that I've described.

> now the user has one app that behaves differently to all their others, which is worse in every practical sense.

Not if that app actually gets the user to where they actually wanted to go.

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.

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

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

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

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

It is also legacy from Khronos point of view.

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.

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.

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

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.

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.

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.

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

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

> Sometimes I wish it would allow wildcards

pfSense for example uses unbound, and while it doesn't have a switch for disabling rebind protection, it does allow injecting arbitrary unbound config, which can disable rebind protection for any depth of a DNS zone or IP space. E.g.:

    server:
    private-address: 192.168.0.1/24
    private-domain: plex.direct

Most isp resolvers are shit and broken

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

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.

Reply on news.ycombinator.com