Are OpenDNS's servers stuck?

Comments

24 comments

  • Avatar
    rotblitz

    As this is the only report of this kind here, I would think it's you or your ISP, not OpenDNS.

  • Avatar
    Kristy Patullo

    It doesn't appear that our NYC servers were having issues: http://system.opendns.com/.  Are you still seeing this behavior?  

  • Avatar
    otto42

    There does appear to be some kind of persistent issue occurring with the OpenDNS servers in general, affecting multiple sites.

    In particular, I've been seeing reports of it responding with incorrect responses to valid domains, resulting in SSL certificate mismatch errors when various systems using OpenDNS are trying to access https URLs.

    Examples:

    https://wordpress.org/support/topic/automatic-updates-of-core-and-plugins-failing-too-many-redirects?replies=16

    https://wordpress.org/support/topic/download-failed-ssl-peer-certificate-or-ssh-remote-key-was-not-ok?replies=9

    In both of the above cases, hits to the "downloads.wordpress.org" domain were given responses that redirected them to an opendns.com site, with their certificate, which (correctly) caused a failure.

    Another example showed up on the StackExchange site where a person got the same result when trying to access github.com with OpenDNS:

    https://stackoverflow.com/questions/23231788/ssl-error-certificate-subject-name-does-not-match-target-host-for-github-com

    Something is happening, and it's causing a lot of behind-the-scenes kinds of problems.

     

  • Avatar
    rotblitz

    "I've been seeing reports of it responding with incorrect responses to valid domains, resulting in SSL certificate mismatch errors when various systems using OpenDNS are trying to access https URLs."

    Are you using content filtering, typo correction or security settings from OpenDNS?  These are generally "incorrect responses" you expect to receive, else the system would not work as supposed to work, e.g. would not block the sites you expect to be blocked.  And naturally, as a mandatory consequence, if these are related to a HTTPS site, you'll necessarily get this certificate mismatch error.

    So, what are you complaining about?

  • Avatar
    glnz

    To all:  Just ran some comparative tests, and I still have my original problem.  See attached word doc.  Before (not OpenDNS in my router) and after (yes OpenDNS).  My ISP is Verizon DSL at home in NYC, zip code 10023.

    Also, I ran a traceroute while OpenDNS was in my modem-router, and here are part of the results - note the initial time-out.

    The current date is: Thu 04/24/2014
    Enter the new date: (mm-dd-yy) The current time is:  9:13:20.10
    Enter the new time:  
    Server:  resolver1.opendns.com
    Address:  208.67.222.222

    DNS request timed out.
        timeout was 2 seconds.
     
    Server:  Broadcom.Home
    Address:  192.168.1.1

    debug.opendns.com    text =

        "server 1.nyc"
    debug.opendns.com    text =

        "flags 20 0 2f4 4000800000000000000"
    debug.opendns.com    text =

        "id 0"
    debug.opendns.com    text =

        "source 96.246.115.222:38384"
     




    Speedtests 4-24-14 started 0855am.doc
  • Avatar
    glnz

    By the way, the word doc attached above has two pages.

  • Avatar
    j.allan

    This is absolutely happening to me on my desktop. Sites like my local library, PBS, and even some OpenDNS pages. I get things like this: http://guidetest.a.id.opendns.com/?url=guidetest%2Ea%2Eid%2Eopendns%2Ecom%2F%3Furl%3Dguidetest%252Ea%252Eid%252Eopendns%252Ecom%252F%253Furl%253Dguidetest%25252Ea%25252Eid%25252Eopendns%25252Ecom%25252F%25253Furl%25253Dguidetest%2525252Ea%2525252Eid%2525252Eopendns%2525252Ecom%2525252F%2525253Furl%2525253Dguidetest%252525252Ea%252525252Eid%252525252Eopendns%252525252Ecom%252525252F%252525253Furl%252525253Dguidetest%25252525252Ea%25252525252Eid%25252525252Eopendns%25252525252Ecom%25252525252F%25252525253Furl%25252525253Dguidetest%2525252525252Ea%2525252525252Eid%2525252525252Eopendns%2525252525252Ecom%2525252525252F%2525252525253Furl%2525252525253Dguidetest%252525252525252Ea%252525252525252Eid%252525252525252Eopendns%252525252525252Ecom%252525252525252F%252525252525253Furl%252525252525253Dguidetest%25252525252525252Ea%25252525252525252Eid%25252525252525252Eopendns%25252525252525252Ecom%25252525252525252F%25252525252525253Furl%25252525252525253Dguidetest%2525252525252525252Ea%2525252525252525252Eid%2525252525252525252Eopendns%2525252525252525252Ecom%2525252525252525252F%2525252525252525253Furl%2525252525252525253Dguidetest%252525252525252525252Ea%252525252525252525252Eid%252525252525252525252Eopendns%252525252525252525252Ecom%252525252525252525252F%252525252525252525253Furl%252525252525252525253Dguidetest%25252525252525252525252Ea%25252525252525252525252Eid%25252525252525252525252Eopendns%25252525252525252525252Ecom%25252525252525252525252F%25252525252525252525253Furl%25252525252525252525253Dguidetest%2525252525252525252525252Ea%2525252525252525252525252Eid%2525252525252525252525252Eopendns%2525252525252525252525252Ecom%2525252525252525252525252F%2525252525252525252525253Furl%2525252525252525252525253Dguidetest%252525252525252525252525252Ea%252525252525252525252525252Eid%252525252525252525252525252Eopendns%252525252525252525252525252Ecom%252525252525252525252525252F%252525252525252525252525253Furl%252525252525252525252525253Dguidetest%25252525252525252525252525252Ea%25252525252525252525252525252Eid%25252525252525252525252525252Eopendns%25252525252525252525252525252Ecom%25252525252525252525252525252F%25252525252525252525252525253Furl%25252525252525252525252525253Dpbskids%2525252525252525252525252525252Eorg

    Ridiculous. 

  • Avatar
    otto42

    @rotblitz I think you are misunderstanding here. I don't use OpenDNS at all. I am a developer on WordPress.org, and we are getting reports like these from users who also do not use OpenDNS, at least knowingly. They have accounts on hosts with servers that were configured to use OpenDNS. 

    Now, I don't know what their blocking settings are, but if they are using settings configured to block these sites, then that configuration is new to them, within the last week or so, because these same servers and users were having no problems before. 

    Our response has been to tell these users to check with the hosting services to ask if they are using OpenDNS, and to ask them to switch to normal DNS instead. This has solved their problem, but somehow I don't believe that it is a solution that OpenDNS wants us to be recommending. Nevertheless, telling people to not use OpenDNS at all is a solution that is currently working for those who have tried it, and unless we can discover some other fix, it's one we're going to have to stick with.

    This is not user error. It is not a configuration error on specific accounts. This is a systemic issue happening to many people at multiple hosting services. All of them are having the same problems, and ceasing to use OpenDNS is fixing it for them. I am merely relying the issue and asking for a real fix instead.

  • Avatar
    Matt Prytuluk

    Hi otto42 and glnz,

    We are aware of a strange and infrequent problem that matches the description of the problem in this thread.  We're actively working on a fix and will let everyone know when it's been deployed.  Apologies for the trouble-- we'll let you know.

     

    Best,

    Matt

  • Avatar
    rotblitz

    @otto42 
    "They have accounts on hosts with servers that were configured to use OpenDNS... This is a systemic issue happening to many people at multiple hosting services."

    What?  Oops, this is not the intended use of OpenDNS.  Such services are strictly requested to use "Premium DNS" exclusively which does not have content filtering, but pure DNS.  According to OpenDNS' policies, they'll be blocking such usage if they become aware of.

    Whatever, I'm a user only.  You had to raise a support ticket.  We users cannot help with this, and I cannot reproduce your problem yet.

     

    @glnz 
    Not sure why you post speed tests.  DNS has nothing to do with your upload and download speed.  DNS is the phone book of the internet, not the phone lines.  It does not make sense to test your phone lines while using different phone books...

    You'll have to run the diagnostics: https://support.opendns.com/entries/21841580-Diagnostic-Tool-Link

    Then you open a support ticket with the diagnostic results URL.

    If you look after a DNS benchmark (which is unrelated to a speed test), then see https://www.grc.com/dns/benchmark.htm

    From your nslookup output I see that you use the OpenDNS New York location, that you have the OpenDNS resolver addresses configured on a Broadcom router.  But your IP address 96.246.115.222 is not registered with your OpenDNS dashboard network, so your OpenDNS settings do not take effect.

  • Avatar
    rotblitz

    @otto42 
    After a deeper look into the links you posted, I'm convinced this is related to Heartbleed vulnerability fix attempts and totally unrelated to OpenDNS.  DNS (and therefore OpenDNS) is related to connectivity and TLS/SSL in no way.  DNS is the phone book of the internet, not the phone lines.

  • Avatar
    otto42

    @rotblitz No, I'm certain that it is not related to Heartbleed. This is not an SSL issue, it is clearly a DNS issue.

    See, In the reported cases, the servers in question are receiving DNS responses that are redirecting their systems to some opendns.com system, thus (correctly) causing the ssl-certificate mismatch. The issue is thus not an SSL issue, but a DNS issue. They get the mismatch because they're talking to a server that they did not expect to be talking to.

    OpenDNS is definitely involved, as the ssl-cert received by these systems is opendns.com's certificate. Additionally, disabling the use of OpenDNS on these servers solves the problem immediately. That's fairly definitive. The issue is rare, but wholly reproducible for the systems that get it.

     

    @mattp1 Thank you for the information. I understand that some hosts may be incorrectly using OpenDNS systems for this type of purpose as well, and we'll continue to inform people about the issue when it happens.

     

  • Avatar
    Matt Prytuluk

    Hi all, 

    The problem should now be fixed.  Please re-test and confirm to let us know if that's the case (or not).

    Some tech detail: In essence, we were seeing clients query the AAAA (IPv6 record) for a domain.  The servers return NODATA, but the client then requery the AAAA with the search suffix attached.  It's unusual behavior for a client, but  we were able to mitigate it by removing additional results for the AAAA record requests from our DNS servers.   No one's fault per se, but definitely something we didn't expect to see-- and something that only happens for certain client software making the requests to certain sites, which is why it's hard to reproduce.

    A special thanks to the OpenDNS customers who were able to submit packet captures.

    Hope that helps everyone!  Please be sure to confirm a resolution, we're keeping an eye on our side as well.

    Best,

    Matt

     

     

  • Avatar
    rotblitz

    "something that only happens for certain client software making the (AAAA) requests to certain sites"

    Great stuff, and unexpected and surprising findings.  You guys and the packet capture contributors did a great job!

    It could well have been related to Heartbleed fixes, but apparently wasn't (or maybe still is as it concentrated on TLS/SSL?).

  • Avatar
    dabblefridge

    I've experienced a lot of similar and reproducible problems on my Dell desktop, but my newer Dell laptop has no problems with the sites that hang when I use the desktop.  The key difference between the two machines is the operating system.  On the older Dell desktop, I run Windows XP.  Thus it appears to have something to do with -- and may be confined to -- users running WinXP.  

    In the meantime, I have switched my router to the Google DNS and am having no more troubles.

  • Avatar
    glnz

    Rotblitz and Matt:  Haven't had time to put OpenDNS back in my modem-router to check, but (without using OpenDNS) I've been running some traceroutes and see something funny.

    I've pasted below part of my most recent set of traceroutes from a few minutes ago.  Notice how the second run (to your second IP number) doesn't get resolved like the first run (your first IP number).  Is that normal?

    Also, at the start, there is

    DNS request timed out.
        timeout was 2 seconds.

    Is that OK?

    Before giving you the traceroute results below, FYI - the first thing I do is run ipconfig /flushdns.

    Then my traceroute batch file has the following:

    echo. >> tracelog755.txt
    nslookup -type=txt which.opendns.com. 208.67.222.222 >> tracelog755.txt
    echo. >> tracelog755.txt
    nslookup -type=txt debug.opendns.com. >> tracelog755.txt
    echo. >> tracelog755.txt
    tracert 208.67.222.222 >> tracelog755.txt
    echo. >> tracelog755.txt
    tracert 208.67.220.220 >> tracelog755.txt
    echo. >> tracelog755.txt
    tracert www.google.com >> tracelog755.txt
    echo. >> tracelog755.txt

    So - here are the results:


    --------  
     
    The current date is: Fri 04/25/2014
    Enter the new date: (mm-dd-yy) The current time is: 12:58:40.81
    Enter the new time:  

    Windows IP Configuration

    Successfully flushed the DNS Resolver Cache.

    --------  
     
    The current date is: Fri 04/25/2014
    Enter the new date: (mm-dd-yy) The current time is: 12:58:45.39
    Enter the new time:  
    DNS request timed out.
        timeout was 2 seconds.
    Server:  UnKnown
    Address:  208.67.222.222

    which.opendns.com    text =

        "9.nyc"
     
    Server:  Broadcom.Home
    Address:  192.168.1.1

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

      1    <1 ms    <1 ms    <1 ms  Broadcom.Home [192.168.1.1]
      2    10 ms    10 ms    10 ms  10.32.234.1
      3    14 ms    15 ms    12 ms  G1-1-1-1.NYCMNY-LCR-21.verizon-gni.net [130.81.198.128]
      4   109 ms    12 ms    13 ms  ae3-0.NY325-BB-RTR1.verizon-gni.net [130.81.199.162]
      5    12 ms    11 ms    12 ms  0.xe-3-0-1.BR1.NYC1.ALTER.NET [152.63.5.149]
      6     *        *        *     Request timed out.
      7    96 ms    99 ms    97 ms  vlan52.ebr2.NewYork2.Level3.net [4.69.138.254]
      8    94 ms    92 ms    95 ms  ae-47-47.ebr2.NewYork1.Level3.net [4.69.201.33]
      9    95 ms    97 ms    96 ms  ae-72-72.csw2.NewYork1.Level3.net [4.69.148.38]
     10   104 ms   109 ms   104 ms  ae-2-70.edge1.NewYork1.Level3.net [4.69.155.78]
     11    96 ms    93 ms    92 ms  OPEN-DNS-IN.edge1.NewYork1.Level3.net [4.78.132.22]
     12    89 ms    93 ms    95 ms  resolver1.opendns.com [208.67.222.222]

    Trace complete.
     

    Tracing route to resolver2.opendns.com [208.67.220.220]
    over a maximum of 30 hops:

      1    <1 ms    <1 ms    <1 ms  Broadcom.Home [192.168.1.1]
      2    10 ms    10 ms    10 ms  10.32.234.1
      3    15 ms    15 ms    12 ms  G1-1-0-4.NYCMNY-LCR-21.verizon-gni.net [130.81.196.204]
      4    14 ms    12 ms    12 ms  ae0-0.NY325-BB-RTR2.verizon-gni.net [130.81.209.110]
      5    12 ms    12 ms    12 ms  0.xe-9-1-0.BR1.NYC1.ALTER.NET [152.63.4.241]
      6     *        *        *     Request timed out.
      7    99 ms    96 ms    97 ms  vlan52.ebr2.NewYork2.Level3.net [4.69.138.254]
      8    99 ms    99 ms    97 ms  ae-48-48.ebr2.NewYork1.Level3.net [4.69.201.37]
      9    98 ms    96 ms    98 ms  ae-62-62.csw1.NewYork1.Level3.net [4.69.148.34]
     10   100 ms   101 ms    99 ms  ae-1-60.edge1.NewYork1.Level3.net [4.69.155.14]
     11    96 ms    94 ms    95 ms  OPEN-DNS-IN.edge1.NewYork1.Level3.net [4.78.132.22]
     12     *        *        *     Request timed out.
     13     *        *        *     Request timed out.
     14     *        *        *     Request timed out.
     15     *        *        *     Request timed out.
     16     *        *        *     Request timed out.
     17     *        *        *     Request timed out.
     18     *        *        *     Request timed out.
     19     *        *        *     Request timed out.
     20     *        *        *     Request timed out.
     21     *        *        *     Request timed out.
     22     *        *        *     Request timed out.
     23     *        *        *     Request timed out.
     24     *        *        *     Request timed out.
     25     *        *        *     Request timed out.
     26     *        *        *     Request timed out.
     27     *        *        *     Request timed out.
     28     *        *        *     Request timed out.
     29     *        *        *     Request timed out.
     30     *        *        *     Request timed out.

    Trace complete.
     

    Tracing route to www.google.com [74.125.228.51]
    over a maximum of 30 hops:

      1    <1 ms    <1 ms    <1 ms  Broadcom.Home [192.168.1.1]
      2    10 ms    10 ms    10 ms  10.32.234.1
      3    15 ms    15 ms    16 ms  G1-1-0-4.NYCMNY-LCR-22.verizon-gni.net [130.81.196.206]
      4     *        *       14 ms  so-3-1-0-0.NY5030-BB-RTR1.verizon-gni.net [130.81.151.234]
      5    22 ms    58 ms    59 ms  0.so-6-0-3.XT1.NYC4.ALTER.NET [152.63.17.85]
      6    17 ms    20 ms    19 ms  TenGigE0-4-4-0.GW8.NYC4.ALTER.NET [152.63.18.202]
      7    16 ms    15 ms    15 ms  google-gw.customer.alter.net [152.179.72.62]
      8    17 ms    16 ms    25 ms  72.14.238.232
      9    16 ms    16 ms    16 ms  209.85.252.250
     10    25 ms    25 ms    24 ms  72.14.239.93
     11    24 ms    31 ms    24 ms  72.14.236.147
     12    24 ms    25 ms    24 ms  72.14.238.175
     13    22 ms    22 ms    22 ms  iad23s06-in-f19.1e100.net [74.125.228.51]

    Trace complete.

    I'll be interested in your thoughts as to the two questions above.

  • Avatar
    rotblitz

    Server:  UnKnown

    Weird, your currently used DNS service seems to have troubles with reverse DNS queries...

    "to your second IP number"

    This isn't mine.  I'm a user like you.

    "the second run (to your second IP number) doesn't get resolved like the first run (your first IP number).  Is that normal?"

    No.  It seems that your ISP or the network carriers have configured suboptimal routing.  Or  resolver1.opendns.com in NY doesn't respond to IMCP packets.  Or the error was related to this mentioned reverse DNS lookup.

    "Also, at the start, there is

    DNS request timed out.
        timeout was 2 seconds.

    Is that OK?"

    No.  It seems the DNS service you're currently using has lousy response times (of more than 2 seconds) or doesn't sometimes respond at all.

    You may want to run a DNS benchmark: https://www.grc.com/dns/benchmark.htm

  • Avatar
    glnz

    Rotblitz - I have now put OpenDNS's IP addresses back into my modem router.  Speedtest.net has NOT timed out when I point to the test server in Secaucus.  However, Speedtest.net is not completing all of its test every time (ping, download and upload), but that's also true when I don't have OpenDNS in my modem-router.  Also, with OpenDNS, I am now able to go to www.actiontecsupport.com and to www.ocster.com.

    I have re-run my traceroute batch file.  Here we are:

    --------  
     
    The current date is: Fri 04/25/2014
    Enter the new date: (mm-dd-yy) The current time is: 17:51:25.20
    Enter the new time:  

    Windows IP Configuration

    Successfully flushed the DNS Resolver Cache.
     
     
    --------  
     
    The current date is: Fri 04/25/2014
    Enter the new date: (mm-dd-yy) The current time is: 17:51:29.07
    Enter the new time:  
    Server:  resolver1.opendns.com
    Address:  208.67.222.222

    which.opendns.com    text =

        "5.nyc"
     
    Server:  Broadcom.Home
    Address:  192.168.1.1

    debug.opendns.com    text =

        "server 5.nyc"
    debug.opendns.com    text =

        "flags 20 0 2fe 0"
    debug.opendns.com    text =

        "id 1232070"
    debug.opendns.com    text =

        "source 96.246.112.188:54312"
     

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

      1    <1 ms    <1 ms    <1 ms  Broadcom.Home [192.168.1.1]
      2    10 ms    10 ms    10 ms  10.32.234.1
      3    13 ms    11 ms    11 ms  G1-1-1-1.NYCMNY-LCR-21.verizon-gni.net [130.81.198.128]
      4    12 ms    12 ms    12 ms  ae0-0.NY325-BB-RTR1.verizon-gni.net [130.81.209.102]
      5    12 ms    11 ms    11 ms  0.xe-3-0-1.BR1.NYC1.ALTER.NET [152.63.5.149]
      6     *        *        *     Request timed out.
      7   111 ms   109 ms   108 ms  vlan52.ebr2.NewYork2.Level3.net [4.69.138.254]
      8   100 ms    98 ms    97 ms  ae-46-46.ebr2.NewYork1.Level3.net [4.69.201.29]
      9   103 ms   105 ms   104 ms  ae-92-92.csw4.NewYork1.Level3.net [4.69.148.46]
     10    99 ms   109 ms    99 ms  ae-4-90.edge1.NewYork1.Level3.net [4.69.155.206]
     11    99 ms    98 ms   101 ms  OPEN-DNS-IN.edge1.NewYork1.Level3.net [4.78.132.22]
     12   101 ms   100 ms    98 ms  resolver1.opendns.com [208.67.222.222]

    Trace complete.
     

    Tracing route to resolver2.opendns.com [208.67.220.220]
    over a maximum of 30 hops:

      1    <1 ms    <1 ms    <1 ms  Broadcom.Home [192.168.1.1]
      2    10 ms    11 ms    11 ms  10.32.234.1
      3    14 ms    11 ms    16 ms  G1-1-0-4.NYCMNY-LCR-21.verizon-gni.net [130.81.196.204]
      4    15 ms    12 ms    13 ms  ae5-0.NY325-BB-RTR1.verizon-gni.net [130.81.163.208]
      5    12 ms    12 ms    12 ms  0.xe-3-0-1.BR1.NYC1.ALTER.NET [152.63.5.149]
      6     *        *        *     Request timed out.
      7   100 ms   103 ms   103 ms  vlan52.ebr2.NewYork2.Level3.net [4.69.138.254]
      8    99 ms    98 ms    98 ms  ae-46-46.ebr2.NewYork1.Level3.net [4.69.201.29]
      9   109 ms   108 ms   107 ms  ae-82-82.csw3.NewYork1.Level3.net [4.69.148.42]
     10    99 ms   124 ms    96 ms  ae-3-80.edge1.NewYork1.Level3.net [4.69.155.142]
     11   100 ms   102 ms   149 ms  OPEN-DNS-IN.edge1.NewYork1.Level3.net [4.78.132.22]
     12    92 ms    94 ms    95 ms  resolver2.opendns.com [208.67.220.220]

    Trace complete.
     

    Tracing route to www.google.com [74.125.226.241]
    over a maximum of 30 hops:

      1    <1 ms    <1 ms    <1 ms  Broadcom.Home [192.168.1.1]
      2    10 ms    10 ms    10 ms  10.32.234.1
      3    17 ms    15 ms    15 ms  G1-1-0-4.NYCMNY-LCR-22.verizon-gni.net [130.81.196.206]
      4    14 ms     *       13 ms  so-5-0-0-0.NY5030-BB-RTR1.verizon-gni.net [130.81.22.18]
      5    13 ms    13 ms    13 ms  0.xe-6-1-1.XT1.NYC4.ALTER.NET [152.63.10.57]
      6    21 ms    23 ms    23 ms  TenGigE0-6-0-0.GW8.NYC4.ALTER.NET [152.63.22.41]
      7    15 ms    13 ms    13 ms  google-gw.customer.alter.net [152.179.72.62]
      8    31 ms    13 ms    13 ms  72.14.238.232
      9    14 ms    25 ms    13 ms  72.14.239.252
     10    14 ms    13 ms    13 ms  lga15s29-in-f17.1e100.net [74.125.226.241]

    Trace complete.

    ►But my complete set of traceroutes also has this:

    Tracing route to nyc.speakeasy.net [216.254.95.2]
    over a maximum of 30 hops:

      1    <1 ms    <1 ms    <1 ms  Broadcom.Home [192.168.1.1]
      2    10 ms    10 ms    10 ms  10.32.234.1
      3    14 ms    15 ms    11 ms  G1-1-1-1.NYCMNY-LCR-21.verizon-gni.net [130.81.198.128]
      4    12 ms    33 ms    12 ms  so-11-0-0-0.NY325-BB-RTR1.verizon-gni.net [130.81.151.222]
      5    12 ms    12 ms    12 ms  0.xe-1-1-0.BR2.NYC4.ALTER.NET [152.63.20.197]
      6    23 ms    24 ms    25 ms  te9-2-0d0.cir1.nyc-ny.us.xo.net [206.111.13.125]
      7    33 ms    33 ms    34 ms  207.88.14.177.ptr.us.xo.net [207.88.14.177]
      8    27 ms    26 ms    24 ms  ae0d0.mcr1.nyc-ny.us.xo.net [216.156.0.18]
      9    31 ms    32 ms    34 ms  207.239.55.82
     10     *        *        *     Request timed out.
     11     *        *        *     Request timed out.
     12     *        *        *     Request timed out.
     13     *        *        *     Request timed out.
     14     *        *        *     Request timed out.
     15     *        *        *     Request timed out.
     16     *        *        *     Request timed out.
     17     *        *        *     Request timed out.
     18     *        *        *     Request timed out.
     19     *        *        *     Request timed out.
     20     *        *        *     Request timed out.
     21     *        *        *     Request timed out.
     22     *        *        *     Request timed out.
     23     *        *        *     Request timed out.
     24     *        *        *     Request timed out.
     25     *        *        *     Request timed out.
     26     *        *        *     Request timed out.
     27     *        *        *     Request timed out.
     28     *        *        *     Request timed out.
     29     *        *        *     Request timed out.
     30     *        *        *     Request timed out.

    Trace complete.


    Tracing route to www.ocster.com [176.34.235.5]
    over a maximum of 30 hops:

      1    <1 ms    <1 ms    <1 ms  Broadcom.Home [192.168.1.1]
      2    11 ms    10 ms    10 ms  10.32.234.1
      3    14 ms    15 ms    15 ms  G1-1-0-4.NYCMNY-LCR-22.verizon-gni.net [130.81.196.206]
      4     *        *       14 ms  so-5-0-0-0.NY5030-BB-RTR1.verizon-gni.net [130.81.22.18]
      5    15 ms    15 ms    15 ms  0.so-6-0-3.XT1.NYC4.ALTER.NET [152.63.17.85]
      6    25 ms    23 ms    24 ms  TenGigE0-6-4-0.GW8.NYC4.ALTER.NET [152.63.21.121]
      7    45 ms    43 ms    44 ms  tinet-gw.customer.alter.net [152.179.72.122]
      8   126 ms   123 ms   121 ms  so-10-1-0.dub40.ip4.tinet.net [89.149.186.193]
      9   137 ms   145 ms   136 ms  amazon-gw.ip4.tinet.net [141.136.96.138]
     10   137 ms   139 ms   137 ms  178.236.0.200
     11   134 ms   133 ms   134 ms  178.236.0.221
     12   138 ms   138 ms   143 ms  ec2-79-125-1-103.eu-west-1.compute.amazonaws.com [79.125.1.103]
     13     *        *        *     Request timed out.
     14     *        *        *     Request timed out.
     15     *        *        *     Request timed out.
     16     *        *        *     Request timed out.
     17     *        *        *     Request timed out.
     18     *        *        *     Request timed out.
     19     *        *        *     Request timed out.
     20     *        *        *     Request timed out.
     21     *        *        *     Request timed out.
     22     *        *        *     Request timed out.
     23     *        *        *     Request timed out.
     24     *        *        *     Request timed out.
     25     *        *        *     Request timed out.
     26     *        *        *     Request timed out.
     27     *        *        *     Request timed out.
     28     *        *        *     Request timed out.
     29     *        *        *     Request timed out.
     30     *        *        *     Request timed out.

    Trace complete.


    So, what do you think?

  • Avatar
    rotblitz

    Most services today do no longer respond to IMCP packets used by traceroute and ping to prevent from DDoS attacks.  No reason to be concerned if these tools do not reach the final destination unless you're sure they should respond (like the OpenDNS resolver addresses).  You do not use sessionless and portless ICMP when visiting websites or sending DNS queries, but TCP, session based, and UDP, both over dedicated ports.  So the diagnostic value of ICMP tools like traceroute and ping is rather limited.

    The rest looks fine.  You're directing your DNS queries from the computer to your ."Broadcom.Home" router at 192.168.1.1.  You're using the OpenDNS NY location.  Your IP address 96.246.112.188 is registered with OpenDNS network ID 1232070 which is hopefully yours.  So you should be fine with everything.

    Btw, regarding your command script, there are better tools for your purposes:
    https://support.opendns.com/entries/21841580-Diagnostic-Tool-Link

  • Avatar
    glnz

    Rotblitz - thanks, and interesting.  Ran the tool.  Things look good (I think) except for a few possibly bad results copied below.  (If you have a private message link, I can send you the full link, which seems to contain some identifying information.)

    What may have happened a few days ago was a coincidence of the OpenDNS problem that Matt and you have fixed AND an ongoing degradation of my Verizon DSL service here in NYC.  The last few days, speedtest.net tests to various local test servers don't always complete, and the Pings are erratic, with or without OpenDNS in my modem-router.  For all I know, it might be my modem-router.

    Here are the questionable portions of the results -

    Results for: nslookup -timeout=10 whoami.akamai.net. ns1-1.akamaitech.net
    stdout:
    Server:  UnKnown
    Address:  193.108.88.1
    Name:    whoami.akamai.net
    Address:  96.246.112.188
    
    stderr:
    *** Can't find server name for address 193.108.88.1: Query refused

     

    Results for: nslookup -timeout=10 -class=chaos -type=txt hostname.bind. 4.2.2.1
    stdout:
    Server:  a.resolvers.level3.net
    Address:  4.2.2.1
    
    stderr:
    *** a.resolvers.level3.net can't find hostname.bind.: Query refused

     

    Results for: nslookup -timeout=10 -class=chaos -type=txt hostname.bind. 192.33.4.12
    stdout:
    in-addr.arpa	nameserver = a.in-addr-servers.arpa
    in-addr.arpa	nameserver = c.in-addr-servers.arpa
    in-addr.arpa	nameserver = f.in-addr-servers.arpa
    in-addr.arpa	nameserver = e.in-addr-servers.arpa
    in-addr.arpa	nameserver = d.in-addr-servers.arpa
    in-addr.arpa	nameserver = b.in-addr-servers.arpa
    a.in-addr-servers.arpa	internet address = 199.212.0.73
    a.in-addr-servers.arpa	AAAA IPv6 address = 2001:500:13::73
    b.in-addr-servers.arpa	internet address = 199.253.183.183
    b.in-addr-servers.arpa	AAAA IPv6 address = 2001:500:87::87
    c.in-addr-servers.arpa	internet address = 196.216.169.10
    c.in-addr-servers.arpa	AAAA IPv6 address = 2001:43f8:110::10
    d.in-addr-servers.arpa	internet address = 200.10.60.53
    d.in-addr-servers.arpa	AAAA IPv6 address = 2001:13c7:7010::53
    e.in-addr-servers.arpa	internet address = 203.119.86.101
    e.in-addr-servers.arpa	AAAA IPv6 address = 2001:dd8:6::101
    f.in-addr-servers.arpa	internet address = 193.0.9.1
    f.in-addr-servers.arpa	AAAA IPv6 address = 2001:67c:e0::1
    Server:  UnKnown
    Address:  192.33.4.12
    hostname.bind	text =
    	"jfk1a.c.root-servers.org"
    hostname.bind	nameserver = hostname.bind
    
    stderr:
    *** Can't find server name for address 192.33.4.12: No information

     

    Failed Results for: http://67.215.69.69
    <!DOCTYPE html>
    <html>
    <head>
    <title>Error 401</title>
    <style>
    
        body {
            width: 35em;
            margin: 0 auto;
            font-family: Tahoma, Verdana, Arial, sans-serif;
        }
        p {
            font-size: 16px;
            line-height: 20px;
        }
        #wrap {
            text-align: center;
        }
        #umbrella-logo {
            display: inline-block;
            width: 207px;
            height: 0px;
            padding-top: 64px;
            border: 0;
            background-image: url(http://www-files.opendns.com/img/logo-umbrella.svg);
            background-position: top;
            background-size: 207px 64px;
            overflow: hidden;
        }
      
    </style>
    </head>
    <body>
        <div id="wrap">
          <a href="http://www.umbrella.com" rel="nofollow" id="umbrella-logo">Umbrella</a>
          <h1>Authorization Required</h1>
        </div>
        <p>If you are an Umbrella customer and are seeing this message in error, please open a support ticket at <a href="http://support.opendns.com/">support.opendns.com</a>.</p>
        <hr>
        <pre>This page served by Umbrella Cloud Security Gateway. Server: ash16</pre>
    </body>
    </html>

     

    Thanks.

  • Avatar
    rotblitz

    This looks all pretty good.  No new insights.  Are you still having problems?

    "the questionable portions of the results"

    *** Can't find server name for address 193.108.88.1: Query refused
    *** Can't find server name for address 192.33.4.12: No information

    These resolver addresses don't have PTR records (for reverse DNS)  assigned.  No problem.

    *** a.resolvers.level3.net can't find hostname.bind.: Query refused

    Level-3 refuse such special DNS queries from your IP address for whatever reasons.  They may have blacklisted your ISP's address range, maybe they have seen too many DNS Amplification Attacks from your subnet.  It works for me.

    "Failed Results for: http://67.215.69.69"

    As the HTML source shows, this page is apparently for Umbrella users, but it shows the server being used:
    This page served by Umbrella Cloud Security Gateway. Server: ash16
    It looks clearer if you visit http://67.215.69.69/ directly - so no problem either.

  • Avatar
    rotblitz

    "If you have a private message link, I can send you the full link"

    This would not help.  These URLs can only be visited by staff who need to login.  You therefore could post the link even here in case staff steps by.

    "the OpenDNS problem that Matt and you have fixed"

    Oops, I can't fix anything at OpenDNS.  I'm a user like you.  However, I'm ICT expert since decades...   ;-)

  • Avatar
    glnz

    Rotblitz - thanks again.

    The GNC Steve Gibson DNS benchmark tool is very interesting, at https://www.grc.com/dns/benchmark.htm.  (I forget how I landed there.) 

    It notes that my PC is using a single DNS nameserver, which is my modem-router 192.168.1.1.  That's because I have OpenDNS in my modem-router, not my PC.  But he is indicating life might be faster if I did the opposite - "System nameserver is SLOWER than 17 public alternatives!"

    Of course, I like OpenDNS for a variety of reasons, including increased security.  But I could put it in our devices rather than the modem-router (unless the modem-router would then force us all onto Verizon's DNS nameservers).

    What do you think?

  • Avatar
    rotblitz

    "It notes that my PC is using a single DNS nameserver, which is my modem-router 192.168.1.1.  That's because I have OpenDNS in my modem-router, not my PC."

    Exactly this is the reason.  It has to be this way in your case.  Not every message of this tool needs to be considered too seriously.

    "But he is indicating life might be faster if I did the opposite - "System nameserver is SLOWER than 17 public alternatives!""

    This may indicate that your router is a lousy DNS server/forwarder, as some routers are.  You really may gain on (DNS) speed and performance if you configured the OpenDNS resolver addresses (also) on the end user devices, thereby circumventing the router's lousy DNS functionality.

    "unless the modem-router would then force us all onto Verizon's DNS nameservers"

    No, this cannot happen if it works now.

Please sign in to leave a comment.