Alarming number of DNS requests made by iOS devices | Hacker News Reader

Alarming number of DNS requests made by iOS devices

stan.sh

67 pointsstanlarroque62 comments

I have been logging, redirecting and blocking these queries for these domains and more for years.

It is one of our biggest complaints about the "new" Apple.

There is no option for the user to disable the nonstop phoning home. iOS is a BSD-like OS configured so that the user does not fully control it (e.g. can't stop someone else's software from incessantly trying to phone home). The user cannot fully configure it (e.g., can't access HOSTS file). Only Apple can (they get root and they do not even own the device). Important settings are placed off limits to the owners of these devices. This is no fun.

Turn on an iOS device and it will keep trying to connect to Apple servers; it will not stop. An incredible tracking device if those servers keep logs, irrespective of Apple's reasoning. Not to mention lots of unnecessary network chatter on the home network.

Clarification: After many years of desensitization to this practice since the first iPhone, it is neither "a secret" nor "scandalous", but it is still disappointing. Moreover, I am not advocating any other mobile OS simply by making a comment about iOS. In fact, none of the "smartphones" being sold today are satisfactory to me as portable computers when compared with the control I get using an open source OS with i386, amd64 or even a development board.

I want to mention that I think it's incredibly disingenuous to edit your comment to argue against my reply without mentioning that you've edited what I was arguing against. It's even more so when you use the exact same wording I did, making it look like I'm arguing something that was explicitly stated in your post, when it wasn't there at the time I wrote my reply.

I am seriously disappointed in this level of discourse. If you want anyone to take you seriously, you'll stop pulling shit like that in the future.

Shame on you.

I would be a lot more sympathetic if your reply had been something other than

> Don't act like you're scandalized about discovering the big secret that Apple won't let you fully control your iPhone in 2017.

I'm not sure why you seem to have a personal vendetta against me, unless you're an alt of feelin_googley. If you want to argue, I think we can keep it to the one chain we already have going, yeah?

Does your device behave correctly when you block these domains? If so, what is the impact on your service and battery life?

I really feel a dissonance between Apple's marketing position with privacy and the behavior of their devices in the background.

Is there really a dissonance? iOS lets you keep everything as local as possible if you want, and lets you limit the exposure of personal information.

As opposed to "we are open Android" but everything that most people define as Android includes closed source Google Play Services and proprietary drivers?

The comment you are responding to explicitly says no alternatives are good and disclaimed any idea that they were telling people to use something different. They shouldn't have had to make that disclaimer, but apparently it didn't even work.

This part of the comment did not exist when I replied....

Clarification: After many years of desensitization to this practice since the first iPhone, it is neither "a secret" nor "scandalous", but it is still disappointing. Moreover, I am not advocating any other mobile OS simply by making a comment about iOS. In fact, none of the "smartphones" being sold today are satisfactory to me as portable computers when compared with the control I get using an open source OS with i386, amd64 or even a development board.

Depending on when scarface replied, that last paragraph did not exist in the original post.

>iOS is a BSD-like OS configured so that the user does not fully control it

Oh come on. You act like this is some malicious or unexpected new behavior when this is how Apple has behaved for at least 15 years now. And if the BSD guys didn't want their software used in that fashion, they'd change their license. But since BSD wrote their own license that allows for that, they explicitly approve of it.

Don't act like you're scandalized about discovering the big secret that Apple won't let you fully control your iPhone in 2017.

> You act like this is some malicious or unexpected new behavior

No, I'm pretty GP "acts like"

> After many years of desensitization to this practice since the first iPhone, it is neither "a secret" nor "scandalous"

I've never really understood the absurd (but common!) argument that a repugnant state of affairs isn't worth discussion if it isn't new. Usually, the heckler even agrees with the person they're heckling! What's the goal? Sabotage of a cause one agrees with merely to redeem hipster / cynic points? I don't get it.

It's disappointing that GP felt the need to preemptively address this possibility in their post, but it's downright silly that parent didn't even let this fact stop them. So it goes.

I think it's fair to note that they edited that part in after I wrote my comment using that exact same wording, but failed to mention they edited it. It's not that their wording didn't stop me from replying, its that their wording did not exist when I replied.

It's a scummy argument tactic, which you've proven is highly effective.

A fair complaint, but you didn't address my main argument -- that novelty shouldn't be a precondition for discussing repugnant situations. Diversion is also a scummy argument tactic.

Seriously? Diversion? You just spent 100 words ripping me apart for a completely valid argument that you misunderstood, and you have the gall to say I'm only pointing that out as a diversion. Seriously. Take a look at yourself right now.

This was their original comment without their subsequent edits:

>I have been logging, redirecting and blocking these queries for these domains and more for years.

>It is one of our biggest complaints about the "new" Apple. There is no option for the user to disable the nonstop phoning home. iOS is a BSD-like OS configured so that the user does not fully control it. The user cannot fully configure it. This is no fun.

>Turn on an iOS device and it will keep trying to connect to Apple servers; it will not stop. An incredible tracking device if those servers keep logs.

It's a far whinier post, with the biggest complaint being that the BSD license allows companies to lock their software down, as intended. Not every piece of software needs to be fully controllable by the end user. I wouldn't call it "repugnant".

How do you know when the parent poster knew what? Must all Apple users know the entire history of Apple device DNS usage? Where is the universally known documentation on such usage?

I'd expect somebody commenting about "the 'new' Apple" to have awareness of Apple's historical activity, yes.

I'm not talking about DNS usage because neither were they. They were talking about being able to fully control their iOS device, which has never been the case, even dating back to the original iPod.

There is pretty universal documentation on that called "every sentence ever uttered about iOS since ever".

UPDATE: I updated my article with a more recent graph with more devices connected.

Here is a quick CSV export of all the concerned hosts (subdomain + domain) I could pick from my database.

https://stan.sh/images/ios_domains.csv

I really want the story behind pancake.g.aaplimg.com

Some quick explanations of non-obvious ones:

mesu, su: software update

pancake: looks like home sharing? https://stackoverflow.com/questions/26900625/what-is-pancake...

phobos, mzstatic: App/iTunes store, possibly also Apple Music

apptrailers: App Store app demo videos?

streamingaudio: Apple Music?

iphonesubmissions, radarsubmissions: crash report upload

guzzoni: Siri

appldwnld: firmware downloads

gs: firmware signature generator/verifier

albert: device activation

ckdatabase, ckdevice: CloudKit, like iCloud 2.0

keyvalueservice: old iCloud sync service, still used with text shortcuts sync

fmf: Find My Friends

fmip: Find My iPhone

All in all just looks normal, there's a lot of features in iOS/macOS/iTunes etc etc and they all have their own respective hostnames, possibly many for old school random-hostname-based load balancing, etc. Seems pretty normal that your users would be downloading apps (or the phone downloading updates automatically), playing Apple Music, updating iOS, etc. Spammy, but not that big a deal. I'd imagine rather similar from Android by filtering to Google, Samsung, etc hosts.

Yes it’s a cloud connected device, it is going to connect to the cloud. I don’t see why you are surprised.

If you think there is an issue, instead of breathlessly declaring you’ve discovered a disturbing pattern in a system you couldn’t possibly have an informed perspective on, the correct way to handle it is to file a radar at https://bugreport.apple.com/ then come back here tell us your radar number so we can dupe it and add any of our own data that might help with the (perceived, in this case, I would say) issue.

Yes, iOS does talk a lot to the Apple servers, and apple makes heavy use of Akamai for CDN purposes.

If you set your iOS device to auto-update overnight, that will typically happen between 3am and 5am. They even tell you that when they set the schedule.

I disabled all that, and background app refresh as well.

I am getting a huge database of these logs because of my users. Maybe someone can help me investigate because there is definitely something going on.

Here is a preview: https://stan.sh/images/log-example.png

"something" going on? like, the manufacturer of a device who provides cloud services with that device is speaking to their servers to provide services that the customer wants? Very alarming.

I understand iCloud, iTunes, and all other apple services need to communicate with their servers. My point is to question why do they need more than 1000 hosts for their endpoints? It only look suspicious in my eyes.

https://stan.sh/images/ios_domains.csv

1) Every service most likely has many, many different servers providing it. These may have different hostnames. Particularly consider that Apple uses a lot of cloud services.

