4 ms·

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 https://news.ycombinat

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

lilyball 6y ago
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.
- user3939382 6y ago
  Why are they ignoring /etc/hosts if this is good behavior?
  - jojobas 6y ago
    In their book a bit of malware might have modified /etc/hosts. It's for your own good!
  - judge2020 6y ago
    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
  - floatingatoll 6y ago
    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.
    - deleted 6y ago
      [deleted]
  - judge2020 6y ago
    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
    - user3939382 6y ago
      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.
      - lilyball 6y ago
        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.
        user3939382 6y ago
        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.
p1mrx 6y ago
The screenshot shows init-p01st.push.apple.com and ##-courier.push.apple.com, none of which have IPv6 AAAA records that I can see.
- user3939382 6y ago
  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.
  - random5634 6y ago
    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?
  - acdha 6y ago
    > 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.
oneplane 6y ago
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.
- joshspankit 6y ago
  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.
  - oneplane 6y ago
    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).
- s0cur10us 6y ago
  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.
  - oneplane 6y ago
    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?
oefrha 6y ago
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.

lilyball 6y ago

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.

user3939382 6y ago
Why are they ignoring /etc/hosts if this is good behavior?
- jojobas 6y ago
  In their book a bit of malware might have modified /etc/hosts. It's for your own good!
- judge2020 6y ago
  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
- floatingatoll 6y ago
  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.
  - deleted 6y ago
    [deleted]
- judge2020 6y ago
  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
  - user3939382 6y ago
    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.
    - lilyball 6y ago
      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.
      - user3939382 6y ago
        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.

p1mrx 6y ago

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

user3939382 6y ago
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.
- random5634 6y ago
  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?
- acdha 6y ago
  > 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.

oneplane 6y ago

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.

joshspankit 6y ago
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.
- oneplane 6y ago
  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).
s0cur10us 6y ago
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.
- oneplane 6y ago
  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?

oefrha 6y ago

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.