DNS servers unreachable

[#1]

---

@Townman wrote: What's the real problem here ...

I realise that this is a long thread, but pings are not the problem. I did make a comment in an earlier post that because many nodes are configured to ignore ping and tracert ICMP packets, these tools have become less useful as diagnostic aids.

To recap: When an IP address in a certain range (which may be 80.189.200.xxx) has been allocated to the line, DNS lookups to the DNS servers configured in the router timeout, while requests to other DNS servers succeed. UDP connection to a VPN server also fails.

[#2]

---

@Kelly wrote:

@McT I believe you've reported an issue with your VPN software.  Ignoring the lack of response to traces/pings, is there any other impacts of this issue?

---

I have not reported an issue with VPN software. I have reported a UDP routing problem which affects DNS requests and VPN connections. (And maybe other things for all I know.)

I mentioned the BTMX (BT Mobile Express VPN) problem as an example of how a routing problem can affect some IP address and not others and of the fact that BT and Plusnet prefer to resolve such problems by changing IP addresses or DNS server configuration rather than fix the underlying problem. (And yes, the Co-op could have replaced their VPN software, but BT could have produced a patch to fix it!)

[#3]

I'm trying to determine if you are seeing a problem with an application running on the line, or if just the tests themselves fail (because they may be being dropped/slowed/low priority on the network)

[#4]

@Kelly Again, I know this is a long thread, but have you read it?

This is now an intermittent problem, dependent on the IP address allocated. When the problem is there, I can't access any websites, because DNS requests fail. I can't initiate a VPN connection over UDP. I can't connect from outside back to my own VPN server because the DDNS feature of the router fails. I can't use the smart features of my TV because it will always try to use the default DNS servers.

@spraxyt You said earlier that someone who understands routing issues is now looking at this................

[#5]

@McT someone who understands routing issues *is* looking into this (though let's not forget routing failures might be a symptom, rather than the cause of the problem). Unfortunately there is too much diagnostic information in this topic which is confusing the issue. Ignoring tracert, ping and VPN experiences which are irrelevant I believe the issue boils down to using the safeguard DNS to look up IPs of well known websites, eg

nslookup bbc.co.uk 213.120.234.42
or
nslookup ibm.com 213,120,234,42

does not resolve from IPs in the range 80.189.200.xxx (because queries timeout)

---

@McT wrote:

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

---

but does resolve using the normal caching DNS

---

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

---

@Kelly It is this which needs to be looked into, other mentions in this topic are best ignored.

[#6]

DNS lookups to the DNS servers configured in the router timeout

This has been seen with the not safeguarded DNS servers as well - but it is never there when taking a diagnostic look.

Are these time outs intermittent or do ALL queries fail?  What PC OS is involved?

@Kelly - we've raised non-specific reservations about DNS mishaps before - yes it is like a needle in a haystack.  Can you suggest any diagnostics we might run here please?

[#7]

@spraxyt You're quite right, there is more info here than required, I was just trying to be thorough.

@Townman The major impact of the problem is the failure of DNS resolution, but I believe the underlying problem is UDP routing. I use NordVPN and when the problem is there I cannot connect to any NordVPN server over UDP, but I can connect to the same server IP addresses over TCP.

When a "bad" IP address is allocated, the problem is consistent. It happens with Windows 10, Android 7, and iOS 9 and also when another router was substituted for the Plusnet Hub One.

[#8]

I did look through the thread to find if there was any actual impact beyond just the tests failing, but couldn't spot it in there.  I was skimming quickly though.

@bobpullen @Gandalf Worth raising an incident and talking to Dave/Adam about this.

[#9]

@Kelly @bobpullen

For IPs in the 80.189.200.xxx range using safeguard DNS I think the point is that

• nslookup failing implies UDP lookups are failing
• normal DNS lookups use UDP but fall back to the higher overhead TCP if UDP fails.
• TCP connections work so normal usage does not generate complaints
• however each lookup carried out will take longer, increase network traffic and the load on the DNS server
• users on that range will therefore experience more sluggish Internet usage

Any application exclusively using UDP is likely to fail. One could argue the application should fall back to TCP but this system currently is broken (and I doubt Microsoft will be implementing TCP fallback with the diagnostic tool nslookup anytime soon).

[#10]

@McT Well over a week has passed since the last Plusnet response in this topic which should have lead to Incident Management Team notification and an investigation. Is the problem still present?

[#11]

I've got an incident raised for this: IMT-2012.  

[#12]

---

@spraxyt wrote:

@McT Is the problem still present?

Not at the moment, but I expect it would return if an IP address in the 'bad' range was allocated.

---

[#13]

New IP address assigned yesterday: [Removed]

Problem has returned.

How difficult can it be to set up a device within Plusnet's network with an address in the 80.189.200.xxx range and to put a sniffer on it? "Not at all" is the answer and yet eight weeks after reporting this problem I see no sign whatsoever of Plusnet performing any useful investigation. What will it take to get this fixed?

I am certain that there must be other people experiencing this same problem, but it never gets investigated because at some point during the initial testing they are told to reboot the router, a new address is assigned and the problem is "fixed".

Moderator's note by Mike (Mav): IP address removed from a public forum (to an area that staff can see).

[#14]

Thanks for the post. I've raised a second escalation on this to raise its profile. As mentioned a few posts ago incident IMT-2012 was raised on 22/05/2018 for investigation. Unfortunately I suspect you are right that the issue is being treated as low priority.

[#15]

It's still on my radar and I'm pushing for some replication.