Solving the App Store’s NSURLErrorDomain Error
All I really wanted to do was check the size of the iTunes 10.7 update for the TidBITS Watchlist item that I was editing, but the App Store app wasn’t cooperating. (For those who haven’t run into this in OS X 10.8 Mountain Lion yet, choosing Software Update from the Apple menu no longer runs a separate Software Update application; instead, App Store launches and shows the Updates screen.) Instead of giving me the iTunes update, or even a sensible error message, the App Store app displayed the thoroughly inscrutable message “The operation couldn’t be completed. (NSURLErrorDomain error -1100.)” As far as I can tell from Apple’s developer documentation, this basically means that some requested file doesn’t exist.
After moaning about Apple’s uncharacteristically poor error message on Twitter, I got a note from Dennis Wurster, a friend and Mac consultant in Rochester, NY, saying that he’d solved the problem by switching his DNS settings to use Google’s public DNS servers (8.8.8.8 and 8.8.4.4). I’ve been using OpenDNS’s servers (208.67.222.222 and 208.67.220.220) for some time now with no problems (for a reason why, see “OpenDNS
Blocks Flashback and Other Threats,” 16 May 2012), but when I changed the order of my DNS servers in the Network preference pane (select your current network adapter, click Advanced, then click DNS) to put Google’s public DNS servers at the top, the App Store app was able to find and download the update with no problem. To avoid pointing the finger of blame too specifically, the problem was not related to using OpenDNS servers, since others reported experiencing it with other DNS servers as well.
Other people have had success with this trick as well, and Kevin Bush reported back to me on Twitter that when he switched back to his previous DNS servers after the App Store app found the iTunes 10.7 update, it could still see it (perhaps due to caching) but couldn’t download it. In the comments, Mike Polinske also reported that he had success with flushing the DNS cache manually using this Terminal command:
sudo killall -HUP mDNSResponder
In the end, I’m still quite uncertain as to how DNS is related to this problem, but I hope that switching DNS servers or flushing the DNS cache resolves it for anyone else experiencing it.
In my case, I saw the update in Software Update and was able to download and install it, following which I got the message. Freakier!
I had this error too, tried this change & it worked. Probably a flush DNS problem. Thanks for the help.
I may have an answer. OpenDNS can have issues with content-distribution networks (CDNs) that rely on cues from an IP address requesting a DNS lookup to provide a "nearby" (in terms of Internet hops) content server.
I've seen this with Apple when I use OpenDNS and try to download something from the developer site or other places. It often crawls. If I switch DNS servers to Comcast's, it speeds up.
Google uses slightly different cues, and it seems that it might be better telling a CDN where the user is. I'm surprised to see an actual error, but this does sound similar.
There's a proposal in the words to update DNS servers (and only major ones would have to adopt the patch) so that a public DNS provider could give a little information about the source of a DNS request to help nudge the CDN to offer a server that's correctly close enough.
Whatever the cause of this App Store error, it's not limited to OpenDNS. I experienced it with a computer yesterday on a university network and using the university's DNS servers. The university uses Infoblox to manage DNS.
Slightly off-topic but related to app store updates... Anyone know why they don't show the size of the update, as they do in iTunes with iOS apps? Or if there is a setting I can change? Or just complain to Apple?
Thanks for asking David. I was literally just asking myself the same question. Anyone know?
I don't think the App Store app shows the size before you download, but if you have automatic downloads turned off, I think you can see a progress bar that includes the size after you click the Update button. All guesswork at the moment, since automatic downloads was turned on for all my Macs, so I won't know for sure until a new update arrives.
The App Store progress bar said the iTunes 10.7 update on my otherwise fully updated OS X 10.8.1 system was 163.3MB. If you download it from the web site, it's 157.33MB. The previous downloadable, iTunes 10.6.3, is bigger, 170.27MB, which makes sense since 10.7 is the first Intel-only version of iTunes.
I'm using OpenDNS and had the error last night, but it has since resolved, at least for me. I downloaded the iTunes update with no trouble tonight.
I did not change DNS servers.
I flushed the DNS cache after seeing the suggestion on the Apple Discussion forum and that worked. In Terminal, enter the following:
sudo killall -HUP mDNSResponder
Here is the link https://discussions.apple.com/thread/4289718?start=0&tstart=0
Fascinating - that would indicate more of a local problem that would be in Apple's purview rather than anything related to which servers were in use. Switching servers would very likely cause the DNS cache to be flushed as well.
The answer is definitely that OpenDNS has a bug, and it may well be precisely in the Flashback blocking done by OpenDNS. That error code indicates a missing file *ON AN HTTP SERVER* (i.e. a "404" HTTP reply) and that would be what you'd expect from using a DNS server that tells you lies for your own good about what it deems to be bad domains. If OpenDNS has misidentified the Apple update machines as carrying bad stuff (maybe because they *DO* serve out files with malware patterns) they will give you bogus addresses for their names. If they are pointing the "bad" names at machines with empty web servers on them, you get a fast 404 to nearly any request. Anything using Core Foundation Networking will turn that into a -1100.
This is an demo of the risk of "white lie" DNS as a tool for protecting people from bad stuff.
Bill, that's a little strident. OpenDNS is an optional service that people choose to use and can stop using with a tiny change.
Seems a little unlikely that this is an OpenDNS bug, since others have reported the problem who aren't using OpenDNS. It may be a bug in DNS software that is used by multiple DNS servers, but that's a different issue.
I was experiencing the same problem using one of Earthlink's opt-out server for primary DNS (207.69.188.172). I was able to solve the problem by promoting my secondary DNS server (Google DNS) to primary.
But I had what sounds like the same problem with my Mom's iPad (it couldn't see the App Store) and solved it by having her artificially set the date to several years in the future, try to connect to the App Store, then set the date back to the real date and time. After that, everything worked fine. I'm wondering if there was a certificate issue, and playing with the date threw out the cached certificate, or something.
Could be! I've seen that fix for iOS device errors with the App Store app, where you might not even be able to mess with DNS. In this situation, the Mac App Store itself seemed available; just not updates.
A technical friend commented in email:
You want this Terminal command instead:
sudo dscacheutil -flushcache
mDNSResponder doesn’t control the regular DNS cache (unless something changed recently).