Hacker News Reader

Comment by user3939382 | Hacker News Reader

So does this mean we won’t be seeing the behavior I just documented the other day on here?

https://news.ycombinator.com/item?id=25746007

In sum, they’re intentionally circumventing DNS, /etc/hosts, and even IPv4 blackholing by attempting to send their phone-home packets through IPv6. Then if you block that as well your computer constantly freezes.

View on HN

You make it sound so sinister, but yes of course Apple will use IPv6 if that’s the only (or best) route. That’s a good thing.

Where does “constantly freezes” come from? You didn’t mention that in your linked post. And if your computer “constantly freezes” with Apple blackholed, why wouldn’t it also be constantly freezing when your network connection doesn’t reach the internet? I’m pretty sure they use an apple.com URL for their reachability test, so your blackhole should be blocking that too.

Why are they ignoring /etc/hosts if this is good behavior?

In their book a bit of malware might have modified /etc/hosts.

It's for your own good!

Are you writing

  ::/0 domain.example

as well? It might using either AAAA DNS lookups or the equivalent of `getent hosts` which pulls v6 records first, which are only overridden if there is a v6 override for the hostname.

  $ getent hosts cloudflare.com && getent ahosts cloudflare.com
  2606:4700::6810:85e5 cloudflare.com
  104.16.133.229  STREAM cloudflare.com
  $ echo "0.0.0.0 cloudflare.com" | sudo tee -a /etc/hosts
  $ getent hosts cloudflare.com && getent ahosts cloudflare.com
  2606:4700::6810:85e5 cloudflare.com
  0.0.0.0         STREAM cloudflare.com

Why are you using /etc/hosts to modify the behavior of the Apple resolver system? That’s not how macOS directory services work, and Apple only appears to offers it as a legacy backwards-compat stub with no guarantee of support or effectiveness for modern anything. It’s no surprise that it’s not an effective solution for you.

Are you also writing

  :: domain.example

Because the difference is gethostbynamev2 (the most likely function being used, or I suppose the Apple equivalent) looks up a ipv6 hostname before it looks up a ipv4 hostname, which means a "0.0.0.0 domain.example" entry won't override the result of ipv6 lookups.

  $ echo "0.0.0.0 cloudflare.com" | sudo tee -a /etc/hosts
  $ getent hosts cloudflare.com && getent ahosts cloudflare.com
  2606:4700::6810:85e5 cloudflare.com
  0.0.0.0         STREAM cloudflare.com

I disabled IPv6 altogether, and Apple’s processes are still finding a way to resolve their real IPs after my DNS and /etc/hosts resolved their domains to 0.0.0.0.

DNS should be enough, I shouldn’t have to black hole Apple’s entire /8 to stop macOS from phoning home when I’m not using the computer and no apps are running.

I suspect the number of macOS machines on networks with misconfigured DNS is far higher than the number of macOS machines whose admins want to prevent them from talking to Apple. So I’m glad they’re going to great lengths to preserve their ability to communicate with Apple even under adverse network conditions.

I appreciate giving people the benefit of the doubt, but this feels overly charitable to me. I doubt they’re worried about accidentally misconfigured /etc/hosts files.

Much more likely is that they were aware of outbound firewalls like Little Snitch and want to evade user attempts to block their software, as discussed in the main article here.

That's an odd one. If my Mac is offline it works just fine. Perhaps your filtering/firewalling isn't complete so it gets partial connections and then times out on the rest? If you do that in large quantities, any OS will start to show trouble.

Timing out packets instead of denying them could certainly be an issue (I run across this a lot with internet being down while the router and internal DNS is still up).

But your claim that “any OS will start to show trouble” is not how it’s supposed to work, nor how it used to work before 24/7 connections, nor even how it should work assuming you’re ok with phone-home daemons.

Of course it's not how it's supposed to work, but that is how it tends to work ;-)

An OS in general has a few layers with caches and monitors and resolvers etc, and if you block a few of them, in a partial manner, they tend to get in to an extreme version of the bus bunching problem. Windows still does that with their 'network identification' where sometimes something goes wrong in the probing process and the connection hangs on "identifying" indefinitely. And that's just a silly "optional" service (which should default to the public profile and only change from there instead of defaulting to no connection at all).

I had that freeze issue and the DROP vs REJECT idea came to my mind too. As far as I remember, it was REJECT everywhere. So no.

Come to think of it, I did hear about this from someone a while ago who was using some sort of public WiFi HotSpot (bad idea in general) which had a broken redirect page and in turn didn't open up the firewall and gets you that 'partial' connection that causes all sorts of problems. Was on both macOS (10.12 I think) and Linux (some Ubuntu version) at that time.

Seems to be an interesting problem: if it works fine with no connection and fine with a complete connection but not 'in between' (which is the best way I can describe it so far) you'd think it must be some common library or component in a network stack that causes this. macOS has some reachability system that might be in play here, perhaps if it flags the network as 'reachable' but then gets REJECT'ed it goes bad? Or the other way around: marks network as 'unreachable' but traffic flows anyway?

Flaky network stacks aren't rare. I've experienced plenty of consumer-facing operating systems that will freeze on boot for 10 to 60 seconds if the network interface is up but DHCP is unreachable.

init-p01st.push.apple.com and *-courier.push.apple.com requests come from apsd(8), the Apple Push Notification service daemon. It's attempting to get push notifications, rather than some sort of phone home telemetry thing.

Now, I do have an issue with apsd specifically on Big Sur, but "sending phone home packets" isn't it.

The screenshot shows init-p01st.push.apple.com and ##-courier.push.apple.com, none of which have IPv6 AAAA records that I can see.

If you proxy macOS connections overnight with no apps running and the computer idle you get about 15 hosts from 7-8 Apple processes phoning home, a handful of them resort last to IPv6 after ignoring your DNS and /etc/hosts

The screenshot is an example of traffic to Apple unsolicited by the user.

Does Apple allow DNS hijacking / local override of their domains? Some security sensitive software will resolve using known good resolvers for things that shouldn't be redirected locally (ie, google may use 8.8.8.8 in some of their VPN products rather than rely on comcast or your malware infected local source?

> The screenshot is an example of traffic to Apple unsolicited by the user.

Do you expect a dialog box every time it resolves a hostname? Users want features like Messages which depend on the push notifications service shown, not the details of how it’s implemented.

This is also Exhibit A for where the idea for things like firewall allow lists come from: there are always people who will block something they don’t recognize and then complain about “bugs” after the system does exactly what they requested.

Reply on news.ycombinator.com