Your IP:

Our Forums Have Moved!

Visit our new forums at http://community.opendns.com/forums/ to post on topics and read the latest content. These forums are now read-only archives.

K-12 Forums

Talk with other K-12 network administrators in your state.

Or see all states.

Categories

Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.

This discussion has been inactive for longer than 30 days, and is thus closed.
    • CommentAuthort.mishka
    • CommentTimeMar 14th 2008
     permalink
    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).
    • CommentAuthorjohndball
    • CommentTimeMar 14th 2008
     permalink
    I've ran the update on both the home version of AVG and the Professional Enterprise edition of AVG and haven't had a problem. When did the problem start?
  1.  permalink
    Administrator
    Have you checked your firewall permissions?
  2.  permalink
    This is very strange. AVG (free version) is fine here.

    Perhaps some of AVG's download mirrors is tagged in some category you blocked, just guessing.
    • CommentAuthorpencoyd
    • CommentTimeMar 14th 2008
     permalink
    Can you tell the exact URL that's being requested/failing?
  3.  permalink
    I just test my AVG to see the hosts..

    First, it download the file /softw/70free/update/avginfo.ctf from guru.grisoft.com

    Then it proceed to download the most current update file from downloadfree.grisoft.com that is just a CNAME for a142.g.akamai.net

    > server resolver1.opendns.com
    Servidor padrÒo: resolver1.opendns.com
    Address: 208.67.222.222

    > set q=any
    > downloadfree.grisoft.com
    Servidor: resolver1.opendns.com
    Address: 208.67.222.222

    Não é resposta de autorização:
    downloadfree.grisoft.com canonical name = downloadfree.grisoft.com.edgesuite.net
    > downloadfree.grisoft.com.edgesuite.net
    Servidor: resolver1.opendns.com
    Address: 208.67.222.222

    Não é resposta de autorização:
    downloadfree.grisoft.com.edgesuite.net canonical name = a142.g.akamai.net
    > a142.g.akamai.net
    Servidor: resolver1.opendns.com
    Address: 208.67.222.222

    Não é resposta de autorização:
    a142.g.akamai.net internet address = 216.246.87.18
    a142.g.akamai.net internet address = 216.246.87.26
    Thankful People: t.mishka
  4.  permalink
    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.
    • CommentAuthort.mishka
    • CommentTimeMar 15th 2008
     permalink
    Very good, then. I can understand the technical issues. I know that Microsoft is using akamai (for downloads and updates) and Intel and so many more. This is a real problem.
    • CommentAuthornickwhit
    • CommentTimeMar 18th 2008
     permalink
    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.
    • CommentAuthort.mishka
    • CommentTimeMar 18th 2008
     permalink
    Actually, I havr a workaround - I am using Vidalia pack and updating the AVG via the privoxy and tor. It works but a little slow.
    • CommentAuthorpencoyd
    • CommentTimeMar 18th 2008
     permalink
    The geo-location issue shouldn't cause failure, just a slightly slower download.
    • CommentAuthort.mishka
    • CommentTimeMar 19th 2008
     permalink
    The updater just times out.
  5.  permalink
    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?
  6.  permalink
    And because I am the persistent type I did some more analysis, the geo-location issues actually cause complete failure of the transfer from AKAMAI. I can reproduce a 100% failure rate.

    What is happening:

    1. The TCP handshake is established at lighting speed
    2. My computer sends the GET request "GET / HTTP/1.1"
    3. I receive a ACK from Akamai for the GET request
    3. NOTHING ... WAIT WAIT WAIT
    4. 40 seconds later .... FIN/ACK ACK FIN/ACK ACK all at lighting speed

    So what is happening? A theory but probably damn close if not spot on:

    1. My computer is setting up a connection with a stateful firewall on the AKAMAI border
    2. The GET request is passed to the AKAMAI Server/Cache
    3. The server responds (destined to my IP Address)
    4. Internal Akamai routing takes place sending my packets back over the optimal path on an Akamai network
    5. These packets hit another firewall somewhere closer to me and promptly get dropped as an out-of-session packet.

    A classic case of an Asymetric Routing issue.
    • CommentAuthormamazitta
    • CommentTimeApr 9th 2008
     permalink
    Maybe it got tangled up in the tubes...

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

    :bigsmile:
    • CommentAuthorChris
    • CommentTimeJul 22nd 2008
     permalink
    I'm having the same problems as rowansmith (and I'm also in New Zealand) with any akamai servers choking.

    Is there any resolution better than just having to switch back to ISP dns?
    • CommentAuthorexncreng
    • CommentTimeJul 22nd 2008 edited
     permalink
    @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?
    • CommentAuthorChris
    • CommentTimeJul 22nd 2008 edited
     permalink
    @nzkiwi

    I'm using TelstraClear too and still experience other problems. For example, if I'm using OpenDNS then I can't do a Vista "Windows Update" check (due, as far as I can tell, to the akamai problems).
    • CommentAuthordiacon
    • CommentTimeJul 22nd 2008
     permalink
    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.
    • CommentAuthorlogonbat
    • CommentTimeAug 6th 2008
     permalink
    I have the same problem updating my CA Antivirus from New Zealand. Also with TelstrClear. Updates just time out.
    • CommentAuthorConor Boyd
    • CommentTimeSep 20th 2008
     permalink
    Another New Zealander with the same problems with TelstraClear, which is a shame, 'cos I'd really like to use OpenDNS.
    • CommentAuthorexncreng
    • CommentTimeSep 23rd 2008
     permalink
    The problem is NOT with TelstraClear as OpenDNS now works correctly on their network. the problem appears to be a geo-location issue related to Akamai (see the postings by rowansmith earlier in this thread).

    Using OpenDNS from NZ results in Akamai serviced mirrors being feed from USA (128.241.220.72, 128.241.220.73) whereas using a NZ based DNS service results in being feed from a NZ based mirror (203.167.223.242, 203.167.223.236). The result is likely to be the same regardless of which NZ ISP is being used.
    • CommentAuthoragentb
    • CommentTimeNov 1st 2008
     permalink
    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 :)

This discussion has been inactive for longer than 30 days, and is thus closed.