Mark Sealey

Q: Google results links not working

Anyone else finding that (since upgrading to Yosemite - as far as I can tell) the links returned by a Google search intermittently all fail… "http://www.xxx.xxx could not be opened because the page cannot be found on that server" (or similar)?

 

A second click on the link (on the Google results page) usually goes right to the page. As does clicking on all other links - anywhere.

 

Surely it cannot be a failure of Google?

 

TA!

iMac with Retina 5K display, OS X Yosemite (10.10.3), Clean machine... no haxies; no Microsoft etc

Posted on May 15, 2015 7:13 AM

Close

Q: Google results links not working

  • All replies
  • Helpful answers

Page 1 Next
  • by Mark Sealey,

    Mark Sealey Mark Sealey May 15, 2015 7:18 AM in response to Mark Sealey
    Level 2 (362 points)
    Desktops
    May 15, 2015 7:18 AM in response to Mark Sealey

    An example of the exact error returned by Google: the URL is perfect, correct, and otherwise reachable:

     

    ge.png

  • by Linc Davis,Apple recommended

    Linc Davis Linc Davis May 15, 2015 4:33 PM in response to Mark Sealey
    Level 10 (207,926 points)
    Applications
    May 15, 2015 4:33 PM in response to Mark Sealey

    I suggest you start by taking the steps recommended in this support article.

  • by Mark Sealey,

    Mark Sealey Mark Sealey May 15, 2015 5:03 PM in response to Linc Davis
    Level 2 (362 points)
    Desktops
    May 15, 2015 5:03 PM in response to Linc Davis

    Thanks, Linc

     

    Yes, I saw that and tried what Apple themselves suggested.

     

    I particularly tried removing Google cookies in Privacy > Details.

     

    No good.

     

    It's the oddest thing: These links - only on Google's results page(s) are the only ones that ever fail.

     

    All other links are quick and infallible. All. Always. It's only Google!

     

    I'm thinking that the way Google builds the links as arguments after a 'url?' parameter may be responsible?

     

    That (the first result on their page) fails!

     

    But only the first time. If I let it time out, produce the error and reload the (Google results) page, I'm OK again!

  • by Linc Davis,

    Linc Davis Linc Davis May 15, 2015 5:44 PM in response to Mark Sealey
    Level 10 (207,926 points)
    Applications
    May 15, 2015 5:44 PM in response to Mark Sealey

    Please read this whole message before doing anything.

    This procedure is a diagnostic test. It’s unlikely to solve your problem. Don’t be disappointed when you find that nothing has changed after you complete it.

    The purpose of the test is to determine whether the problem is caused by third-party software that loads automatically at startup or login, by a peripheral device, by a font conflict, or by corruption of the file system or of certain system caches.

    Disconnect all wired peripherals except those needed for the test, and remove all aftermarket expansion cards, if applicable. Start up in safe mode and log in to the account with the problem.

    Note: If FileVault is enabled in OS X 10.9 or earlier, or if a firmware password is set, or if the startup volume is a software RAID, you can’t do this. Ask for further instructions.

    Safe mode is much slower to start up and run than normal, with limited graphics performance, and some things won’t work at all, including sound output and Wi-Fi on certain models. The next normal startup may also be somewhat slow.

    The login screen appears even if you usually login automatically. You must know your login password in order to log in. If you’ve forgotten the password, you will need to reset it before you begin.

    Test while in safe mode. Same problem?

    After testing, restart as usual (not in safe mode) and verify that you still have the problem. Post the results of the test.

  • by Mark Sealey,

    Mark Sealey Mark Sealey May 15, 2015 7:11 PM in response to Linc Davis
    Level 2 (362 points)
    Desktops
    May 15, 2015 7:11 PM in response to Linc Davis

    No change.

  • by Linc Davis,

    Linc Davis Linc Davis May 15, 2015 7:33 PM in response to Mark Sealey
    Level 10 (207,926 points)
    Applications
    May 15, 2015 7:33 PM in response to Mark Sealey

    Restart your router and also your broadband device, if they're separate.

  • by Mark Sealey,

    Mark Sealey Mark Sealey May 15, 2015 8:10 PM in response to Linc Davis
    Level 2 (362 points)
    Desktops
    May 15, 2015 8:10 PM in response to Linc Davis

    Thanks, Linc; I did that: was away on vacation for nearly three weeks, and had power cuts before that; and actually replaced a UPS causing restarts galore.

     

    So my Airport Extreme was on and off often.

     

    Hasn't helped :-(

     

    What puzzles me, and what must be the key to the reason, is that it's only Google results which fail!

  • by Linc Davis,

    Linc Davis Linc Davis May 15, 2015 8:24 PM in response to Mark Sealey
    Level 10 (207,926 points)
    Applications
    May 15, 2015 8:24 PM in response to Mark Sealey

    From the menu bar, select

              ▹ System Preferences... ▹ Network ▹ Advanced... ▹ DNS

    Under DNS Servers you should have one or more numerical addresses, such as “192.168.1.1” or “10.0.0.1”. What are those addresses?

  • by Mark Sealey,

    Mark Sealey Mark Sealey May 15, 2015 9:30 PM in response to Linc Davis
    Level 2 (362 points)
    Desktops
    May 15, 2015 9:30 PM in response to Linc Davis
    208.67.222.222
    208.67.220.220

     

    Those of OpenDNS.

  • by Linc Davis,Apple recommended

    Linc Davis Linc Davis May 15, 2015 9:51 PM in response to Mark Sealey
    Level 10 (207,926 points)
    Applications
    May 15, 2015 9:51 PM in response to Mark Sealey

    Start up in Recovery mode. In the OS X Utilities screen, select Get Help Online. A clean copy of Safari will launch. No plugins, such as Flash, will be available. While in Recovery, you'll have no access to your saved bookmarks or passwords, so make a note of those before you begin, if they're needed for the test.

    Test. After testing, restart as usual and post the results.

  • by Mark Sealey,

    Mark Sealey Mark Sealey May 16, 2015 7:27 AM in response to Linc Davis
    Level 2 (362 points)
    Desktops
    May 16, 2015 7:27 AM in response to Linc Davis

    Thanks, Linc. Same behavior: Google results Pages' links fail…

  • by Linc Davis,

    Linc Davis Linc Davis May 16, 2015 8:26 AM in response to Mark Sealey
    Level 10 (207,926 points)
    Applications
    May 16, 2015 8:26 AM in response to Mark Sealey

    The cause of the problem is external to the computer. It's either your router, your ISP, or OpenDNS (which I don't recommend.)

  • by Mark Sealey,

    Mark Sealey Mark Sealey May 16, 2015 8:55 AM in response to Linc Davis
    Level 2 (362 points)
    Desktops
    May 16, 2015 8:55 AM in response to Linc Davis

    Linc,

     

    I was beginning to think the same thing, too; thanks.

     

    Though I've tested with other browsers and don't seem experience the failures - in FF (38), for example.

     

    Safari has but one extension: 1Password 5.

     

    I like what you say about the ISP - AT&T UVerse - though I think I'd need a month of tranquilizers and some very strong liquor before they'd really be able to help.

     

    What don't you like about OpenDNS?

     

    Alternative(s)?

     

    I suppose I could put back AT&T's DNS IP addresses.

     

    Though why on earth would resolution work for everything except just Google search results whose URLs are built as an argument in the link?

     

    Your help and suggestions appreciated.

  • by Linc Davis,

    Linc Davis Linc Davis May 16, 2015 9:19 AM in response to Mark Sealey
    Level 10 (207,926 points)
    Applications
    May 16, 2015 9:19 AM in response to Mark Sealey

    This is a comment on OpenDNS and other public domain-name system (DNS) services, such as Google DNS. You should use such a service if it solves a problem for you, and not if it creates problems you don't already have. To summarize:

    ☞ Using public DNS will probably not make your network faster, and may make it slower.

    ☞ It will probably not stop your browser from being redirected when you try to connect to a valid web address.

    ☞ It will not make you safer from malware attacks.

    ☞ It could cause confidential information to be compromised.

    ☞ It has other privacy implications that you should be aware of.

    A DNS server resolves the human-readable "domain name" of an Internet host, such as www.apple.com, to the numerical address by which that host can be reached. The process is analogous to looking up a phone number by name. There is no chance that changing the DNS server you use will have any effect on a network problem not related to name resolution.

    There are two valid reasons why you might want to use a public DNS service:

    ☞ The DNS servers provided by your ISP are misconfigured (perhaps deliberately) or don't perform well.

    ☞ You have a use for the filtering controls provided by OpenDNS and others.

    Although some DNS services are touted as responding faster than others, there will be no noticeable difference if your ISP is delivering what you pay for. Most likely, the difference in response time among the DNS servers available to you is on the order of a hundredth of a second or less. But under some conditions, public DNS will significantly slow down network performance. Here is a case in point.

    A content-distribution network (CDN), such as the one used by Apple to deliver software updates and iTunes content, relies on the location of the DNS server to optimize performance. If your query goes to a distant server, you may get slow downloads of Apple content, among other things. From the report of a test carried out by a networking consultant:

    We listed 9 CDNs that would benefit from supporting/using edns-client-subnet, and only two actually support edns-client-subnet: CDN77 and ChinaCache. Others, including Akamai, Internap and CDNetworks, do not currently. This really is too bad, because from the performance data we collected, it is clear these CDNs deliver (much) worse performance currently in many countries to Google DNS and OpenDNS users.

    Another reason often given for using public DNS is to avoid "redirection," that is, false results from a query for a valid domain name. Ethical ISP's do not intentionally redirect valid DNS queries, though it might happen unintentionally because of a misconfiguration; for example, because the address of a network host has recently changed, or because of a "poisoning" attack on the DNS server. Note that many ISP's may, and OpenDNS certainly will, redirect invalid queries to ad sites, in violation of published standards for DNS.

    Recently, a few low-quality commercial ISP's such as "CenturyLink" have taken to deliberately redirecting DNS queries for some domains, such as search engines. Do not tolerate this practice. If your ISP is doing it, then you should demand that the redirection be stopped, or else switch to another ISP.

    Some ISP's have been said to route all DNS queries to their own name servers, regardless of where the queries were directed—another intolerable practice. I haven't heard that any commercial ISP is now doing this, but if yours is, you won't be able to use a public DNS service, even if you change the network settings on your computer or router.

    Of course, if your Internet access is provided by an employer or institution, rather than by a commercial ISP, then you have to take whatever you get.

    The claims on the OpenDNS website that it blocks malware attacks are false advertising. A DNS service does not and cannot block anything. All it can do is to selectively refuse to answer queries. It's trivial for a malware attacker to evade such controls. It's just as easy to evade the parental controls offered by OpenDNS. Nevertheless, you may find those control features useful, despite their limitations. Here is an example of an ASC user who had undesirable results from OpenDNS content filtering.

    If you need to switch DNS providers because of a misconfiguration of your ISP's servers, the change will most likely only need to be temporary. The problem may be resolved automatically within a matter of hours.

    If you're considering whether to use public DNS, such as OpenDNS, on a long-term basis, you should take into account the privacy implications. As a user of the free service, you are not an OpenDNS customer, and the service provider—a for-profit corporation—doesn't have a contract with you. The marketers to whom OpenDNS sells access and information are its customers.

    OpenDNS will know, and store, the address of every Internet server you use. This is from its privacy policy:

    When you use our Services, OpenDNS stores certain DNS, IP address and related information about you to improve the quality of our Service, to provide you with Services and for internal business and analysis purposes.

    Concerning personal information, the policy states:

    ...[I]t is disclosed to entities that perform marketing services on our behalf or to other entities with whom we have joint marketing agreements...

    You can't opt out of those disclosures. Read the privacy policy carefully and draw your own conclusions. The privacy policy of Google DNS seems to be somewhat more benign, but again, you should judge for yourself.

    That's not the worst of it, though. The practice of hijacking nonexistent domains followed by most public DNS services could result in leaking confidential information to a hacker:

    For example, consider the "same origin trust model" used for Web cookies. If you're holding a cookie for GOOGLE.COM and you can be fooled into following a link to KJHSDFKJHSKJHMJHER.GOOGLE.COM, and the resulting NXDOMAIN response is remapped into a positive answer to some advertising server, then you're going to send your cookie to that advertising server when you send your HTTP GET request there. Not such a bad thing for a GOOGLE.COM cookie, but a real problem for a BANKOFAMERICA.COM cookie.

    NXDOMAIN remapping is not something that only happens when you randomly mistype a domain name. It can be exploited deliberately by malicious links placed on any web page. In the case of OpenDNS, the result would be that a cookie intended for another server would be sent to the OpenDNS web server instead. A rogue OpenDNS employee, or anyone who managed to break into the web server, might then be able to impersonate you on another website. If this scenario seems far-fetched, it's the stuff that network exploits are made of.

    See also a brief, and somewhat outdated, critique of OpenDNS on a Harvard Law School blog, with a response from the company's founder.

Page 1 Next