Plusnet DNS up-the-creek AGAIN?

[#1]

Quote from: Anotherone

Question (not given it any thought yet) - How might one tell if it's the Router dns client failing, or Plusnet's DNS servers?

Dig?

[#2]

If you've got a always on PC, send it to a syslog client.
No idea of the log file limit, but I have suspected performance suffers if the logs get too big or it may be other memory usage. That's why I always reboot the router every two weeks or so.
Don't think you need worry about the dns client failing. It uses the routers dns server IP's, so if one fails they've both failed.

[#3]

Quote from: Anotherone

I think you may have missed the subtlety of my post Brian

Whoosh!
Straight over my head...

[#4]

Hi All,
So, the DNS resolver on the router (192.168.1.254) will relay DNS queries to the Plusnet DNS servers when the WAN interface is up.
When the WAN interface is down all responses will point to the 198.18.1.0-255 range so that any browsing requests are directed towards 'helpful' features on the router to get people back online (these hopefully will become more helpful with our latest FTTC firmware).
The list you see by running ':dns server debug spoof list' should only be used as a lookup table when the WAN interface is down.
You can turn off this functionality by running the command given by npr earlier ":dns server config WANDownSpoofing=disabled"
So... some of you who don't even use the DNS on the router have entries in this table, this is because the various clients on the router (TR-069, NTP etc) use the routers internal DNS resolver.
However... if the router is connected to the internet, and 198.18.1.0-255 addresses are being returned then I'd be very interested in seeing a Wireshark of this happening and I'll get Technicolor to open a bug on it. But please remember that the client on your computer may have it's own DNS cache, so a packet capture is very important in confirming what exactly is going on.
Any questions? Please just ask.
Cheers,
Matt

[#5]

Quote from: Matt

But please remember that the client on your computer may have it's own DNS cache, so a packet capture is very important in confirming what exactly is going on.

Doesn't adding the DNS server to the command ensure that it bypasses the PC's DNS cache? E.g.

nslookup ntp.plus.net 192.168.1.254

[#6]

Quote from: jelv

Doesn't adding the DNS server to the command ensure that it bypasses the PC's DNS cache? E.g. nslookup ntp.plus.net 192.168.1.254

Yes, it does, but if you're using something like the ping command (ping plus.net), I'm not sure if it does a new DNS look-up each time you run it.
Did I miss someone with a nslookup resolving to the 198 addresses when they had internet connectivity? (Wireshark trace please :))
Matt

[#7]

Will try and get Wiresharks next time!

Quote from: Anotherone

Thinking of running the CLI command <dns server config domain=lan syslog=enabled> which presumably would get some timestamps on these in the future in the Event log.

In definitely don't recommend that - leave syslog disabled for this. It logs every dns request and a couple of visits to a couple of media intensive pages with ads soon fills the log msgbuf (cache) - a waste of time, and would probably lose more important log entries.
Still investigating other possibilities.

[#8]

Quote from: Matt

However... if the router is connected to the internet, and 198.18.1.0-255 addresses are being returned then I'd be very interested in seeing a Wireshark of this happening and I'll get Technicolor to open a bug on it. But please remember that the client on your computer may have it's own DNS cache, so a packet capture is very important in confirming what exactly is going on.

Thread necromancy! Just been debugging this and came across this thread. I have a wireshark capture if you're still interested in one.
https://www.dropbox.com/s/mqccb1gsvvnm2cm/wireshark-dns-plusnet.pcapng.gz?dl=0
Eg look at the DNS response at time 6.778249, to a request for localhost.ably.io, which returns 198.18.1.134 -- even though all other requests made within a few milliseconds (including one for that same domain, eg response at 6.773642) return the correct result.
Simon