DNS servers unreachable

[#1]

Have you any objection to Plusnet ( @Kelly )  posting up a list of your IPs with times over the last month, might jog memories?

Is it a fair statement that an IP address which you rate as OK never became not-OK without an associated line drop and change of IP?

[#2]

No, I don't mind. However, although the router log goes back several months, not all categories of event are kept for that long. The info that I've managed to glean from the log is posted above. One useful piece of information would be the exact date that I raised the original ticket and the IP address at that time - that would give one more failing address.

[#3]

You should be able to find and check tickets raised yourself by going to https://www.plus.net/wizard/?p=search, choosing a suitable date range in the Closed Questions range selector, then clicking Go. In the resulting list Tickets/Questions will be described as such with numbers starting with 1....

Obviously that wouldn't give you the IP but Plusnet might be able to find it.

[#4]

Ticket: 171928376 was raised on 06/04/18 07:52 and your ip at the time was 80.189.200.169

[#5]

@McT I've pm'd you a csv.  You'll need to make a text file from it and open in excel, but it should give you what you need

[#6]

---

@McT wrote:

What is the lease time for an IP address? It doesn't seem to change with every reconnect or router restart - I've had 80.189.200.135 for 13 days.

---

@McT When others have needed to force an IP change to bypass incorrect geolocation data, turning the router off for 65 minutes has been suggested. Hopefully if you try that you'd get  a better behaved IP.

[#7]

---

@Kelly wrote:

Ticket: 171928376 was raised on 06/04/18 07:52 and your ip at the time was 80.189.200.169

---

Thanks. So that's one more bad address, also in the range 80.189.200.xxx. BT/Plusnet need to check forward and return UDP routing between this range and, for instance, 213.120.234.42.

[#8]

---

@Kelly wrote:

@McT I've pm'd you a csv.  You'll need to make a text file from it and open in excel, but it should give you what you need

---

Thank you. There is only one other 80.189.200.xxx address in the list, but it was active for only 8 minutes and I don't know whether the error existed during that period.

[#9]

---

@spraxyt wrote:

---

---

@McT When others have needed to force an IP change to bypass incorrect geolocation data, turning the router off for 65 minutes has been suggested. Hopefully if you try that you'd get  a better behaved IP.

---

Yes, that's a work-around, but it's not a fix.

[#10]

I agree it isn't a fix, I answered your question and thought of it as means to allow normal usage to continue whilst the troublesome IP range problem was worked on. Earlier in the thread you urged this be investigated by someone who understood the routing issues - I assure that is now the case.

[#11]

---

@spraxyt wrote:

 Earlier in the thread you urged this be investigated by someone who understood the routing issues - I assure that is now the case.

---

Good. There are countless reports of similar problems in this forum and others - usually circumvented by configuring a different DNS server, rebooting the router to get a new IP address, or in some cases by acquiring a static IP address - but never fixed by resolving the underlying problem. The one example I found, after comprehensive searching, in which the root cause was discovered, was a situation whereby BT supplied VPN software recognised a particular IP address range as internal to BT, but the range had later been released for general use in the Internet.

[#12]

I should add that in the case mentioned above, although the cause was discovered it was never actually fixed! The reason being that the VPN software in question had been around for years and was no longer in development.

[#13]

What's the real problem here ... what is it that gives rise to so much concern over if the DNS server does or does not respond to pings?

Responding to pings is a low priority network function, might well be ignored if a device is busy ... or simply might be ignored completely if the device so wishes - there is no obligation for a server to respond to pings.

In the case of a DNS server, if it is responding to DNS lookup requests, then what's the concern?

PS C:\Users\Me> ping 213.120.234.42

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

Ping statistics for 213.120.234.42:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
PS C:\Users\Me> nslookup
Default Server:  ZyXEL.Home
Address:  192.168.1.1

> server 213.120.234.42
Default Server:  indnsc92.ukcore.bt.net
Address:  213.120.234.42

> google.co.uk
Server:  indnsc92.ukcore.bt.net
Address:  213.120.234.42

Non-authoritative answer:
Name:    google.co.uk
Addresses:  2a00:1450:4009:809::2003
          216.58.204.67

>

The above was performed on a ZyXEL router, giving the same results as reported on the PN router herein ... so long as DNS look ups are responded to, not responding to pings is I suggest neither here nor there.

Do you have evidence of DNS look ups (not pings) not being serviced by the safeguard DNS servers?

The one example I found, after comprehensive searching, in which the root cause was discovered, was a situation whereby BT supplied VPN software recognised a particular IP address range as internal to BT, but the range had later been released for general use in the Internet

Indeed there have been reports of out of date VPN software not behaving correctly on some IP ranges ... will see if I can find that topic for you.  IIRC that had nothing to do with DNS servers.

[#14]

See https://community.plus.net/t5/Broadband/VPN-fine-for-9-months-stopped-working-Jan/m-p/1301072#M30229... - suspect that this specific case might have been circumvented by applying a fixed IP address.  Read on though there are a lot of examples.

It is a long topic and I do recall that (to name but one company) the Coop had a lot of issues and steadfastly refused to address the root cause by updating their VPN software.

[#15]

@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?