cancel
Showing results for 
Search instead for 
Did you mean: 

Plusnet DNS Servers Slow?

buseng12
Grafter
Posts: 374
Thanks: 1
Registered: ‎14-06-2013

Plusnet DNS Servers Slow?

Is there a problem with Plusnet's DNS servers? I'm finding that some web pages are taking ages to load or fail to load at all.
Diagnostics tell me that the DNS servers are not responding.
I have put Google DNS servers in my adaptor settings & the pages load almost instantly.
23 REPLIES 23
Pettitto
Plusnet Alumni (retired)
Plusnet Alumni (retired)
Posts: 6,346
Fixes: 5
Registered: ‎26-11-2011

Re: Plusnet DNS Servers Slow?

We've got an open Service Status regarding DNS at the moment.

http://usertools.plus.net/status/archive/1401373622.htm
npr
Pro
Posts: 1,898
Thanks: 119
Fixes: 9
Registered: ‎21-01-2013

Re: Plusnet DNS Servers Slow?

Quote
Posted on: Thursday 29 May 2014, 15:27
Our network engineers have been investigating a solution for this and we'll be implementing some changes this evening.

@Chris,
I don't think that happened.
Can we please have a update on this.
popeyeuk
Grafter
Posts: 90
Thanks: 3
Registered: ‎07-09-2010

Re: Plusnet DNS Servers Slow?

Hello
I have been having problems with slow DNS lookups for a while.  I have made things useable by putting
Googles public DNS server details into my PC's network connection settings..
Not sure what's going on..
30FTTC06
Pro
Posts: 2,286
Thanks: 108
Fixes: 4
Registered: ‎18-02-2013

Re: Plusnet DNS Servers Slow?

This issue got fixed a while ago, I've done a few tests and all seems well from my end atm.
[tt]212.159.6.9        17.06/18.02/19.03/0.63/0
212.159.6.10        17.79/18.12/18.60/0.28/0
212.159.13.49      17.31/17.90/18.40/0.43/0
212.159.13.50      17.53/18.16/18.88/0.46/0
[/tt]
SuperZoom
Grafter
Posts: 353
Registered: ‎17-05-2013

Re: Plusnet DNS Servers Slow?

Yup, can't see any DNS issues from here either (PTN-AG02):
[tt]
Nameserver           Response Time (ms)
                    min    avg    max    stdev  retries
212.159.6.9         3.79   4.28   4.79   0.41   0
212.159.6.10         4.50   4.85   5.10   0.20   0
212.159.13.49       3.82   4.45   4.83   0.43   0
212.159.13.50       3.82   4.47   4.88   0.40   0
Local Unbound       0.89   0.91   0.94   0.02   0
[/tt]

Had another re-jig, so have moved Unbound to an RPi myself now too, 11110_110.
Even decided to give the ad-blocking a try. Works very nicely, I must say     Smiley

EDIT:
On the other hand, there has been quite a bit of packet loss here, so that could be a more likely cause of any recent sluggishness if it isn't local to my exchange.
Kelly
Hero
Posts: 5,497
Thanks: 380
Fixes: 9
Registered: ‎04-04-2007

Re: Plusnet DNS Servers Slow?

Packet loss on your graph is down to our LONAP peering, rather than general problems.
Kelly Dorset
Ex-Broadband Service Manager
SuperZoom
Grafter
Posts: 353
Registered: ‎17-05-2013

Re: Plusnet DNS Servers Slow?

Ah, I didn't see the other thread before I posted.
That's one advantage of the LCP echo system Andrews and Arnold use, I suppose. Useful to have both.
30FTTC06
Pro
Posts: 2,286
Thanks: 108
Fixes: 4
Registered: ‎18-02-2013

Re: Plusnet DNS Servers Slow?

Quote from: SuperZoom

[tt]
Nameserver           Response Time (ms)
                    min    avg    max    stdev  retries
212.159.6.9         3.79   4.28   4.79   0.41   0
212.159.6.10         4.50   4.85   5.10   0.20   0
212.159.13.49       3.82   4.45   4.83   0.43   0
212.159.13.50       3.82   4.47   4.88   0.40   0
Local Unbound       0.89   0.91   0.94   0.02   0
[/tt]

