Plusnet DNS up-the-creek AGAIN?

[#1]

Pinging ntp.plus.net [198.18.1.89] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 198.18.1.89:
   Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Initially spotted around 2110 seemed to recover around 2125.
Gateway ptw-ag03 20CN.

[#2]

Are you using the correct DNS address?
Primary DNS: 212.159.6.10
Secondary DNS: 212.159.6.9

Here is my ping to ntp.plus.net
Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. All rights reserved.
C:\Windows\system32>ping ntp.plus.net
Pinging ntp.plus.net [212.159.6.10] with 32 bytes of data:
Reply from 212.159.6.10: bytes=32 time=32ms TTL=250
Reply from 212.159.6.10: bytes=32 time=8ms TTL=250
Reply from 212.159.6.10: bytes=32 time=14ms TTL=250
Reply from 212.159.6.10: bytes=32 time=10ms TTL=250
Ping statistics for 212.159.6.10:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 8ms, Maximum = 32ms, Average = 16ms
C:\Windows\system32>

[#3]

By recover, I mean started working again with ping output similar to yours
>ping ntp.plus.net
Pinging ntp.plus.net [212.159.6.9] with 32 bytes of data:
Reply from 212.159.6.9: bytes=32 time=35ms TTL=250
Reply from 212.159.6.9: bytes=32 time=35ms TTL=250
Reply from 212.159.6.9: bytes=32 time=36ms TTL=250
Reply from 212.159.6.9: bytes=32 time=38ms TTL=250
Ping statistics for 212.159.6.9:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 35ms, Maximum = 38ms, Average = 36ms

[#4]

I'm curious how you got 198.18.1.89 as your DNS resolver, it doesn't appear to be assigned to PlusNET (it's a test IP) and it's not routed anywhere by the looks of it

Quote

Comment:        This block has been allocated for use in Comment:        benchmark tests of network interconnect Comment:        devices. This range was assigned to                     Comment:        minimize the chance of conflict in case a Comment:        testing device were to be accidentally Comment:        connected to part of the Internet. Comment:        Packets with source addresses from Comment:        this range are not meant to be forwarded                     Comment:        across the Internet.

# host ntp.plus.net
ntp.plus.net has address 212.159.13.49
ntp.plus.net has address 212.159.13.50
ntp.plus.net has address 212.159.6.9
ntp.plus.net has address 212.159.6.10

Can't see any sign of that IP showing up

[#5]

The question here being why is ntp.plus.net resolving to 198.18.1.89 rather than not responding to a ping?
It's listed as 'SPECIAL-IPV4-BENCHMARK-TESTING-IANA-RESERVED'
with a purpose of
'use in benchmark tests of network interconnect devices. This range was assigned to minimize the chance of conflict in case a  testing device were to be accidentally connected to part of the Internet. Packets with source addresses from this range are not meant to be forwarded across the Internet.'
Weird?

[#6]

Reply #2 the IP of ntp.plus.net resolved correct. I wonder if he has some malware that is changing his ip's? (Maybe something simple, but what???)
Perhaps Anotherone could comment?

[#7]

Quote from: Anotherone

Pinging ntp.plus.net [198.18.1.89] with 32 bytes of data:

The following cli command may (or may not) help us understand what's happening.
dns server debug spoof list
This is what my fibre TG852n gives:
Spoof IP          FQDN                        Real IP          Flags
198.18.1.1      ntp.plus.net                0.0.0.0          Not resolved

I'm not sure what the above is all about, but suspect IP's in the range 192.18.1.? are used by the router to redirect to internal web pages when the internet is down.
Don't know if the same IP's are used with different firmware versions. Not something I've paid much attention to.

[#8]

Thanks for that npr, as you can see I mentioned the 582n later in this post.
I certainly would comment shalom2010, yes or course I am using the correct DNS addresses.
ntp.plus.net resolved to that IP address when it was not resolving!
Using only Plusnet DNS during the times I mentioned, nothing was resolving at all and pings returned as per my OP.
Using another alternative DNS, everything was working fine. The times I quoted are only approximate as I was getting on with what I was doing and periodically adding and removing an alternate DNS to see if the Plusnet ones were back in action.
Try looking at the IP address returned in the event log in the 582n for synchronising with a time server. You'll find a similar IP address correctly returned for ntp.plus.net when there is no resolution, but with the relevant virtual IP address(es) for Plusnet's DNS - when Plusnet DNS is working! It has naff all to do with viruses or anything of the kind. Don't ask me to explain exactly the ins and outs - I thought exactly the same as houlton23 when I first encountered it, and if it's baffling npr as well, say no more. We'll have to get one of the Plusnet Network guys to give us the low down on that!
Edit: rephrase badly worded comment about synchronising with a time server above, and it may be worth adding for the sake of clarity as well that I have defined specific IP addresses for 2 time servers in my 582n (rather than a domain name), so this must be related to the spoofing when DNS does not resolve, and I don't get that similar IP address returned now for the time server.
I'm also editing my OP to add Gateway etc as this may have been a Gateway or Hostlink dependant problem if not everyone saw it.
(ptw-ag03 20CN).

[#9]

Or run your own resolver
I gave up on ISP's DNS resolvers years ago.

[#10]

Yes I've seen several of your posts etc about that  
I usually have alternate DNS set-up when I know the Plusnet ones are playing up, but I don't leave it set up otherwise I wouldn't spot when the Plusnet ones did go awol
Just called CSC to see if they knew anything - no guesses as to the answer!
Edit: oh and the phone system messages gave extremely bad advice about rebooting the router - something one should only do as a last resort and even then after doing a number of other checks first.

[#11]

Quote from: Anotherone

Just called CSC to see if they knew anything - no guesses as to the answer! Edit: oh and the phone system messages gave extremely bad advice about rebooting the router - something one should only do as a last resort and even then after doing a number of other checks first.

About the norm for the industry then
To be fair, I've only been here a few months, but I do find plusnet give better and more honest information than most ISP I've used.

[#12]

I'll give Matt a nudge tomorrow.  This is mysterious.

[#13]

Quote from: Anotherone

I usually have alternate DNS set-up when I know the Plusnet ones are playing up, but I don't leave it set up otherwise I wouldn't spot when the Plusnet ones did go awol

I don't know how enlightening it will be with regard to the 198.18.1.89 issue, but since I make a fuss when things aren't working as they should, I feel morally obliged to post that the DNS servers are working very well from here (ptn-ag03 21CN) this evening:
[tt]Nameserver              Response Time (ms) Over 10 Lookups of www.google.com
                          min        avg        max    stdev      retries
212.159.6.9              6.77      7.28      7.77      0.38      0
212.159.6.10            6.78      7.30      8.39      0.57      0
212.159.13.49            7.10      7.50      8.26      0.42      0
212.159.13.50            7.25      7.42      7.60      0.15      0
208.67.222.222          14.76      14.90      15.23      0.17      0
208.67.220.220          14.48      14.72      15.01      0.18      0
8.8.8.8                16.51      16.89      17.59      0.39      0
8.8.4.4                16.09      16.70      17.72      0.59      0
4.2.2.1                  6.72      7.13      7.61      0.31      0
4.2.2.6                  6.81      6.94      6.99      0.07      0
192.168.0.2              3.08      3.36      3.61      0.18      0
[/tt]

Hardly worth running the local resolver.

[tt]Pinging ntp.plus.net [212.159.6.9] with 32 bytes of data:
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Reply from 212.159.6.9: bytes=32 time=4ms TTL=250
Ping statistics for 212.159.6.9:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum =  4ms, Average =  4ms[/tt]


Can confirm that 198.18.1.89 is not reachable...

[#14]

@npr
Your TG582n must be broken 
------------------------------------------------------------------------
     |                 |           o             |
     |---  ,---. ,---. |---. ,---. . ,---. ,---. |     ,---. ,---.
     |     |---' |     |   | |   | | |     |   | |     |   | |
     `---' `---' `---' `   ' `   ' ` `---' `---' `---' `---' `

                 Technicolor TG582n FTTC
                   10.2.5.2.EO
                     Copyright (c) 1999-2012, Technicolor

------------------------------------------------------------------------
=>dns server debug spoof list
Spoof IP          FQDN                         Real IP          Flags
198.18.1.65      www.ign.com                  0.0.0.0          Not resolved
198.18.1.66      www.askmen.com               0.0.0.0          Not resolved
198.18.1.67      ajax.googleapis.com          0.0.0.0          Not resolved
198.18.1.68      www.pcmag.com                0.0.0.0          Not resolved
198.18.1.69      ajax.microsoft.com           0.0.0.0          Not resolved
198.18.1.70      www8.pcmag.com               0.0.0.0          Not resolved
198.18.1.71      www2.pcmag.com               0.0.0.0          Not resolved
198.18.1.72      www4.pcmag.com               0.0.0.0          Not resolved
198.18.1.73      www1.pcmag.com               0.0.0.0          Not resolved
198.18.1.74      common.ziffdavisinternet.com 0.0.0.0          Not resolved
198.18.1.75      ssl.gstatic.com              0.0.0.0          Not resolved
198.18.1.76      promos.mcafee.com            0.0.0.0          Not resolved
198.18.1.77      housecall.trendmicro.com     0.0.0.0          Not resolved
198.18.1.78      usertools.plus.net           0.0.0.0          Not resolved
198.18.1.79      books.google.co.uk           0.0.0.0          Not resolved
198.18.1.80      www.plus.net                 0.0.0.0          Not resolved
198.18.1.81      community.plus.net           0.0.0.0          Not resolved
198.18.1.82      ping.chartbeat.net           0.0.0.0          Not resolved
198.18.1.83      www.metoffice.gov.uk         0.0.0.0          Not resolved
198.18.1.84      sprites.pcpro.co.uk          0.0.0.0          Not resolved
198.18.1.85      content.dl-rms.com           0.0.0.0          Not resolved
198.18.1.86      www.google.com               0.0.0.0          Not resolved
198.18.1.87      w.sharethis.com              0.0.0.0          Not resolved
198.18.1.88      d3c3cq33003psk.cloudfront.net 0.0.0.0          Not resolved
198.18.1.89      ntp.plus.net                 0.0.0.0          Not resolved
198.18.1.90      bqm.alexhoulton.co.uk        0.0.0.0          Not resolved
198.18.1.59      www.appscout.com             0.0.0.0          Not resolved
198.18.1.60      www.extremetech.com          0.0.0.0          Not resolved
198.18.1.61      www.geek.com                 0.0.0.0          Not resolved
198.18.1.62      mobile.pcmag.com             0.0.0.0          Not resolved
198.18.1.63      blogs.pcmag.com              0.0.0.0          Not resolved
198.18.1.64      www.computershopper.com      0.0.0.0          Not resolved
=>exit

Quote from: houlton23

The question here being why is ntp.plus.net resolving to 198.18.1.89 ........... Weird?

198.18.1.90      bqm.alexhoulton.co.uk        0.0.0.0          Not resolved
Even weirder

[#15]

Quote from: Anotherone

198.18.1.90      bqm.alexhoulton.co.uk        0.0.0.0          Not resolved Even weirder

Shouldn't even be visible on the intarwebs, unless PN have accidentally left some test kit connected, maybe?
[tt]NetRange:      198.18.0.0 - 198.19.255.255
CIDR:          198.18.0.0/15
OriginAS:     
NetName:        SPECIAL-IPV4-BENCHMARK-TESTING-IANA-RESERVED
NetHandle:      NET-198-18-0-0-1
Parent:        NET-198-0-0-0-0
NetType:        IANA Special Use
Comment:        This block has been allocated for use in
Comment:        benchmark tests of network interconnect
Comment:        devices. This range was assigned to                   
Comment:        minimize the chance of conflict in case a
Comment:        testing device were to be accidentally
Comment:        connected to part of the Internet.
Comment:        Packets with source addresses from
Comment:        this range are not meant to be forwarded                   
Comment:        across the Internet.                   
Comment:        This assignment was made by the IETF in
Comment:        RFC 2544, which can be found at:
Comment:        http://www.rfc-editor.org/rfc/rfc2544.txt
RegDate:        1992-11-23
Updated:        2010-10-18
Ref:            http://whois.arin.net/rest/net/NET-198-18-0-0-1[/tt]