Web browsing using Unbound a lot slower than using Forwarder
-
Hello everyone
Recently I made a fresh install of 2.4.3 and restored my configuration from before the install.
Before the new install, web browsing was really fast and smooth.
After the fresh install, some pages still load fast, however some pages take very long to load.Today I compared speeds between using Unbound and DNS Forwarder. Using the DNS Forwarder, speeds are as expected, however Unbound seems to be a lot slower than before!
I do not forward queries using Unbound.I am using pfBlockerNG and squid. I tried again when I disabled squid, however that does not seem to have any impact on performance.
I don't know why this might have any influence, but before the new install, my LAN interface was connected to a trunk port and I was using only a single VLAN on it. I disabled the Trunk on the switch and made it an access port using the single VLAN I use for my LAN. With the fresh install, I deleted the VLAN interface, which apparently broke my traffic shaper configuration. I also posted about this on another thread. Now I can't reconfigure the traffic shaper.
Can anybody help me troubleshoot this? I would like to stick with Unbound…
Best Regards
Philipp -
If your having problems with resolving then you would need to resolve where the slowdown is in what your trying to resolve.
Once something is resolved it would be cached.. Once part of the tree is cached, that is also cached and does not have to be resolved again.
So for example if you look up something.domain.tld and resolve to find the name servers for domain.tld - and then you want to look up otherthing.domain.tld you would not have to resolve the NS again and unbound would directly query the NS for domain.tld until the ttl of the NS expire.
A good tool for troubleshooting problems with resolving is dig +trace since this will have your client running the dig command actually show you the resolve path so you can catch where you might be seeing problems in how long it takes to get an answer, etc.
Your really going to need some specifics of what it slow to resolve to try and find where the problem is.
If your on a high latency connection, then resolving can sometimes be slower than just forwarding.. Or if your trying to resolve something that authoritative ns are on the other side of the planet, etc. Then that can show longer than just asking some forwarder for what their cache is, etc.
But unless the TTL of a record is really short, once it is resolved once your clients resolving that should be just as fast if you were using a forwarder, etc.
Are you running your resolver through a vpn or something?
-
If your having problems with resolving then you would need to resolve where the slowdown is in what your trying to resolve.
Once something is resolved it would be cached.. Once part of the tree is cached, that is also cached and does not have to be resolved again.
So for example if you look up something.domain.tld and resolve to find the name servers for domain.tld - and then you want to look up otherthing.domain.tld you would not have to resolve the NS again and unbound would directly query the NS for domain.tld until the ttl of the NS expire.
A good tool for troubleshooting problems with resolving is dig +trace since this will have your client running the dig command actually show you the resolve path so you can catch where you might be seeing problems in how long it takes to get an answer, etc.
Your really going to need some specifics of what it slow to resolve to try and find where the problem is.
If your on a high latency connection, then resolving can sometimes be slower than just forwarding.. Or if your trying to resolve something that authoritative ns are on the other side of the planet, etc. Then that can show longer than just asking some forwarder for what their cache is, etc.
But unless the TTL of a record is really short, once it is resolved once your clients resolving that should be just as fast if you were using a forwarder, etc.
Are you running your resolver through a vpn or something?
Thank you for this quick response! I generally do have quite a fast connection, in fact I am running a Multi-WAN setup with 2x 100Mbit/s Downstream, 2x 20Mbit/s Upstream and a RTT to Google DNS of around 10ms.
I don't run DNS through a VPN.I did not yet test with dig, but here's what I found so far: uninstalling pfBlockerNG made the issue go away. I reinstalled pfBlockerNG and tried to just disable it by unchecking its Enable checkbox.
Trying to disable pfBlockerNG this way yields the following error message:The following input errors were detected:
The field Interface(s) is required.Now, because my LAN interface is not on the interface I used to have (ixl1 instead of ixl1.50), could it be pfBlockerNG is still configured with ixl1.50? I use the same name for the LAN interface as before…
Best Regards
Philipp -
Here's the output of dig for a site that loads slowly:
; <<>> DiG 9.11.2-P1 <<>> +trace www.blick.ch 127.0.0.1
;; global options: +cmd
. 515737 IN NS g.root-servers.net.
. 515737 IN NS h.root-servers.net.
. 515737 IN NS k.root-servers.net.
. 515737 IN NS d.root-servers.net.
. 515737 IN NS e.root-servers.net.
. 515737 IN NS l.root-servers.net.
. 515737 IN NS j.root-servers.net.
. 515737 IN NS m.root-servers.net.
. 515737 IN NS b.root-servers.net.
. 515737 IN NS i.root-servers.net.
. 515737 IN NS f.root-servers.net.
. 515737 IN NS c.root-servers.net.
. 515737 IN NS a.root-servers.net.
. 515737 IN RRSIG NS 8 0 518400 20180504050000 20180421040000 39570 . hpaw9eeH9OWPkzOcKWom0/iv4cAq2RyBcS17lay3ZmobM8MTbzkgtbCo lkWqlsn9+oZmHNS7IdFUVIfTV86wy2JwhRclNOnE7njgjjlkuE84GX/d HRQovK7B+NN6AJ8bhVILEp0mD5nWe5rGrWAdZQbZfEMuK7JqcZNcUiRr ZRQMHcD00Tq0DvlcUmJ5V6aP357KUZu4yShrv0f/RPEyZdjnHRMrtWVu 0/xG70YPFJ0DwbNRdMSrw1lRwwhIbbzSpvIxsTrAPeMTvxkkumUB1d0A B0u1ZMfEIvt+VlB8uxCd6qbrYxR3iLdizbGTvwmbX7koqPxUYYwERDwC OrRZrw==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 msch. 172800 IN NS a.nic.ch.
ch. 172800 IN NS b.nic.ch.
ch. 172800 IN NS c.nic.ch.
ch. 172800 IN NS d.nic.ch.
ch. 172800 IN NS e.nic.ch.
ch. 172800 IN NS f.nic.ch.
ch. 172800 IN NS g.nic.ch.
ch. 172800 IN NS h.nic.ch.
ch. 86400 IN DS 58852 8 2 A14E7E746D70F96F0AA20B326C5903F294AACB2C8C720B73CA369FE6 11F565C4
ch. 86400 IN RRSIG DS 8 1 86400 20180504050000 20180421040000 39570 . ExrkaBTMQs3NpGJQzmkJq6ldGd7+02edXDMw3/fTu/arWe2ab3Srb+5d vWYuoLEyH7J7wdu2FtFYRw23i3+4HE51nQw/tF5ag5aWcGrlukLqgFwp YZqMvT6RPluq2dHQluOYEiFO1YtZPvN3Ih5eWgvTT6KddXyLO0AF45Wc XovTcAWrS5osf6aXweIP6lexI8NnuM3EfAzeLbf82NtCNyskEb9k8eUo 6yxgxgN1ib9qpudnSW3zv390+CXbe+0uii+eZqV2HkMHYl483+8roGEq cl0ao84b8ipWnHTpIw4VndcoyRcsdP2RR34in12z6cT8Rf739x1J7agH pFt0Vw==
;; Received 860 bytes from 198.41.0.4#53(a.root-servers.net) in 99 msblick.ch. 3600 IN NS ns-cloud-b1.googledomains.com.
blick.ch. 3600 IN NS ns-cloud-b3.googledomains.com.
blick.ch. 3600 IN NS ns-cloud-b4.googledomains.com.
blick.ch. 3600 IN NS ns-cloud-b2.googledomains.com.
NEQ3PPNH7VK456PM1TAG1MMBRHRO8OJQ.ch. 900 IN NSEC3 1 1 2 D1B31DA4 NEQ777D7Q9MN996RBBHLTU5APAAH1VEB NS SOA RRSIG DNSKEY NSEC3PARAM
NEQ3PPNH7VK456PM1TAG1MMBRHRO8OJQ.ch. 900 IN RRSIG NSEC3 8 2 900 20180513070151 20180419113002 15681 ch. RiaJQjw1tv0CiR4ESJQyjpvTOAq3OtTJ28kjNsaCLK7j2o/500/nxNDW 7jiBbehlZgioHe9OxNyeNodL4TrJ4VmLEfDAgREG7qK/djzQEQ7voO9I DjqgURjr5Ofwk1TZGzxaVOURmO1c5i0g5LeQMdeD3THJNjz09GpqdRlC LypLUWOiXJvbnsfINqs2SEetjfcI+n2h9KN8HI6sBHQ7wQ==
V027GS3VI0TS01R3CNV3I2K132RKKJJQ.ch. 900 IN NSEC3 1 1 2 D1B31DA4 V02K0IBVJVR6SC0S6O3740RHEHQ1IU3T NS DS RRSIG
V027GS3VI0TS01R3CNV3I2K132RKKJJQ.ch. 900 IN RRSIG NSEC3 8 2 900 20180508025421 20180419113002 15681 ch. gIkVYPP37d6byaGZesyGYrQVlEr62ms94vjIMuhtqe/ow6Y9MQaJyDLE hWTL66ZbJjwgQV6MXi013ZB8ToehUXWC4DtxhSBd74LH2LDkUNip76dJ oxegobUw9NzhQJv5JFo11TyIpbVzIq03cqF651bMt1TRl+Ph0WHlzpzA jhTHfbthG8pk2QT0dNJSNXSgbP2flr61ZI+TCBBO0t8XrQ==
;; Received 717 bytes from 147.28.0.39#53(c.nic.ch) in 160 mswww.blick.ch. 300 IN CNAME f.blick.ch.edgekey.net.
;; Received 77 bytes from 216.239.38.107#53(ns-cloud-b4.googledomains.com) in 26 ms. 515729 IN NS g.root-servers.net.
. 515729 IN NS h.root-servers.net.
. 515729 IN NS k.root-servers.net.
. 515729 IN NS d.root-servers.net.
. 515729 IN NS e.root-servers.net.
. 515729 IN NS l.root-servers.net.
. 515729 IN NS j.root-servers.net.
. 515729 IN NS m.root-servers.net.
. 515729 IN NS b.root-servers.net.
. 515729 IN NS i.root-servers.net.
. 515729 IN NS f.root-servers.net.
. 515729 IN NS c.root-servers.net.
. 515729 IN NS a.root-servers.net.
. 515729 IN RRSIG NS 8 0 518400 20180504050000 20180421040000 39570 . hpaw9eeH9OWPkzOcKWom0/iv4cAq2RyBcS17lay3ZmobM8MTbzkgtbCo lkWqlsn9+oZmHNS7IdFUVIfTV86wy2JwhRclNOnE7njgjjlkuE84GX/d HRQovK7B+NN6AJ8bhVILEp0mD5nWe5rGrWAdZQbZfEMuK7JqcZNcUiRr ZRQMHcD00Tq0DvlcUmJ5V6aP357KUZu4yShrv0f/RPEyZdjnHRMrtWVu 0/xG70YPFJ0DwbNRdMSrw1lRwwhIbbzSpvIxsTrAPeMTvxkkumUB1d0A B0u1ZMfEIvt+VlB8uxCd6qbrYxR3iLdizbGTvwmbX7koqPxUYYwERDwC OrRZrw==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018042100 1800 900 604800 86400
. 86400 IN RRSIG SOA 8 0 86400 20180504050000 20180421040000 39570 . fOUQQkc2GOyqwb8n8evw7fIrP0ih2IcWAx5bqBVF9RYbYbxgQh8xJCng w+Hv6AER44Cz8rMEaDE+0BE5QaPswPDVCEPUhhbO86erYp5qMD6EDzas SzdtW9MohzLDTBVuTZ+VxAueDqc1bSyrU4yrQnzQEHSYrXaweiHs4Cfv QPqmdjAaCMU8f+eppBwmGqAeLGKPzgdTXfvbwia++v2SIbmBGuehJRj4 pNJGWteXw9/2nbGbqj4nA7pZtdWKznVykSGdK8lB+E2+lmezYe4UMasU n6Tkr5F7YZnVlDmc00s3QivF4wSSAOcYwzr9IC9sIySm6/5nzOvICHxp CRnZhQ==
. 86400 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY
. 86400 IN RRSIG NSEC 8 0 86400 20180504050000 20180421040000 39570 . Z8ESZJV9tk9kI89gSc0JaQg7zgnWKtGGPf5hZN5Cf4AmFjLUTgfTE7Wt fgYLyHelm1xrYEk/ErsVKPG8/VKNoZc0PmwG/biihB936AtCOfFBasv9 aSo1N1a6l+EbqlYJgoz8ZQ8tw3laE5xtO2DQvC60L+W7N0CDxHLnDGjk /dJsa1jdq4q8pk4kAXhg58HFu3yHvs7yPty9S7FyOiTtO8CvKyJ1oDpv DuNRPYoaktHK/8L2yW2cal+2KzI3p+Gf02QU5SZJi/Lic1v9MyMS23a2 mu9boniMc0KbVpJlrdw3w0IznBGfLX9oC/EXi1RnExCpL2FvQ7X1FNol 8WkfyA==
;; Received 710 bytes from 192.5.5.241#53(f.root-servers.net) in 17 msApparently DNS itself does not even seem to be really slow…
-
I was able to reset the outbound interface of pfBlockerNG and then disable the package. This does not seem to make the situation any better however…
So currently, with pfBlockerNG uninstalled, it's faster than having it installed and disabled...
-
I enabled pfBlockerNG again and restarted Unbound. Somehow the issue has gone away. I suppose re-setting the pfBlocker outbound interface did the trick.
Web browsing is as fast as it used to be now. I just need to get the traffic shaper to work again and migration will be complete. -
While I am a huge fan of bcan177's work on the package.. It has become somewhat of a beast ;)
And taming a beast can have some trouble..
Glad you got it sorted, and this from your trace
Received 717 bytes from 147.28.0.39#53(c.nic.ch) in 160 ms
160ms is a bit on the high side.. but not crazy or anything. Unless every step in the resolve process was taking that or longer I don't see how you would of noticed a problem
Doing the dig on your client and then on your server (pfsense) could show if something else going on vs just latency, etc. Your client shouldn't be any significant different in latency that what pfsense actually shows, etc.
-
Well yeah I'm happy it works again… With all the IPs and domains I blacklist, one would not think it would be possible to have a nice and fast browsing experience like this. On my system it only hurts performance very slightly, which I think squid makes up for. I'm still deciding if I should set up HTTPS proxying.
Whatever my latency is, I don't think I can contribute to that a lot any more. I'm pretty sure I've done everything on my end to minimize latency (except for the traffic shaper which I still can't get to work again). I think my internet latency will only improve when I get a fiber connection straight into my pfsense box, which is probably years away unless I move out lol.