198.18.1.x address problems

[#1]

Thanks npr,
The first link makes very clear that the browser is doing its own caching - whilst I see the merit of the pre-fetch, local caching seems illogical.  It leads to duplication of caching and unexpected results.  The platform has already got DNS caching in the comms stack, so why duplicate it else where?
The second link goes nowhere.
Kevin

[#2]

You can disable prefetching in firefox, don't know about IE.
Very strange, the link works at this end. 

[#3]

Quote from: Townman

The second link goes nowhere.

Let me rephrase that - it goes to McAfee's site but to a page which says the content cannot be found.

[#4]

That is interesting
The first time I clicked on it I got the page saying you need to enable cookies and now it is page cannot be found

[#5]

This is what I see  

Update:
After clearing the browsers cache, re-trying the link gave me a page telling me how to enable cookies. 
I've temporarily  allowed third-party cookies and get the above screen capture web page again.

[#6]

Quote from: Townman

EDIT: @CRT see post 15 here - http://www.gpforums.co.nz/threads/478377-Windows-8-1-Upgrade-Ramifications - there is a suggestion there that there is a specific issue between Win8 and TGs See also posts here - http://answers.microsoft.com/en-us/windows/forum/windows_8-networking/internet-connection-dropping-w... - from 12 Jan 2014 onwards. Is this on your / the CSC / Product's radar?

Sorry, not sure how I missed this thread.
I've asked the question internally if it's something we're aware of and what can be done, I'll get back when I've got a response.

[#7]

This or this (reporting the same thing) suggest Technicolor should already be aware of it. Presumably it doesn't affect all Win 8.1 computers or we'd have seen more about it here.

[#8]

@Chris,
Have you had an internal response please?
There is another report of the same issue here - http://community.plus.net/forum/index.php/topic,135034.new.html#new - which did not get quite the right advice from the CSC.
Again I ask the question, does the CSC know about this strange condition bringing together 3 technology failures...
1. No response from PlusNET DNS (based on observation that the problem does not occur when Win8 PC DNS is changed to Google)
2. TG582n treats DNS non-response as WAN down and delivers a spoofed IP address
3. Win8 multiple caching of IP address resolution causes confusing behaviours which makes the problem look like something else - e,g. Intermittent wifi
I suggest that an alert flash across CSC is required to avoid inappropriate, potentially expensive advice is given to customers.
A fix to the DNS response issues or the TG behaviour ought to fix this.  Please send me a PM if products or networks need more input on this problem.  If there are diagnostics which can be set or gathered from the TG on DNS lookups, I am quite happy to assist.
Cheers,
Kevin

[#9]

Does changing the DNS servers that the 582n uses make a difference? When the Win8 computer is set to use Google DNS, then it won't be using the router's internal DNS server at all. Changing the computer to use Plusnet DNS servers directly also avoids the 582n's internal DNS server.

[#10]

First, FYI, I got exactly the same as Oldjim with the McAfee page, and I'm using a different version of Windows from him.

Quote from: Townman

I found that changing the DNS settings to use Google's DNS (8.8.8.8 and 4.4.4.4) virtually eliminated the problem,

Can you confirm that this change is being done on your Win8 machine? (and not in the TG).
I've not been following this thread for a few days so trying to do a quick catch up. I'm coming to the conclusion that this issue is possibly related to a combination of Browser DNS Pre-fetching & WANDownSpoofing.

Quote from: Townman

Can you explain what this does, why it does it and the consequence of disabling it please?

As far as I can tell, and also going by npr's comment, disabling WANDownSpoofing certainly won't have a detrimental effect and may well solve the issue.
As I mentioned in reply #32 if Plusnet's DNS server responds (even with a page not found) then a Spoofed entry does not exist. If for some reason the TG thinks the DNS server hasn't responded (due to Pre-fetching?) and there is a spoofed entry this may cause some conflict.

[#11]

Just to add to this, having been alerted by Townman, I think I'm having the same issue but on Windows 7 x64.
Other systems on the same network, including W8.1, seem to be OK.
I started my own thread here: http://community.plus.net/forum/index.php/topic,135116.0.html but will continue here for now.
Note that I am using Microsoft Security Essentials (and IE10 mostly) on W7 and Defender on W8.1, no third-party protection.

[#12]

You could configure the router to directly assign the DNS IP addresses to your devices in place of it assigning the routers dns relay (192.168.1.254). If it works by manually configuring the dns in the devices then this method should also work.
http://npr.me.uk/changedns.html ; (method 2)

[#13]

It would be interesting to see if setting different DNS servers in the router reduced the propensity of the TG to spoof addresses.
Does changing the DNS settings require a router restart (xDSL or PPP)?

[#14]

I don't think web browser DNS pre-fetching is likely to have much to do with this issue. I think the DNS pre-fetching done by a web browser is just the browser doing some extra DNS lookups for sites linked in a webpage. The extra lookups might be wasted if you don't open those links, but as far as any DNS server is concerned, the DNS lookups from pre-fetching are the same as any other DNS lookups.
I was thinking the issue might be related to the 582n sending each DNS query to both its DNS servers at the same time. I suppose in a way that behaviour should make things more reliable, since you should only need to get a reply from one of the two servers. But if both queries or replies get destroyed by a burst of CRC errors, or both get dropped somewhere due to congestion, there's no other DNS server address for it to fallback to after the timeout.
I thought it might be interesting to try configuring the router to use Plusnet's DNS servers, but manually assigning them different metric values, so that it would try one, and then the other if the first fails to respond. You could use the 212.159.13.49 and 212.159.13.50 IP addresses if that makes it easier to configure.

[#15]

Quote from: Townman

Does changing the DNS settings require a router restart (xDSL or PPP)?

No.