I can confirm that at least with my internet provider whenever OpenDNS is set up google searches lag anywhere from 10 to 40 seconds and a tracert reveals delayed (and sometimes even dropped) responses on hops. I have even tried forcing the proper google ips using hosts to get around OpenDNS's google hijack to no success. The instant the DNS is set to auto, things go back to normal with pristene tracert's and blazing searches/acess time.

I have confirmed this on neighbors and freinds machines(same ISP) and with IE, FF, and Opera. This is not my computer or settings, this is something the matter with either my ISP or OpenDNS and it seems more likely to me to be OpenDNS as there arent any problems with their dns servers not enabled.

As much as I love OpenDNS, I just cannot stand 10+ seconds waiting for every google query to load.

ISP is CableOne(in Idaho).

tracert:
1 10 ms 6 ms 8 ms 10.x.x.x
2 11 ms 7 ms 8 ms xx-xxx.xx-xx-cpe.cableone.net [72.xx.xx.xxx]
3 10 ms 7 ms 8 ms xx-xxx-xx-xxx.static.twtelecom.net [64.xx.xx.xxx]
4 43 ms 41 ms 42 ms peer-02-so-0-0-0-0.palo.twtelecom.net [64.129.248.19]
5 41 ms 41 ms 41 ms xe-4-1.r04.plalca01.us.bb.gin.ntt.net [129.250.4.122]
6 43 ms 41 ms 42 ms fa-3-3.r04.plalca01.us.ce.gin.ntt.net [140.174.21.166]
7 43 ms 44 ms 44 ms resolver1.opendns.com [208.67.222.222]
----
1 12 ms 9 ms 7 ms 10.x.x.x
2 7 ms 10 ms 11 ms xx-xxx.xx-xx-cpe.cableone.net [72.xx.xx.xxx]
3 7 ms 11 ms 7 ms xx-xxx-xx-xxx.static.twtelecom.net [64.xx.xx.xxx]
4 42 ms 47 ms 47 ms peer-02-so-0-0-0-0.palo.twtelecom.net [64.129.248.19]
5 49 ms 48 ms 62 ms xe-4-1.r04.plalca01.us.bb.gin.ntt.net [129.250.4.122]
6 210 ms 232 ms 236 ms fa-3-3.r04.plalca01.us.ce.gin.ntt.net [140.174.21.166]
7 41 ms 63 ms 45 ms resolver2.opendns.com [208.67.220.220]

By the way this is a recent development, this only started happening once you guys started hijacking google searches.

tracert of google.navigation.opendns.com:
1 8 ms 7 ms 8 ms 10.x.x.x
2 7 ms 7 ms 8 ms xx-xxx.xx-xx-cpe.cableone.net [72.xx.xx.xxx]
3 9 ms 10 ms 6 ms xx-xxx-xx-xxx.static.twtelecom.net [64.xxx.xx.xxx]
4 41 ms 45 ms 42 ms peer-02-so-0-0-0-0.palo.twtelecom.net [64.129.248.19]
5 84 ms 42 ms 61 ms xe-4-1.r04.plalca01.us.bb.gin.ntt.net [129.250.4.122]
6 42 ms 42 ms 41 ms fa-3-3.r04.plalca01.us.ce.gin.ntt.net [140.174.21.166]
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
... and it continued like that to the final hop (30)

Ya, I have no clue why this is going on. But I think its directly related with you guys hooking google search traffic. Is there any way you could turn that stuff off on my account and see if that fixes it?

Did not work, was still intercepting google.

So, nobody cares anymore then?

a little workaround maybe configure your DNS server to forward all requests to google.com direct to your isp dns and not to opendns.

but for people at home with simple routers I think things can't be done that way.

@mike240se:

They can use DNS to hijack any domain. For example, typo correction "hijacks" craigslist.og and redirects you to the right site. If they were evil, they could hijack www.paypal.com or something (using HTTPS would make that more difficult though). Fortunately, they're not.

They point www.google.com to their own servers, to work around some Dell adware crap or to help with shortcuts or something. See http://blog.opendns.com/2007/05/22/google-turns-the-page/ or half a dozen other forum threads. It's possible to disable it by submitting a support request and asking them to turn off shortcuts on your account (the dashboard is not enough; they have to do it).

Shrug. I don't know and I don't care. I have just about everything turned off.

Edit: Hmm, rereading this post, it sounds a little rude. Oops.

Yes, I do run McAfee SiteAdvisor.

I contacted OpenDNS support to request that they disable Shortcuts on my account, since my attempts to do so did not stop redirection of Google requests or restore SiteAdvisor functionality.