Had another re-jig, so have moved Unbound to an RPi myself now too, 11110_110.
Even decided to give the ad-blocking a try. Works very nicely, I must say     Smiley

Your figures seem nice and tight now, did you find out what was causing your http slowdown?
Yeah I think the little Raspberry does a sterling job as a DNS-cache, filtering works very well with yoyo's list
Not sure if you've seen the conversion script or not, makes things slightly easier, yoyo updates the list once a month and it doesn't go over the top, just about perfect infact for me with OpenDNS Family-Safe ip's in combination with dnstop "sudo dnstop -l  9 eth0" for a quick view  Wink

#!/bin/sh
#
# Convert the Yoyo.org anti-ad server listing
# into an unbound dns spoof redirection list.

wget -O yoyo_ad_servers "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&mimetype=plaintext" && \
cat yoyo_ad_servers | grep 127 | awk '{print $2}' | \
while read line ; \
do \
  echo "local-zone: \"$line\" redirect" ;\
  echo "local-data: \"$line A 127.0.0.1\"" ;\
done > \
filter.conf

#  then add an include line to your unbound.conf pointing to the full path of
#  the filter.conf file:
#
#   include: filter.conf
#

This gives you a basic idea how well mine is working atm, about 24 days worth 4 pc's!
sudo unbound-control stats_noreset
[tt]
thread0.num.queries=177805
thread0.num.cachehits=116441
thread0.num.cachemiss=61364
thread0.num.prefetch=4274
thread0.num.recursivereplies=61364
thread0.requestlist.avg=0.785795
thread0.requestlist.max=11
thread0.requestlist.overwritten=0
thread0.requestlist.exceeded=0
thread0.requestlist.current.all=0
thread0.requestlist.current.user=0
thread0.recursion.time.avg=0.043214
thread0.recursion.time.median=0.0312249
total.num.queries=177805
total.num.cachehits=116441
total.num.cachemiss=61364
total.num.prefetch=4274
total.num.recursivereplies=61364
total.requestlist.avg=0.785795
total.requestlist.max=11
total.requestlist.overwritten=0
total.requestlist.exceeded=0
total.requestlist.current.all=0
total.requestlist.current.user=0
total.recursion.time.avg=0.043214
total.recursion.time.median=0.0312249
time.now=1406463969.769328
time.up=2174933.197749
time.elapsed=2174933.197749
[/tt]
Again thanks to npr for his help and guidance.
npr
Pro
Posts: 1,898
Thanks: 119
Fixes: 9
Registered: ‎21-01-2013

Re: Plusnet DNS Servers Slow?

Impressive results  Cheesy
Any chance of a copy of your unbound.conf, to see if I'm missing a trick.
30FTTC06
Pro
Posts: 2,286
Thanks: 108
Fixes: 4
Registered: ‎18-02-2013

Re: Plusnet DNS Servers Slow?

pm sent npr.
Don't forget I'm using max memory for the cpu in raspi-config and permanant  over-clocking "not on demand"
What speeds are you getting from your SD card ? http://elinux.org/RPi_SD_cards
Write speed:
sync; time dd if=/dev/zero of=~/test.tmp bs=500K count=1024; time sync
Read speed:
dd if=~/test.tmp of=/dev/null bs=500K count=1024

Delete the temporary file:
rm ~/test.tmp
My results:
sync; time dd if=/dev/zero of=~/test.tmp bs=500K count=1024; time sync
1024+0 records in
1024+0 records out
524288000 bytes (524 MB) copied, 29.0842 s, 18.0 MB/s

real    0m29.463s
user    0m0.020s
sys    0m9.480s

real    0m2.577s
dd if=~/test.tmp of=/dev/null bs=500K count=1024
1024+0 records in
1024+0 records out
524288000 bytes (524 MB) copied, 28.1743 s, 18.6 MB/s
uname -a
Linux  3.10.37+ #669 PREEMPT Tue Apr 15 14:44:32 BST 2014 armv6l GNU/Linux

npr
Pro
Posts: 1,898
Thanks: 119
Fixes: 9
Registered: ‎21-01-2013

Re: Plusnet DNS Servers Slow?

