Plusnet DNS Intermittent faults

[#1]

My problem "vanished" @ about 5:30 last evening -looking at the router logs I had a whole series of "dns probe {8812} : dns query failed " lines from early afternoon til then, regardless of whether I was on PN DNS or Google.
Also it appears as if the internet went down totally mid afternoon -altho' the router didn't lose synch as far as I can tell. Either a local exchange problem or PN gateway problem?
Actually seems to be running faster this am -at least in terms of web page loading!

[#2]

Service: Broadband Posted: Wed, Oct 16 2013 at 23:13:22 Subject: Broadband connection problems (77524/41569) - RESOLVED
This is an update to this afternoon's post about the difficulty some broadband customers may be having connecting to the Internet.
Our suppliers have resolved the issue causing connection problems. This was due to a hardware problem that has now been resolved.
Apologies for the continued inconvenience.
Kind regards,
Chris Parr Customer Support.

[#3]

Currently everything is back working again so hopefuly a dodgy piece of hardware somewhere along the line (not belonging to me) was causing the intermeittent faults.

[#4]

Rather than use ping or tracert to report these issues you need to use nslookup directing the lookup to particular servers. E.g.

C:\Users\John>nslookup bbc.co.uk 212.159.6.9
Server:  cdns01.plus.net
Address:  212.159.6.9
Non-authoritative answer:
Name:    bbc.co.uk
Addresses:  212.58.251.195
          212.58.253.67

C:\Users\John>nslookup bbc.co.uk 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8
Non-authoritative answer:
Name:    bbc.co.uk
Addresses:  212.58.251.195
          212.58.253.67

C:\Users\John>nslookup bbc.co.uk 208.67.222.222
Server:  resolver1.opendns.com
Address:  208.67.222.222
Non-authoritative answer:
Name:    bbc.co.uk.cieh.org
Address:  67.215.65.132

[#5]

The nameserver response times 30FTTC06 and I both posted were from a handy little utility called ns_bench. Check it out! Quick to use, easy to interpret and good for comparisons.
(Just watch out for the fact that it may run a tad slower in Windows because the exe is compiled for Cygwin, so the absolute numbers may be reported as a couple of ms higher than is really the case. Since change is generally what you're looking for, that isn't normally a problem. For an accurate absolute benchmark it is better to run it under Linux, however.)
All the nslookups have told you is the ip addresses for a particular name.
I suppose if the lookup failed, that might give you some extra information, but most lookups to PlusNet servers won't fail to get any response unless things are really bad (as they were quite recently for a short time) - you can see there are no retries in the figures we posted.

[#6]

Sometimes all you need to know is whether it's working properly or not, not which DNS server is 2ms faster than another.

Quote from: jelv

Server:  resolver1.opendns.com Address:  208.67.222.222 Non-authoritative answer: Name:    bbc.co.uk.cieh.org Address:  67.215.65.132

I expect that weird result from OpenDNS was due to the typo, but DNS benchmarks don't seem to take into account that different DNS servers can give you different answers for the same address.

[#7]

Horses for courses, really.
A particular tool doesn't have to be used to find out

Quote from: ejs

which DNS server is 2ms faster than another.

It's what you do with, and understand by, the information you glean which counts.

[#8]

It's not working correclty again, same intermittent problem
[tt]C:\Users\Steven>nslookup 212.159.6.9
Server:  UnKnown
Address:  192.168.2.1
*** UnKnown can't find 212.159.6.9: Server failed
C:\Users\Steven>nslookup 212.159.6.10
Server:  UnKnown
Address:  192.168.2.1
*** UnKnown can't find 212.159.6.10: Server failed
C:\Users\Steven>tracert cdns02.plus.net
Unable to resolve target system name cdns02.plus.net.
C:\Users\Steven>ping cdns02.plus.net
Ping request could not find host cdns02.plus.net. Please check the name and try again.
C:\Users\Steven>tracert cdns01.plus.net
Unable to resolve target system name cdns01.plus.net.
C:\Users\Steven>ping cdns01.plus.net
Ping request could not find host cdns01.plus.net. Please check the name and try again.
[/tt]
Yet a few seconds later its all working again, then 10 secs and its gone again.
I have used ping, tracert and nslookup on a number of sites and servers and its that same story. One minute everything is fine, then next its gone again. If i switch the router over to google dns it all works instantly. Same problem on 4 different devices with 2 different routers.

[#9]

All of those nslookups and tracerts tell us exactly the same thing: DNS lookups are failing on your router. We can't tell if it's a router problem or if the router couldn't get an answer from the Plusnet DNS.
Next time it fails try
nslookup bbc.co.uk 212.159.6.9
That will make the PC do the lookup directly on the Plusnet DNS server 212.159.6.9, bypassing the DNS on the router.

[#10]

I already ran nslookup bbc.co.uk 212.159.6.9 and that either works normally or fails, the same as the others.
it is currently working more than it isnt so it's difficult to detect what is and isnt working. If I use nslookup on a site with the bypass in place and it fails than I tracert or ping the domain or IP it has normally kicked back in again. I can have a tracert fail followed by a successful nslookup. If it was just not working in a steady manner then I could get a stable set of results.

[#11]

Note that cdns01.plus.net and cdns02.plus.net do not resolve to the IP addresses of the DNS servers. You only get the answer of cdns01.plus.net when you do a reverse lookup on the 212.159.6.9 IP address. So "ping cdns01.plus.net"  and "tracert cdns02.plus.net" will always fail. You can ping or tracert ntp.plus.net (which will pick any 1 of the 4 DNS server IP addresses).

[#12]

Quote from: Tensulp

If I use nslookup on a site with the bypass in place and it fails than I tracert or ping the domain or IP it has normally kicked back in again. I can have a tracert fail followed by a successful nslookup. If it was just not working in a steady manner then I could get a stable set of results.

Perhaps the sync is dropping, but not long enough to lose the PPP session?
Feel free to ignore the suggestion if it doesn't meet your needs, but if you were to consider ns_bench worth installing, a single command line

ns_bench 212.159.6.9 212.159.6.10 212.159.13.49 212.159.13.50 192.168.2.1

will allow you to test more at once.
It sends 10 asynchronous requests for google.com to all of PlusNet's servers and your router. If the PlusNet servers fail, then they likely can't be reached for whatever reason. If only the router fails then the issue is more likely to be there. If you put the router last on the list, there is less chance of the problem resolving during the time it takes to time out before the PlusNet servers are tested. You can remove from the list whichever two PlusNet servers the router isn't configured to use. This method will also show up extreme variability or transient failures between the 10 requests (if there are any).
It's just a quicker way of doing things which gives you more information. There are plenty of other ways, though. This isn't a test which concerns itself with the actual IP address returned for the name requested.
Use if helpful; disregard if not. It's only information.
If the PlusNet servers are timing out when you test, then move on to look at sync loss and other things. You will need different tools for that.

[#13]

@Tensulp
It doesn't seem that your connection has been dropping unless it is that quick we haven't managed to pick this up, I'd be surprised though if it continually missed your disconnections.
<img src="http://community.plus.net/visualradius/generated/image13823538396426.png"/>

[#14]

Quote from: chrispurvey

I'd be surprised though if it continually missed your disconnections.

I wouldn't be at all surprised. When I was having trouble with losing sync on an incoming call it was resyncing within 15seconds. Not one of the events appeared in the radius log - but they all appeared in the event log on the router and when I finally convinced Plusnet to look in the right place were visible to them as well.

[#15]

There was your case, it is uncommon for them to be missed though.
I've checked from BT wholesales' stats and that also is showing no drops, although that would be sync drops and not PPP sessions.