DNS servers unreachable

[#1]

The DNS servers coded (unchangeably!) in the Plusnet Hub are unreachable - which is a real pita. I can override the setting in laptops and phones, but not in the TV. I reported this to customer service 9 days ago and supplied a tracert of the failure, but at the last communication they were talking about sending an engineer out so I'm not filled with confidence that they understand the problem.


C:\>tracert 213.120.234.42

Tracing route to indnsc92.ukcore.bt.net [213.120.234.42]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  PNHUB1 [192.168.11.11]
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     8 ms     8 ms    16 ms  172.17.2.165
  5    10 ms     9 ms     9 ms  172.17.10.34
  6     9 ms     9 ms     9 ms  be2.pcn-ir01.plus.net [195.166.129.164]
  7    11 ms    14 ms    10 ms  195.99.125.136
  8    10 ms    10 ms    10 ms  109.159.252.134
  9    10 ms    10 ms    20 ms  host213-121-192-65.ukcore.bt.net [213.121.192.65]
 10  host213-121-192-65.ukcore.bt.net [213.121.192.65]  reports: Destination net unreachable.

Trace complete.

Does anyone else have this problem?

[#2]

All I can say is I have had several apparent DNS failures the last couple of days.

[#3]

Yes, I get the same here and I think now you mention it, I am having similar problems with the TV.

C:\Users\Harry>tracert 213.120.234.42

Tracing route to indnsc92.ukcore.bt.net [213.120.234.42]
over a maximum of 30 hops:

  1     3 ms    17 ms     2 ms  READYSHARE [10.131.97.173]
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4    73 ms    54 ms    27 ms  be3-3100.pcn-ir01.plus.net [195.166.143.128]
  5    26 ms    71 ms    23 ms  195.99.125.136
  6    35 ms    35 ms    86 ms  109.159.252.138
  7    37 ms    25 ms    49 ms  host213-121-192-61.ukcore.bt.net [213.121.192.61]
  8  host213-121-192-61.ukcore.bt.net [213.121.192.61]  reports: Destination net unreachable.

Trace complete.

[#4]

Thank you Harry for confirming that it's not just me

I suspect that there is a routing table error, or a route that is down, in BT's network. This error can also occur if there is no return route to the source address from the reporting node (see uRPF). I remember seeing a post somewhere that mentioned certain BT IP address ranges having routing problems.

[#5]

ping works fine..

Pinging 213.121.192.61 with 32 bytes of data:
Reply from 213.121.192.61: bytes=32 time=23ms TTL=249
Reply from 213.121.192.61: bytes=32 time=26ms TTL=249
Reply from 213.121.192.61: bytes=32 time=25ms TTL=249
Reply from 213.121.192.61: bytes=32 time=21ms TTL=249

Ping statistics for 213.121.192.61:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 21ms, Maximum = 26ms, Average = 23ms

[#6]

I'm not sure a traceroute is relevant if the servers still respond to DNS queries. Has a traceroute ever completed for you?

Windows traceroute uses ICMP. DNS queries are served using UDP. Are you able to query the servers and get a response using nslookup?

> nslookup bbc.co.uk 213.120.234.42

If so, the server is responsive.

What are the symptoms of the problems you're encountering?

[#7]

C:\Users\Harry>nslookup bbc.co.uk 213.120.234.42
Server:  indnsc92.bt.net
Address:  213.120.234.42

Non-authoritative answer:
Name:    bbc.co.uk
Addresses:  2a04:4e42:600::81
          2a04:4e42:200::81
          2a04:4e42:400::81
          2a04:4e42::81
          151.101.0.81
          151.101.128.81
          151.101.192.81
          151.101.64.81

[#8]

My Plusnet Hub router is configured with the addresses of two "Safeguard" DNS servers (which I cannot change):

213.120.234.42    
213.120.234.38

Ping, tracert and nslookup all fail to both these servers.

Ping, tracert and nslookup all succeed to both of the "normal" Plusnet servers:

212.159.6.9
212.159.6.10

C:\>nslookup ibm.com 213.120.234.42
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  213.120.234.42

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

C:\>ping 213.120.234.42

Pinging 213.120.234.42 with 32 bytes of data:
Reply from 213.121.192.65: Destination net unreachable.
Request timed out.
Request timed out.
Reply from 213.121.192.65: Destination net unreachable.

Ping statistics for 213.120.234.42:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),


C:\>nslookup ibm.com 212.159.6.9
Server:  cdns01.plus.net
Address:  212.159.6.9

Non-authoritative answer:
Name:    ibm.com
Address:  129.42.38.10


C:\>tracert 212.159.6.9

Tracing route to cdns01.plus.net [212.159.6.9]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  PNHUB1 [192.168.11.11]
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     9 ms     8 ms     8 ms  172.17.2.165
  5    10 ms     9 ms     9 ms  172.17.10.34
  6     9 ms     9 ms     9 ms  be2.pcn-ir01.plus.net [195.166.129.164]
  7     9 ms     9 ms     9 ms  cdns01.plus.net [212.159.6.9]

Trace complete.

There are dozens of similar reports regarding BT and Plusnet DNS servers over the last couple of years. All seem to be resolved by using a different DNS server (usually Google servers) by reconfiguring the router, where that is possible, or the device connected to it. I could find no evidence of Plusnet ever coming clean and admitting to a DNS server problem.

It is now 10 days since I reported this problem. I supplied a failed tracert to 213.120.234.42 and a successful tracert to 212.159.6.9 on day one and I have had nothing back from customer service. This isn't good enough, especially when it is not possible to change the DNS configuration in the supplied router.

@harrym1byt Your ping was to the node reporting "Destination net unreachable", not the DNS server.

[#9]

Assuming you haven't done this already, can you try a factory reset of your router using the pinhole at the back?

[#10]

The plot thickens..........

---

My initial reaction to the above was: "Don't be daft, how can a router affect an unreachable destination 9 hops downstream?"

I had forgotten, since retiring many years ago after nearly 30 years as a network engineer with IBM, that the weirdest of problems are frequently the result of more than one issue. It appears that one of those issues in this case is the fact that some organisations disable responses to ICMP packets. I suspect that the usefulness of tracert and ping as diagnostic tools is diminishing.

So I did a factory reset on the router and to my surprise an nslookup worked, but only briefly. After the reset the situation was:

213.120.234.42 and 213.120.234.38

ping and tracert fail consistently, nslookup fails intermittently (within a few seconds of a successful request another may fail and vice versa)

212.159.6.9 and 212.159.6.10

ping, tracert and nslookup succeed every time

So what was a solid error has become an intermittent error plus a red herring, but it does look like the router, if not the culprit, is certainly a suspect. To that end I have now installed another router, which appears to function correctly, and I await developments. Unfortunately, the only suitable spare router to hand also glibly accepts whatever DNS servers the ISP sends, with no opportunity to change them.

I have another thread open, which describes a problem connecting via UDP to a VPN server, although using TCP works OK. That issue also appears to have been resolved by the router reset. The common element here is UDP. What process in the router could prevent UDP connections to IP address A, but not to IP address B?

If the substitute router behaves over the next few days, I'll assume the router was the problem and request a new one.

Moderator's note by Mike (Mav): Post released from Spam Filter.

Moderator's note by Mike (Mav): Full quote of preceding post removed as per Forum rules.

[#11]

Update:

After substituting another router, DNS lookups worked OK until half an hour ago, when the problem returned in its original, solid, form. Lookups to 213.120.234.42 and 213.120.234.38 time-out and the VPN over UDP can't connect. Lookups to 212.159.6.9 and 212.159.6.10 are fine, as is VPN over TCP. Same symptoms with a laptop and an Android phone.

Rebooting the router resolved the problem, but I don't expect it to last. As I've tested with different devices and different makes of router the problem has to be the network, but why rebooting the router should temporarily clear the error, I don't know. The only thing I can think of is that the IP address changed, which may affect the routing. I've made a note of it this time.

The icing on the cake is that pulling the plug on the DSL connection and messing with different routers has dropped my sync speed by 13Mbps. Great.

Will DLM eventually restore the original speed?

[#12]

Will DLM eventually restore the original speed?

Send me a PM with your username and I'll check this for you.

[#13]

Will DLM eventually restore the original speed?

DLM hasn't banded your line:

Profile Name

0.128M-80M Downstream, Retransmission High - 0.128M-20M Upstream, Error Protection Off

 In addition your router is in sync at fantastic speed:

Sync Status	In Sync
Downstream Speed	77.0 Mbps
Upstream Speed	17.6 Mbps

[#14]

Moderator's note:

Thread moved from Broadband to Everything Else.

[#15]

Yes, downstream sync back to 77Mbps.

Just waiting now to see if the DNS/UDP problem returns.