Quote
pi@piDNS ~ $ sync; time dd if=/dev/zero of=~/test.tmp bs=500K count=1024; time sync
1024+0 records in
1024+0 records out
524288000 bytes (524 MB) copied, 43.4871 s, 12.1 MB/s
real    0m45.819s
user    0m0.020s
sys    0m10.120s
real    0m0.057s
user    0m0.000s
sys    0m0.010s
pi@piDNS ~ $ dd if=~/test.tmp of=/dev/null bs=500K count=1024
1024+0 records in
1024+0 records out
524288000 bytes (524 MB) copied, 28.6999 s, 18.3 MB/s
pi@piDNS ~ $ uname -a
Linux piDNS 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 armv6l GNU/Linux

My write speed is a bit slower but the read speeds are near enough the same.
My Pi is one of the early 256 MB ones. I believe you've said yours is  512 MB, I'm sure that will make a difference.

30FTTC06
Pro
Posts: 2,286
Thanks: 108
Fixes: 4
Registered: ‎18-02-2013

Re: Plusnet DNS Servers Slow?

Yes I have the 512mb version, so it seems that might well be why, I'll do some tests on the 256mb version when I get around to it.
These are the figures so far without the filter running, it looks on target for the same sort of figures as with it running.
[tt]
thread0.num.queries=1400
thread0.num.cachehits=684
thread0.num.cachemiss=716
thread0.num.prefetch=24
thread0.num.recursivereplies=716
thread0.requestlist.avg=0.766216
thread0.requestlist.max=7
thread0.requestlist.overwritten=0
thread0.requestlist.exceeded=0
thread0.requestlist.current.all=0
thread0.requestlist.current.user=0
thread0.recursion.time.avg=0.054768
thread0.recursion.time.median=0.0362699
total.num.queries=1400
total.num.cachehits=684
total.num.cachemiss=716
total.num.prefetch=24
total.num.recursivereplies=716
total.requestlist.avg=0.766216
total.requestlist.max=7
total.requestlist.overwritten=0
total.requestlist.exceeded=0
total.requestlist.current.all=0
total.requestlist.current.user=0
total.recursion.time.avg=0.054768
total.recursion.time.median=0.0362699
time.now=1406489662.454376
time.up=9984.115238
time.elapsed=9984.115238
[/tt]
Here are my figures for my 256mb version with no over-clocking and a class(6) Card
Linux 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 armv6l GNU/Linux
[tt]
sys    0m0.000s
sync; time dd if=/dev/zero of=~/test.tmp bs=500K count=1024; time sync
1024+0 records in
1024+0 records out
524288000 bytes (524 MB) copied, 98.9418 s, 5.3 MB/s

real    1m40.514s
user    0m0.020s
sys    0m10.020s

real    0m6.081s
user    0m0.000s
sys    0m0.000s
dd if=~/test.tmp of=/dev/null bs=500K count=1024
1024+0 records in
1024+0 records out
524288000 bytes (524 MB) copied, 28.5679 s, 18.4 MB/s[/tt]
npr
Pro
Posts: 1,898
Thanks: 119
Fixes: 9
Registered: ‎21-01-2013

Re: Plusnet DNS Servers Slow?

Quote from: 11110_110
Yes I have the 512mb version, so it seems that might well be why, I'll do some tests on the 256mb version when I get around to it.

I'll look forward to seeing those results.
It may justify upgrading my Pi.  Cheesy
SuperZoom
Grafter
Posts: 353
Registered: ‎17-05-2013

Re: Plusnet DNS Servers Slow?

