I'm thinking about blocking my many iOS machines from downloading software updates from Apple at expensive times of day. This would mean blocking outside the hours 0200-0559 local time/BST (not GMT unfortunately). I'd like to block updates of both iOS itself and updates of apps too. If possible, I'd like to avoid frustrating manual downloads of apps though.
I read somewhere that blocking access to the IP addresses that map to FQDN mesu.apple.com will do the trick because then devices won't know that new updates are available. From what I read, there is another domain name that maps to (distinct) servers from which actual downloads are delivered.
Has anyone else had a go at this?
Does anyone know if the mechanisms for checking for iOS releases and for new apps’ releases are different?
A block on detecting new releases would be an ideal technique as users would still be able to manually download additional apps if needed quickly, if I get this right.
A DNS lookup mesu.apple.com gives two IPv4 results. I'm wondering how stable these results are over time. Guesswork on the basis of a PTR query and traceroute suggest, unsurprisingly, that the servers are geographically local, optimised for me, so my chosen IP addresses to block would not be general and there's always the possibility that the A record assignements could change over time or Apple could change things at a higher level anyway, the latter not being something I can do anything about obviously. However, I don't know how to get my firewall, a Firebrick, to do a DNS lookup and I have to use rules based on multiple fixed IP addresses.
I wondered if there's any way I could at least be alerted if a DNS record changes. A quick google of the subject came up with a big load of results. Does anyone have any recommendations? (Iirc the lookup in this particular case will involve more than one step: a CNAME, and then an A record with a couple of results. So I'd have to monitor the individual records in the process for changes or compare the result entire lookup process as a whole for change.)
Actually, I just noticed that after multiple levels of cname lookup there are two A record results, and the values are rotating in time, presumably to provide load balancing. I suppose I could simply guess and match against something like x.y.z.0/24, or maybe rather tighter than that, although god only knows what other unfortunate effects there might be from false matches against innocent servers inside the range.
see also http://forum.kitz.co.uk/index.php/topic,19091.0.html
Actually another idea might be to pervert the DNS, giving a fake result back to devices on the LAN that use the Firebrick as their DNS server (relay / proxy). This would be more reliable, unless some devices bypass the server suggestion given out by DHCP, such as using hard-coded DNS servers, or don't use DNS at all, which seems very unlikely.
However it would be a bit of a nuisance as it would inconvenience me at my own machine if I wish to investigate what’s going on.