2) All the services you list in fact consist of many smaller services. iTunes alone is a storefront, a CDN, a payment processing service, a DRM system, a syndication service, an account management service, a media library synchronisation service, a streaming media service, and so on. iCloud is a blanket name for a large collection of big services which themselves may consist of many smaller services.

3) That isn’t even the full set of services.

In light of these considerations, 1000 hostnames should not be unexpected. That might even be a surprisingly small figure.

Why is it suspicious? I don't see your reasoning here. Having a diverse range of DNS names requested doesn't seem to me to be an indicator of suspiciousness.

On earlier releases of iOS that had a public jailbreak released, I spent quite some time using HttPeek (https://github.com/Yonsm/HttPeek) to examine what various OS processes were sending, and found nothing untoward.

I'd be surprised if this had changed for the worse in more recent iOS releases.

One area where Apple uses a large amount of domain names on purpose is for their captive portal detection. Supposedly they do this on purpose so that captive portals can't try to hard-code a list of domains in order to white-list/fool it.

Device: Am I on a captive portal? Nonce.

Apple server: No. Same Nonce. Cryptographic signature.

If different response: Captive portal. If no response: No internet.

Oops, this doesn't actually work, because the captive portal can just let that one request through unmodified...

What benefit would a captive portal derive from hiding from Apple's captive portal detector?

iOS offers a slideover view that gets dismissed once absence of captive portal is detected. That way you can’t redirect people forcibly to your website after auth is done in a way that persists.

But if you force people to use a browser rather than auto disappearing modal view, the bounce rate is much lower once you force them to visit your website after captive portal login.

Why not?

I've developed some very large globe-spanning systems that are probably a single-digit % complexity as the Apple ecosystem and we touch hundreds of endpoints. Doesn't seem suspicious to me at all.

In your logs why don’t you also log whether each device is connected to power and what preferences each user has set on a per app basis for push notifications, background data fetch, background downloads (distinct from background data fetch), as well as their do not disturb settings and timeframe, whether they are on a cell network or wifi, whether the wifi is exposing a networked backed by a cell network, the current battery level at each time, whether the device is changing location, whether the user is moving the device, whether the screen is locked, whether any app is in the foreground, whether any currently installed apps have code that gets invoked when geographic regions change, whether they have any code that is invoked when specific locations are visited, whether they have code that gets invoked when non-specific locations are arrived at or departed from, whether the user has recently changed networks, whether the user has recently plugged or unplugged the power, etc., etc., etc...

Don’t have all this data? Then maybe don’t jump to premature conclusions about what your network activity is telling you.

Try to temporarily log out of iCloud and iTunes Store and disable push notifications. I think that could reduce a lot of the traffic. And then gradually start turning things on one by one.

Perhaps it's the recent iOS update? Right now iOS 11 is being rolled out, and it defaults to auto update overnight.

What exactly makes this "alarming"? I could understand "large" or maybe even "unexpected", but if this is background noise, I'm not sure "alarming" really fits here unless we're sure this is bad behavior.

Since you're blocking some DNS requests, do you think a portion of the usage might be retries? If one DNS request could turn into querying all the addresses in your list, I could see an amplification attack happening, and then that happening also on a retry. Look for patterns in querying the individual names?

I do not block these requests. However I am pretty sure Apple does some DNS tunneling.

Also, some iOS specific requests happen when there is no other DNS activity at all.

> However I am pretty sure Apple does some DNS tunneling.

That seems very reasonable. It would be better than hardcoding IP addresses and safer than straight DNS for management things. Maybe their implementation of that doesn't have a very long TTL?

Are you sure it's not just a bunch of app store updates and an iCloud backup? That's what I'd expect my phone to be doing at 4am anyway.

I also have a DNS logger and I found that iOS makes a lot of requests to time-ios.apple.com. That one isn't really alarming, though.

I'm still amazed that computers are so terrible at telling reliable time without connecting to a network constantly. I've seen computers with a fully-functional CMOS battery lose 5 minutes a month without a network connection. Mind blowing.

That is surprising, so surprising that I have to assume the computer in question was running some kind of misbehaving ntpd that was skewing the clock.

A good quality quartz crystal is accurate to about 15 seconds a month. Even the cheap ones can manage 30 seconds a month.

My car loses about 3 minutes per month, and it has no ability to query NTP. Oddly enough my SUV gains about a minute per month.

It turns out that if you really want a device that can keep accurate time over a long period you must pay a significant amount of money. You would need a temperature compensated crystal (TCXO) or ovenized crystal oscillator (OCXO). Both of these would cost tens to hundreds of dollars, which is orders of magnitude more than hardware makers are willing to spend. Not to mention these kinds of accurate oscillators tend to be power hungry.

But that is missing the main point of the network time checks. Even if computers were perfect at telling time you still need to check network time for security reasons, especially if local users can change the device time. There are crypto attacks that rely on changing the time, and checking that the time matches another somewhat reliable source helps make those attacks harder to pull off.

For a mobile phone it might make sense to check more often as they tend to either move timezones more often, or be powered off and then back on again.

Why would it be surprising? Manufacturers optimize for cost. The clock in your computer is the cheapest one they can find.

Knowing why and how this happens should be a basic course in computer science classes.

I would say its place is more in a computer engineering or an "applied computer science" discipline. Similarly, a chemistry student doesn't especially need to learn about how to plan a safe and cost-effective end industrial synthesis process, which would fall squarely in the domain of chemical engineering.

Is is if your you want your alarms to sound on time.

Hmm. Can’t it just rely on the mobile network? I suppose Apple trust their own time servers more.

Some mobile networks do a decent job of providing the time, some do a poor job, and some don't provide time at all (saw this when I was overseas). I would accept the time from the mobile network as a starting point, but prefer to get it from IP networks I trust, or from global positioning.

Perhaps not really that big a deal, but the first consequence I can think of is draining battery...

Well the author sort of neglected to state whether the device was charging at the time, which makes a difference. No doubt it wasn’t always charging but it would be fair to clarify when it was. The OS has some activities like checking for updates that it is more likely to do if tethered to power.

Also some of the activity can be related to measures that actually save power. For example, before attempting to do a heavy download of data provided by apps that implement background data downloading, it makes sense to first check the quality of the network connection.

I’d suggest everyone just chill and realize there can be good reasons for things, not just bad reasons. And consider the possibility that Apple is not stupid when it comes to power management.

What exactly is 'alarming' about a cloud device trying to connect to its cloud services? DNS/UDP is the cheapest way of communicating for the device, and, if the DNS servers are not mad and the RR timers are set correctly, also for the name server.

That animated banner at the top of https://databuster.net is a perfect example of what not to do on a website

You must be seeing something different than I am. I don't see anything animated on that page, with no ad or content blockers running.

Is there something in particular that's wrong with it? It seemed fine to me.

I run a pi-hole instance at home and observe the same thing. Most DNS requests come from my iOS devices.

Reply on news.ycombinator.com