The good news is that the Support team resolved the problem for me within an hour. Google requests from both networks I manage are no longer redirected through “google.navigation.opendns.com.” (Google) searches now run as quickly as ever and, once again, include McAfee SiteAdvisor “safety ratings.” According to the Support team’s response to my inquiry, they “altered a setting in your account which should resolve this matter until we come up with a more permanent solution system-wide.”

The bad news is that both “typo correction” and “shortcuts” had to be disabled to get here. Unfortunately, many OpenDNS “features” (e.g., Content Filtering and Adult Site Blocking) rely on these and are, therefore, also disabled. According to the Support team, only Phishing Protection remains available. My Dashboard, however, indicates Domain Whitelisting and (individual) Domain Blocking are still functional.

Additional bad news came in response to my inquiry about when the “more permanent solution system-wide” might be available for those of us who'd like to take advantage of Content Filtering and Adult Site Blocking without the Google performance hit and loss of SiteAdvisor “safety ratings.” Their response now states “our business model is based upon using this feature and you cant have one without the other.” They went on to say “we cannot make this change each time your IP updates. You will need to use software to keep it updated in your account. Keep in mind that this is not something we normally do for users, since as you have seen first-hand, that it disables all of our other services.”

I’m not sure how this equates to a “more permanent solution system-wide…?” It’s also worth noting that my Idea Bank suggestion, that users be allowed to opt-out of the Google redirect, has gone nowhere (i.e., has not been approved for a vote of the users) since I submitted it a couple of days ago.

Happy to, John. My apologies for any problems caused.

Given the frustration I (and several others, from the look of things) have with this "feature", and the difficulty in locating CURRENT ACCURATE information about it, perhaps you could post a Knowledge Base article? If one exists, I'd appreciate you directing me to it, since my searches were fruitless.

On a related note, can/will you comment on whether your business model really is based upon using this feature? Is a "more permanent solution system-wide" in the works? Will users be able to opt-out, more easily and without the loss of valuable services like Content Filtering and Adult Site Blocking, in the future?

Thanks, in advance, for your insights on this issue.

Wrote back to you directly already.

http://www.opendns.com/support/cache/ helps you check this out.

Your image doesn't show you visiting johndball.com though.

What's the address bar URL you have when you get this error message?

I am also having strange timeouts, I im in Ireland and if I try to open www.google.com it timesout, if I open www.google.ie it does not. here are my pings and tracert.

ping www.google.ie

Pinging google.navigation.opendns.com [208.69.34.230] with 32 bytes of data:

Reply from 208.69.34.230: bytes=32 time=94ms TTL=53
Reply from 208.69.34.230: bytes=32 time=46ms TTL=53
Reply from 208.69.34.230: bytes=32 time=49ms TTL=53
Reply from 208.69.34.230: bytes=32 time=47ms TTL=53

Ping statistics for 208.69.34.230:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 94ms, Average = 59ms

ping www.google.com

Pinging google.navigation.opendns.com [208.69.34.231] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 208.69.34.231:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Now sometimes it switches but every time I go through google.navigation.opendns.com [208.69.34.231] it times out whereas 208.69.34.230 does not.

Tracing route to resolver1.opendns.com [208.67.222.222]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 195.xxx.x.xx
2 * * * Request timed out.
3 44 ms 18 ms 18 ms bas505.cwt.esat.net [193.95.136.241]
4 21 ms 19 ms 19 ms vlan500.rt501.cwt.esat.net [193.95.136.124]
5 22 ms 18 ms 19 ms vlan53.rt002.cwt.esat-x.com [193.95.130.153]
6 21 ms 19 ms 18 ms ge2-0.br003.cwt.esat.net [193.95.129.23]
7 20 ms 19 ms 20 ms ge-2-3-0-110.dub20.ip.tiscali.net [213.200.67.25
3]
8 77 ms 36 ms 36 ms xe-1-0-0.ams10.ip.tiscali.net [89.149.186.241]
9 39 ms 37 ms 37 ms ge-1.ams-ix.amstnl02.nl.bb.gin.ntt.net [195.69.1
44.36]
10 * * * Request timed out.
11 48 ms 46 ms 49 ms p64-2-0-0.r23.londen03.uk.bb.gin.ntt.net [129.25
0.4.104]
12 46 ms 47 ms 47 ms xe-3-1.r01.londen03.uk.bb.gin.ntt.net [129.250.2
.46]
13 * * * Request timed out.
14 47 ms 45 ms 46 ms resolver1.opendns.com [208.67.222.222]