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