Why your iOS update may have refused to download
If, like me, you were left scratching your head last week when your iPad refused to download the latest update to iOS, there is a very complicated explanation.
This bewildering problem coincided with the release of iOS 5.1. I downloaded the patch on the iPhone 4S without any problem using the office Wi-Fi connection, but attempts to upgrade my iPad at home were met with an “unable to check for update” error message.
Naturally, I griped on Twitter and went online to discover dozens of other people having the same problem, with Apple support forums suggesting that changing your DNS servers to those of OpenDNS or Google’s DNS service would fix the problem. Alas, diverting my router to OpenDNS did nothing for me, and in the end I resorted to downloading the update via iTunes, but it seems many people did indeed succeed once they’d changed their DNS servers.
So what was going on? Were certain ISPs blocking access to Apple’s update servers for some strange reason? The answer is no — at least, not deliberately.
The eagle-eyed PR representative for my ISP, Zen Internet, saw my plaintive cry for help on Twitter, and set her technical team on to finding an explanation. After much digging around, Zen located the problem.
When users attempted to contact Apple’s update server via Zen’s DNS servers, the following packet of data was returned:
; <<>> DiG 9.7.3 <<>> +ignore +bufsize=4000 appldnld.apple.com @22.214.171.124
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62872
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 10, ADDITIONAL: 11
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;appldnld.apple.com. IN A
;; ANSWER SECTION:
appldnld.apple.com. 2435 IN CNAME
appldnld.apple.com.akadns.net. 169 IN CNAME
appldnld2.apple.com.edgesuite.net. 10378 IN CNAME
appldnld2.apple.com.edgesuite.net.globalredir.akadns.net. 169 IN CNAME
a2047.gi3.akamai.net. 3 IN A 126.96.36.199
a2047.gi3.akamai.net. 3 IN A 188.8.131.52
a2047.gi3.akamai.net. 3 IN A 184.108.40.206
a2047.gi3.akamai.net. 3 IN A 220.127.116.11
a2047.gi3.akamai.net. 3 IN A 18.104.22.168
a2047.gi3.akamai.net. 3 IN A 22.214.171.124
a2047.gi3.akamai.net. 3 IN A 126.96.36.199
a2047.gi3.akamai.net. 3 IN A 188.8.131.52
a2047.gi3.akamai.net. 3 IN A 184.108.40.206
;; AUTHORITY SECTION:
gi3.akamai.net. 11037 IN NS n7gi3.akamai.net.
gi3.akamai.net. 11037 IN NS n9gi3.akamai.net.
gi3.akamai.net. 11037 IN NS n2gi3.akamai.net.
gi3.akamai.net. 11037 IN NS n5gi3.akamai.net.
gi3.akamai.net. 11037 IN NS n8gi3.akamai.net.
gi3.akamai.net. 11037 IN NS n4gi3.akamai.net.
gi3.akamai.net. 11037 IN NS n6gi3.akamai.net.
gi3.akamai.net. 11037 IN NS n1gi3.akamai.net.
gi3.akamai.net. 11037 IN NS n3gi3.akamai.net.
gi3.akamai.net. 11037 IN NS n0gi3.akamai.net.
;; ADDITIONAL SECTION:
n0gi3.akamai.net. 11582 IN A 220.127.116.11
n1gi3.akamai.net. 21294 IN A 18.104.22.168
n2gi3.akamai.net. 12293 IN A 22.214.171.124
n3gi3.akamai.net. 420 IN A 126.96.36.199
n4gi3.akamai.net. 1577 IN A 188.8.131.52
n5gi3.akamai.net. 34489 IN A 184.108.40.206
n6gi3.akamai.net. 10686 IN A 220.127.116.11
n7gi3.akamai.net. 20888 IN A 18.104.22.168
n8gi3.akamai.net. 33387 IN A 22.214.171.124
n9gi3.akamai.net. 13905 IN A 126.96.36.199
;; Query time: 2 msec
;; SERVER: 188.8.131.52#53(184.108.40.206)
;; WHEN: Tue Mar 13 14:52:27 2012
;; MSG SIZE rcvd: 729
The key to solving the problem, according to Zen’s senior engineering design consultant Jerry Nichols, was found in the very last line of that packet. “The problem was the message size — a lot of broadband routers are set to a limit of 512 bytes,” Nichols told me. As you can see, the Apple packet was 729 bytes, causing many people’s routers to simply reject the package.
Why was Apple’s packet so large? It seems there are an extra nine server records returned under the Authority and Additional sections. Normally this extraneous data is ignored, but it can be useful for diagnostics, which is why Zen’s DNS servers were set to retain that data. Google DNS, on the other hand, deals with millions of requests every second, so it strips out such extraneous data to save bandwidth, returning a packet size that routers would accept and allowing users to reach the Apple update server.
Zen has now adjusted its DNS servers to only seek the minimal amount of data required to resolve the address correctly, which should avoid any further problems. If you’re having the same issue with your ISP, perhaps you should point its technical support team in the direction of this blog. Or find an ISP that’s as technically switched on and responsive as Zen.