Accessing Apple from Australia
Update (12:09 AM) There has been a suggestion that this is the result of DNS attack affecting some Apple domains (http://www.macnn.com/articles/14/03/12/fault.is.likely.due.to.hacker.attack.rather.than.apple.originated.issue/) which would have many of the same symptoms as being blackholed on the way to a legitimate location. The attackers were at least clever enough to make sure that the reverse address had something Apple related in it and at least in the case of the addresses I looked at addresses owned by Apple.
traceroute to apple.com (17.172.224.47), 64 hops max, 52 byte packets
1 10.0.0.250 (10.0.0.250) 23.993 ms 5.945 ms 4.707 ms
2 210.9.181.1 (210.9.181.1) 9.713 ms 2.879 ms 6.827 ms
3 ge-0-0-0-196.bdr01.mel01.vic.vocus.net.au (114.31.197.33) 4.971 ms 23.748 ms 2.593 ms
4 ge-0-1-0-3.cor01.mel07.vic.vocus.net.au (114.31.196.208) 183.191 ms 173.803 ms 170.721 ms
5 ten-0-1-0-0.cor03.syd03.nsw.vocus.net.au (114.31.196.162) 171.659 ms 173.828 ms 172.215 ms
6 ten-0-5-0-1.cor01.syd04.nsw.vocus.net.au (175.45.72.118) 170.216 ms
ten-0-1-0-3.cor01.syd04.nsw.vocus.net.au (175.45.72.225) 171.122 ms
ten-0-5-0-1.cor01.syd04.nsw.vocus.net.au (175.45.72.118) 173.822 ms
7 ten-0-0-0-1.cor02.sjc01.ca.vocus.net (114.31.199.36) 173.737 ms
ten-0-0-1-1.cor02.sjc01.ca.vocus.net (114.31.199.44) 170.294 ms
ten-0-0-0-1.cor02.sjc01.ca.vocus.net (114.31.199.36) 181.561 ms
8 en-0-2-0.bdr01.sjc01.ca.vocus.net (114.31.199.243) 170.566 ms 175.352 ms 176.096 ms
9 te7-5.ccr01.sjc05.atlas.cogentco.com (38.122.92.1) 194.310 ms 176.055 ms 210.084 ms
10 te0-2-0-4.ccr21.sjc01.atlas.cogentco.com (154.54.84.53) 170.461 ms
te0-2-0-4.ccr22.sjc01.atlas.cogentco.com (154.54.84.57) 170.633 ms
te0-2-0-4.ccr21.sjc01.atlas.cogentco.com (154.54.84.53) 174.234 ms
11 be2161.ccr22.lax01.atlas.cogentco.com (154.54.27.169) 202.876 ms
be2163.mpd22.lax01.atlas.cogentco.com (154.54.27.237) 185.685 ms
be2162.mpd21.lax01.atlas.cogentco.com (154.54.27.173) 184.856 ms
12 be2068.mpd22.iah01.atlas.cogentco.com (154.54.7.157) 219.232 ms
be2067.mpd21.iah01.atlas.cogentco.com (154.54.7.161) 218.409 ms
be2065.ccr21.iah01.atlas.cogentco.com (154.54.5.65) 225.180 ms
13 be2173.ccr22.atl01.atlas.cogentco.com (154.54.29.117) 236.383 ms
be2175.mpd22.atl01.atlas.cogentco.com (154.54.29.221) 238.380 ms
be2174.mpd21.atl01.atlas.cogentco.com (154.54.29.201) 418.829 ms
14 te3-1.ccr01.clt01.atlas.cogentco.com (154.54.6.174) 454.208 ms
te2-1.ccr01.clt01.atlas.cogentco.com (154.54.0.97) 508.215 ms
te3-1.ccr01.clt01.atlas.cogentco.com (154.54.6.174) 611.001 ms
15 38.104.168.146 (38.104.168.146) 240.891 ms 239.066 ms
38.104.168.182 (38.104.168.182) 333.731 ms
16 *
And the whois showed that the final router was owned by Cogent. So one of 2 things had happened either an incorrect advertisement of the route had been made pulling the routes through a filter or someone had determined that a lot of traffic was coming through their network and it was probably an abuse.
It seems to have partially cleared now ... though not before upsetting the update and now my iPad is throwing an Unknown error (3004) when I attempt a restore.
Looks like a long day ahead.
The access problem has been observed in 3 network locations in Australia.
Update (10:55 AM) - 3 restore attempts later and the iPad finally came to life. My guess is that accessing the authentication server was blocked by the network error during the earlier restore attempts. Of course the really paranoid would point out that this is what mass subversion of iOS devices using a rootkit to replace an update could look like ... fortunately the target addresses are owned by Apple (at least the ones I looked at).