Why your iOS update may have refused to download

iPad keyboard dock

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 @
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62872
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 10, ADDITIONAL: 11
; EDNS: version: 0, flags:; udp: 4096


;appldnld.apple.com.            IN      A


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
a2047.gi3.akamai.net.   3       IN      A
a2047.gi3.akamai.net.   3       IN      A
a2047.gi3.akamai.net.   3       IN      A
a2047.gi3.akamai.net.   3       IN      A
a2047.gi3.akamai.net.   3       IN      A
a2047.gi3.akamai.net.   3       IN      A
a2047.gi3.akamai.net.   3       IN      A
a2047.gi3.akamai.net.   3       IN      A


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.


n0gi3.akamai.net.       11582   IN      A
n1gi3.akamai.net.       21294   IN      A
n2gi3.akamai.net.       12293   IN      A
n3gi3.akamai.net.       420     IN      A
n4gi3.akamai.net.       1577    IN      A
n5gi3.akamai.net.       34489   IN      A
n6gi3.akamai.net.       10686   IN      A
n7gi3.akamai.net.       20888   IN      A
n8gi3.akamai.net.       33387   IN      A
n9gi3.akamai.net.       13905   IN      A

;; Query time: 2 msec
;; 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.