Interesting to compare the stats, actually, and see how the setup and usage pattern is reflected in them.
So this is about 20 days' worth of extremely light and sporadic use from ours (not much going on here at the moment, hence a re-jig).
It's a Model B, overclocked to 900Mhz and 2v, in the safe way via config.txt, but with the standard memory allocation.
(I notice a new B+ has just been released with a more nifty push-lock microSD card reader, and some other stuff, so now may be the time to snap up bargain 512MB Model B stock!)
Unbound doesn't take a lot of memory at all, however.
At idle, top reveals:
[tt]
VIRT= 42084
RES=  24m
SHR=  2036
%MEM= 5.7
[/tt]
%CPU is zero, rising to 1% if I pull up a web page on a client.
[EDIT FOR CLARITY: so, with the current settings, the "on demand" overclocking doesn't actually kick in.]

SD card performance shouldn't matter very much either, provided all the logging is turned off...

[tt]
total.num.queries=22218
total.num.cachehits=3788
total.num.cachemiss=18430
total.num.prefetch=326
total.num.recursivereplies=18430
total.requestlist.avg=0.904191
total.requestlist.max=21
total.requestlist.overwritten=0
total.requestlist.exceeded=0
total.requestlist.current.all=0
total.requestlist.current.user=0
total.recursion.time.avg=0.226320
total.recursion.time.median=0.0718047
time.now=1406553860.862030
time.up=1776754.178674
time.elapsed=1776754.178674
[/tt]
You can see that because the usage is sporadic, there are lots of cache misses, and because ours is doing its own recursion (not merely caching) on an end-user connection (albeit with the low latency of FTTP) the average and median recursion times are higher than your use case, 11110_110, of leveraging OpenDNS's enormous cache and processing power as an upstream resolver.
Unbound is definitely faster running on an old laptop. The lower processing power of the Raspberry Pi does have a significant impact - but the upside is a single-purpose appliance which consumes little power, generates little heat and produces no noise.
The interesting thing is that even on our connection, where latency to PlusNet's DNS servers is so low, it is still worth doing this. I don't know whether it's simply the solid, reliable consistency of it or what, but the connection is more responsive with local servers. Those nice figures I posted for the PlusNet ones certainly can't be relied upon to stay that way, so I'd rather not have to think about what they're doing at any particular moment.
I haven't noticed any performance penalty from having the ad filters activated.
I'm using the YoYo list too, and have a very similar script.
I actually serve up the IP address of the RPi rather than the loopback address and have set up the firewall on it to reject the resulting requests. Minimal resource use and they fail much more quickly that way for a variety of clients, especially Android devices, I've found.
Here's our skeleton unbound.conf with unmodified defaults, site-specifics and notes removed. The RPi only has a single core, of course, but I've left those lines in in case anyone wants to fiddle on a more powerful machine and assess the impact of processing power. The extra send and receive socket buffers are probably neither needed nor useful with a max request list of 21(!) and especially considering I haven't overridden the system's limits, but I've left them in too because I'm still intending to have a play around with that.

server:
   auto-trust-anchor-file: "/var/lib/unbound/root.key"
   root-hints: "/etc/unbound/root.hints"
   verbosity: 0
   statistics-interval: 0
   num-threads: 1
   msg-cache-slabs: 1
   rrset-cache-slabs: 1
   infra-cache-slabs: 1
   key-cache-slabs: 1
   outgoing-range: 950
   num-queries-per-thread: 512
   so-rcvbuf: 4m
   so-sndbuf: 4m
   cache-min-ttl: 3600
   module-config: "iterator"
   interface:          #According to your needs
   outgoing-interface: #According to your needs
   access-control:     #According to your needs
   port: 53
   prefetch: yes
   do-ip4: yes
   do-ip6: no
   do-udp: yes
   do-tcp: no
   hide-identity: yes
   hide-version: yes
   harden-short-bufsize: yes
   harden-large-queries: yes
   harden-glue: yes
   private-address: #According to your needs
   private-domain:  #According to your needs
   local-zone:      #According to your needs
   local-data:      #According to your needs
   include: "/etc/unbound/adfilter.conf"
   rrset-cache-size: 40m
   msg-cache-size: 20m
   infra-cache-numhosts: 30000
forward-zone:      #According to your needs
   name:          #According to your needs
   forward-first: #According to your needs
   forward-addr:  #According to your needs
remote-control:
   control-enable: yes #According to your needs
   control-interface:  #According to your needs
   control-port:       #According to your needs


As to HTTP responsiveness, an explanation remains elusive. Sometimes (occasionally) it flies. If you've ever had your car handbrake get jammed on, it's a bit like that. It gets unstuck and suddenly you think "that's better, I knew there was something wrong!" It either has to be something to do with BT profiles or the exchange, or with latency introduced by PlusNet's profiling and traffic management system. The times when it performs as I'd expect must be when some profile or other is temporarily removed for maintenance, or routing or SVLANs are in the process of being reconfigured or something. We actually connect to a different bRAS now, so can't have been that. Everything is much, much better than it was at one point, mind you. I wouldn't be surprised if it were the exchange. In any case, I should soon have an opportunity to do some comparative tests on a good quality FTTC connection on another exchange, so it will be interesting to see what the difference is.