Works fine with ISP DNS servers. When using openDNS the update is able to fetch the file list, but gets stuck on downloading files (not downloading even one byte).

Have you checked your firewall permissions?

Can you tell the exact URL that's being requested/failing?

when your ISP's local dns servers make the request, akamai sees the requests from your ISP's side of the internet. they give your ISP's dns servers a response that is close (in network topography) to those servers.

in other words, your ISP in Israel will ask Akamai for an IP and Akamai will give a result that is in Israel or close to Israel.

when OpenDNS makes the request to akamai, it made from our servers (London, NYC, Washington DC) and akamai will return an IP that is close to those locations. these locations may give much poorer performance that the Israeli mirror that Akamai would have returned had your ISP's server made the request.

as we expand into other locations (Israel being on the list of possibilities), the Akamai servers will give answers that are closer to those locations. OpenDNS also can open a discussion with Akamai on a method to pass the original client's IP to their servers (via DNS or other means) so Akamai can return an IP to us that is closer to the original requester.

Other nationwide providers have this same problem. pretend AOL (as an example, i don't know the specifics of their configuration - this is just an example) has DNS servers in San Jose and Washington DC. an AOL user in St. Louis looks up an Akamai address, Akamai will return a server that is close to San Jose or DC, because those coastal servers are where the Akamai server saw the request from. Akamai might have a mirror in St. Louis, but Akamai has no way of knowing the original request came from STL.

As OpenDNS adds more and more locations, the responses we give will have a higher likelihood of returning an Akamai response that reflects your actual presence. the Akamai servers that you were pointed at are in Washington DC, which may give you the poor performance you experienced. this is despite the fact that Akamai has mirrors much closer to you.

I was being blocked from AVG updates through March 15, but by the 17th, I was getting updates. Not sure if that means they updated in the areas I needed it, but its working for me now in Southern California.

The geo-location issue shouldn't cause failure, just a slightly slower download.

I would like to add to this. I have been using OpenDNS from New Zealand for the past several weeks, with the view to migrating my customers onto this service.

Within the 10 days or so random websites have just stopped working from my offices with IE/Firefox completely timing out.

I have spent a lot of time diagnosing this and after looking over many packet dumps today, I suddenly came to the realization that it was always an Akamai redirect for a graphic or some other content (css etc) that was causing going extremely slowly or not at all and was causing the browser to time out.

Of course I suddenly clicked that the problem was Akamai/OpenDNS and the geo-location issue, switching my DNS Servers to be non-forwarding instantly solved the problem as I got back different IP Addresses for the service I was trying to use.

Specifically I could not get www.trendmicro.com to work at all, microsoft.com was sporadic news.com was half loading with style sheets missing many other sites simply not working ... because I had also chnaged ISP in the mix this was a nightmare to diagnose :-)

> www.trendmicro.com.
Server: resolver1.opendns.com
Address: 208.67.222.222

Non-authoritative answer:
Name: a151.d.akamai.net
Addresses: 128.241.220.72, 128.241.220.73
Aliases: www.trendmicro.com, trendmicro.georedirector.akadns.net
trendmicro.com.edgesuite.net

> www.trendmicro.com
Server: dns1.clear.net.nz
Address: 203.97.33.1

Non-authoritative answer:
Name: a151.d.akamai.net
Addresses: 203.167.223.242, 203.167.223.236
Aliases: www.trendmicro.com, trendmicro.georedirector.akadns.net
trendmicro.com.edgesuite.net

So anyway, the long and the short of it is, I really like the openDNS Service, I found it excellent infact. However I can not use it because of this issue :-(

So if their is a way to work with Akamai so that they can recognise the source IP Address that would be great, however I realise that their will always be many other services that will have this problem.

Perhaps it is time to extend the DNS Protocol and include a tag for the source of the query inside the DNS query request?

Maybe it got tangled up in the tubes...

http://www.youtube.com/watch?v=EtOoQFa5ug8

@rowansmith, @smileychris

What ISP are you with? I'm with TelstraClear, and apart from using OpenDNS for DNS look-up, I am unable to use any other OpenDNS service. This is due to the ISP's transparent caching proxy. It may explain why I haven't experienced the timeout problems you have. A mixed blessing?

New Zealand ISP's usually use a transparent proxy for http traffic. That might also be the case in Israel. I had a hell of a time setting up VPN's from Israel to the US. This could be affecting OpenDNS in conjuntion with AKAMAI.

Another New Zealander with the same problems with TelstraClear, which is a shame, 'cos I'd really like to use OpenDNS.

I was having problems with this too, am using Telstra and running a home DNSMASQ DNS/DHCP server - at first I thought it was that, but now I realize it's Akamai - which kinda sucks, openDNS is a awesome service and I want it to be available in New Zealand - I just sent a email to Telstra asking if there is any possibility with being able to use our own DNS server's instead of sticking to their own, I will let you know what the response is :)