What's new

Unbound unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Code:
num-threads: 2

Very interesting, i will definetely try this. Did you change just the threads or the slabs aswell?
No it's just experimental so I just changed threads to '2'.

NOTE: Pick up the latest v3.10 beta and be aware that it is currently hardcoded for only two threads (0 and 1) when displaying the cache stats on screen.

However, if you issue 's thread' you will see the cache counters etc. for all additional threads but you will have to manually calculate the cache hits percentage.
 
No it's just experimental so I just changed threads to '2'.

NOTE: Pick up the latest v3.10 beta and be aware that it is currently hardcoded for only two threads (0 and 1) when displaying the cache stats on screen.

However, if you issue 's thread' you will see the cache counters etc. for all additional threads but you will have to manually calculate the cache hits percentage.
I just installed the dev branch with uf dev and i get this:
Code:
A:Option ==> s


total.num.queries=11                    total.num.expired=0                     total.requestlist.exceeded=0            total.tcpusage=0
total.num.queries_ip_ratelimited=0      total.num.recursivereplies=9            total.requestlist.current.all=0         msg.cache.count=636
total.num.cachehits=2                   total.requestlist.avg=0                 total.requestlist.current.user=0        rrset.cache.count=782
total.num.cachemiss=9                   total.requestlist.max=0                 total.recursion.time.avg=0.238458       infra.cache.count=94
total.num.prefetch=0                    total.requestlist.overwritten=0         total.recursion.time.median=0.229376    key.cache.count=26



Summary: Cache Hits success=18.00%

thread0.num.queries=6                   thread0.num.expired=0                   thread0.requestlist.exceeded=0          thread0.tcpusage=0
thread0.num.queries_ip_ratelimited=0    thread0.num.recursivereplies=4          thread0.requestlist.current.all=0       msg.cache.count=636
thread0.num.cachehits=2                 thread0.requestlist.avg=0               thread0.requestlist.current.user=0      rrset.cache.count=782
thread0.num.cachemiss=4                 thread0.requestlist.max=0               thread0.recursion.time.avg=0.219783     infra.cache.count=94
thread0.num.prefetch=0                  thread0.requestlist.overwritten=0       thread0.recursion.time.median=0.218453  key.cache.count=26



Thread 0: Cache Hits success=33.00%
thread1.num.queries=5                   thread1.num.expired=0                   thread1.requestlist.exceeded=0          thread1.tcpusage=0
thread1.num.queries_ip_ratelimited=0    thread1.num.recursivereplies=5          thread1.requestlist.current.all=0       msg.cache.count=636
thread1.num.cachehits=0                 thread1.requestlist.avg=0               thread1.requestlist.current.user=0      rrset.cache.count=782
thread1.num.cachemiss=5                 thread1.requestlist.max=0               thread1.recursion.time.avg=0.253398     infra.cache.count=94
thread1.num.prefetch=0                  thread1.requestlist.overwritten=0       thread1.recursion.time.median=0.240299  key.cache.count=26



Thread 1: Cache Hits success=0.00%
I'm also seeing to pid's :
Code:
unbound (pid 6334 6137) is running... uptime: 0 Days, 00:04:46 version: 1.10.0 # rgnldo Github Version=v1.09 Martineau update (Date Loaded by unbound_manager Fri May 1 16:35:10 DST 2020)
 
The cache hit percentage in the UI is calculated hourly (at :59) and is calculated the same way as the script does it when you show stats.
Unbound tracks the number of hits and misses and total requests. It is in memory only so if you restart unbound those stats reset.

Thanks @juched - the heading to the first graph on your webui stats page is headed ...
"Cache Hits % Last 24 Hours" ... so if you reboot and the stats are reset to 0 [as above] then the result represented when you update stats is in fact the % since last reboot - not over last 24 hrs?

This has nothing to do with the cache, these are just numbers unbound has built internally to track usage. The calculation is simple total hits / total requests. It has always been the same with no changes

I assume what you mean by the underlined text above is the reset to zero on restart of unbound is not resetting [clearing] the actual DNS records that have so far been cached by unbound - but just the stats numbers?

When I boot my router, yes my number drops as there is such a low number of requests processed by then. But by the next hour it has come back up into the 80s and then grows to 90%.
That also being said, this is highly dependant on your devices and browsing habits.

When you reboot are the existing DNS request records retained in the cache through to the restart of unbound? So when the same DNS records are requested after reboot they count as hits against the accumulated pre and post boot cache ... or count as misses if they were never in the accumulated cache?

I am just trying to understand why the cache hits percentage is so low with a single PC seeking the same web pages over and over again - with some reboots in between.

I do believe there was a change not too long ago to change the max and min time to live inside the conf file. This should change your testing as in my understanding, but may be worth a review.
“Change 'cache-max-ttl: 21600' and 'cache-min-ttl: 5 to 14400/1200'”

I see the default cache-max-ttl: is 86,400 [24 hrs] - would that not work better for a chart of hits over a 24 hr period?
Finally - do you agree that the actual cache hits are as per Table A of the spreadsheet I enclosed? Those cached DNS records were indeed gathered in a 24 hour period.

Thanks for your consideration.
 
I just installed the dev branch with uf dev and i get this:
Code:
A:Option ==> s


total.num.queries=11                    total.num.expired=0                     total.requestlist.exceeded=0            total.tcpusage=0
total.num.queries_ip_ratelimited=0      total.num.recursivereplies=9            total.requestlist.current.all=0         msg.cache.count=636
total.num.cachehits=2                   total.requestlist.avg=0                 total.requestlist.current.user=0        rrset.cache.count=782
total.num.cachemiss=9                   total.requestlist.max=0                 total.recursion.time.avg=0.238458       infra.cache.count=94
total.num.prefetch=0                    total.requestlist.overwritten=0         total.recursion.time.median=0.229376    key.cache.count=26



Summary: Cache Hits success=18.00%

thread0.num.queries=6                   thread0.num.expired=0                   thread0.requestlist.exceeded=0          thread0.tcpusage=0
thread0.num.queries_ip_ratelimited=0    thread0.num.recursivereplies=4          thread0.requestlist.current.all=0       msg.cache.count=636
thread0.num.cachehits=2                 thread0.requestlist.avg=0               thread0.requestlist.current.user=0      rrset.cache.count=782
thread0.num.cachemiss=4                 thread0.requestlist.max=0               thread0.recursion.time.avg=0.219783     infra.cache.count=94
thread0.num.prefetch=0                  thread0.requestlist.overwritten=0       thread0.recursion.time.median=0.218453  key.cache.count=26



Thread 0: Cache Hits success=33.00%
thread1.num.queries=5                   thread1.num.expired=0                   thread1.requestlist.exceeded=0          thread1.tcpusage=0
thread1.num.queries_ip_ratelimited=0    thread1.num.recursivereplies=5          thread1.requestlist.current.all=0       msg.cache.count=636
thread1.num.cachehits=0                 thread1.requestlist.avg=0               thread1.requestlist.current.user=0      rrset.cache.count=782
thread1.num.cachemiss=5                 thread1.requestlist.max=0               thread1.recursion.time.avg=0.253398     infra.cache.count=94
thread1.num.prefetch=0                  thread1.requestlist.overwritten=0       thread1.recursion.time.median=0.240299  key.cache.count=26



Thread 1: Cache Hits success=0.00%
Yup, I changed the screen display to display in detail the stats for each thread.

So apart from being a possibly pointless addition, the point I was trying to prove is that there is ONLY 1 cache, that is referenced by each thread...do you agree?
 
Code:
A:Option ==> s


total.num.queries=81                    total.num.expired=7                     total.requestlist.exceeded=0            total.tcpusage=0
total.num.queries_ip_ratelimited=0      total.num.recursivereplies=53           total.requestlist.current.all=0         msg.cache.count=1065
total.num.cachehits=28                  total.requestlist.avg=0.0461538         total.requestlist.current.user=0        rrset.cache.count=1249
total.num.cachemiss=53                  total.requestlist.max=1                 total.recursion.time.avg=0.189435       infra.cache.count=335
total.num.prefetch=12                   total.requestlist.overwritten=0         total.recursion.time.median=0.150435    key.cache.count=80



Summary: Cache Hits success=34.00%

thread0.num.queries=41                  thread0.num.expired=6                   thread0.requestlist.exceeded=0          thread0.tcpusage=0
thread0.num.queries_ip_ratelimited=0    thread0.num.recursivereplies=20         thread0.requestlist.current.all=0       msg.cache.count=1065
thread0.num.cachehits=21                thread0.requestlist.avg=0.0344828       thread0.requestlist.current.user=0      rrset.cache.count=1249
thread0.num.cachemiss=20                thread0.requestlist.max=1               thread0.recursion.time.avg=0.203540     infra.cache.count=335
thread0.num.prefetch=9                  thread0.requestlist.overwritten=0       thread0.recursion.time.median=0.16384   key.cache.count=80



Thread 0: Cache Hits success=51.00%
thread1.num.queries=40                  thread1.num.expired=1                   thread1.requestlist.exceeded=0          thread1.tcpusage=0
thread1.num.queries_ip_ratelimited=0    thread1.num.recursivereplies=33         thread1.requestlist.current.all=0       msg.cache.count=1065
thread1.num.cachehits=7                 thread1.requestlist.avg=0.0555556       thread1.requestlist.current.user=0      rrset.cache.count=1249
thread1.num.cachemiss=33                thread1.requestlist.max=1               thread1.recursion.time.avg=0.180887     infra.cache.count=335
thread1.num.prefetch=3                  thread1.requestlist.overwritten=0       thread1.recursion.time.median=0.13703   key.cache.count=80



Thread 1: Cache Hits success=17.00%
Yup, I changed the screen display to display in detail the stats for each thread.

So apart from being a possibly pointless addition, the point I was trying to prove is that there is ONLY 1 cache, that is referenced by each thread...do you agree?
Yes i agree and can see that now.
 
So apart from being a possibly pointless addition, the point I was trying to prove is that there is ONLY 1 cache, that is referenced by each thread...do you agree?
Yes i agree and can see that now.

Quite interested going in this direction on my 86U...
Code:
A:Option ==> s


total.num.queries=43            total.num.expired=4            total.requestlist.exceeded=0        total.tcpusage=0
total.num.queries_ip_ratelimited=0    total.num.recursivereplies=36        total.requestlist.current.all=0        msg.cache.count=872
total.num.cachehits=7            total.requestlist.avg=0.225        total.requestlist.current.user=0    rrset.cache.count=3008
total.num.cachemiss=36            total.requestlist.max=3            total.recursion.time.avg=0.257223    infra.cache.count=40
total.num.prefetch=4            total.requestlist.overwritten=0        total.recursion.time.median=0.177883    key.cache.count=23



Summary: Cache Hits success=16.00%

thread0.num.queries=19            thread0.num.expired=4            thread0.requestlist.exceeded=0        thread0.tcpusage=0
thread0.num.queries_ip_ratelimited=0    thread0.num.recursivereplies=14        thread0.requestlist.current.all=0    msg.cache.count=872
thread0.num.cachehits=5            thread0.requestlist.avg=0.166667    thread0.requestlist.current.user=0    rrset.cache.count=3008
thread0.num.cachemiss=14        thread0.requestlist.max=2        thread0.recursion.time.avg=0.213729    infra.cache.count=40
thread0.num.prefetch=4            thread0.requestlist.overwritten=0    thread0.recursion.time.median=0.131072    key.cache.count=23



Thread 0: Cache Hits success=26.00%
thread1.num.queries=24            thread1.num.expired=0            thread1.requestlist.exceeded=0        thread1.tcpusage=0
thread1.num.queries_ip_ratelimited=0    thread1.num.recursivereplies=22        thread1.requestlist.current.all=0    msg.cache.count=872
thread1.num.cachehits=2            thread1.requestlist.avg=0.272727    thread1.requestlist.current.user=0    rrset.cache.count=3008
thread1.num.cachemiss=22        thread1.requestlist.max=3        thread1.recursion.time.avg=0.284901    infra.cache.count=40
thread1.num.prefetch=0            thread1.requestlist.overwritten=0    thread1.recursion.time.median=0.224695    key.cache.count=23



Thread 1: Cache Hits success=8.00%
 
Quite interested going in this direction on my 86U...
Code:
A:Option ==> s


total.num.queries=43            total.num.expired=4            total.requestlist.exceeded=0        total.tcpusage=0
total.num.queries_ip_ratelimited=0    total.num.recursivereplies=36        total.requestlist.current.all=0        msg.cache.count=872
total.num.cachehits=7            total.requestlist.avg=0.225        total.requestlist.current.user=0    rrset.cache.count=3008
total.num.cachemiss=36            total.requestlist.max=3            total.recursion.time.avg=0.257223    infra.cache.count=40
total.num.prefetch=4            total.requestlist.overwritten=0        total.recursion.time.median=0.177883    key.cache.count=23



Summary: Cache Hits success=16.00%

thread0.num.queries=19            thread0.num.expired=4            thread0.requestlist.exceeded=0        thread0.tcpusage=0
thread0.num.queries_ip_ratelimited=0    thread0.num.recursivereplies=14        thread0.requestlist.current.all=0    msg.cache.count=872
thread0.num.cachehits=5            thread0.requestlist.avg=0.166667    thread0.requestlist.current.user=0    rrset.cache.count=3008
thread0.num.cachemiss=14        thread0.requestlist.max=2        thread0.recursion.time.avg=0.213729    infra.cache.count=40
thread0.num.prefetch=4            thread0.requestlist.overwritten=0    thread0.recursion.time.median=0.131072    key.cache.count=23



Thread 0: Cache Hits success=26.00%
thread1.num.queries=24            thread1.num.expired=0            thread1.requestlist.exceeded=0        thread1.tcpusage=0
thread1.num.queries_ip_ratelimited=0    thread1.num.recursivereplies=22        thread1.requestlist.current.all=0    msg.cache.count=872
thread1.num.cachehits=2            thread1.requestlist.avg=0.272727    thread1.requestlist.current.user=0    rrset.cache.count=3008
thread1.num.cachemiss=22        thread1.requestlist.max=3        thread1.recursion.time.avg=0.284901    infra.cache.count=40
thread1.num.prefetch=0            thread1.requestlist.overwritten=0    thread1.recursion.time.median=0.224695    key.cache.count=23



Thread 1: Cache Hits success=8.00%
I'm not a statistician, but I would say your sample is simply too small to make an informed conclusion, although 8%,26% and 16% would suggest otherwise, but you are using 2,5 and 7 hits out of relatively small number of requests, so leave it 24hrs to see if there still remains a significant difference in the figures.

I left mine for 3 hours, to allow things to settle.
 
I'm not a statistician, but I would say your sample is simply too small to make an informed conclusion, although 8%,26% and 16% would suggest otherwise, but you are using 2,5 and 7 hits out of relatively small number of requests, so leave it 24hrs to see if there still remains a significant difference in the figures.

I left mine for 3 hours, to allow things to settle.
Sure, will keep on using this version. Only wanted to give feedback that I will test it. Fore sure ist also will depend on the parameters that are set in the unbound.config.add... But its very cool that statistics can be generated now for each thread. Will surely be helpful finding the adequate adjustment in the config. Thanks!
 
The cache hit percentage in the UI is calculated hourly (at :59) and is calculated the same way as the script does it when you show stats.

Unbound tracks the number of hits and misses and total requests. It is in memory only so if you restart unbound those stats reset. This has nothing to do with the cache, these are just numbers unbound has built internally to track usage.

The calculation is simple total hits / total requests. It has always been the same with no changes.

When I boot my router, yes my number drops as there is such a low number of requests processed by then. But by the next hour it has come back up into the 80s and then grows to 90%.

That also being said, this is highly dependant on your devices and browsing habits.

I do believe there was a change not too long ago to change the max and min time to live inside the conf file. This should change your testing as in my understanding, but may be worth a review.

“Change 'cache-max-ttl: 21600' and 'cache-min-ttl: 5 to 14400/1200'”
@juched .... would using the VPN ISPs function available within unbound mess with cache hits? Normally unbound uses WAN but for those who've enabled VPN, I wonder if the cache hit % might differ...
 
Last edited:
If you only have one available outbound interface, then unbound will obviously be forced by default to use it, so explicitly BINDing unbound to the WAN interface isn't necessary.

The force BIND to WAN simply attempts to pre-empt a potential (not that anyone would notice?) performance drop for unbound DNS requests that leak via the (invariably slower) VPN Client interface.

WAN PPTP users are a $£^&*!!!! :p

However, would you mind trying to assist and diagnose why the script seemingly fails to identify the actual WAN Gateway IP for the detected 'ppp0' interface
Code:
ip route | grep ppp0
Please redact your actual WAN IP before posting.

Hi Martineau

I substituted made up values below for WAN Gateway address -

Code:
ip route | grep ppp0
gives following output

Code:
110.3.231.6 dev ppp0  proto kernel  scope link
default via 110.3.231.6  dev ppp0
 
Last edited:
Thanks @juched - the heading to the first graph on your webui stats page is headed ...
"Cache Hits % Last 24 Hours" ... so if you reboot and the stats are reset to 0 [as above] then the result represented when you update stats is in fact the % since last reboot - not over last 24 hrs?



I assume what you mean by the underlined text above is the reset to zero on restart of unbound is not resetting [clearing] the actual DNS records that have so far been cached by unbound - but just the stats numbers?



When you reboot are the existing DNS request records retained in the cache through to the restart of unbound? So when the same DNS records are requested after reboot they count as hits against the accumulated pre and post boot cache ... or count as misses if they were never in the accumulated cache?

I am just trying to understand why the cache hits percentage is so low with a single PC seeking the same web pages over and over again - with some reboots in between.



I see the default cache-max-ttl: is 86,400 [24 hrs] - would that not work better for a chart of hits over a 24 hr period?
Finally - do you agree that the actual cache hits are as per Table A of the spreadsheet I enclosed? Those cached DNS records were indeed gathered in a 24 hour period.

Thanks for your consideration.

The last 24 hours is the graph. Shows the data points collected over the past 24 hours.

The cache is retained since unbound manager saves stats in restart. But I do not believe that works during a reboot, in the case I believe the cache is reset.

But the cache builds back very quickly so unless you reboot every few hours it should still be fast.
 
That is not correct at all - a successful installation of Unbound overrides this setting. When Unbound is stopped either accidentally or commanded then this setting will allow successful resolving to your ISP's DNS servers. The problem with MartinDEE is presumably tied to the fact that his NTP server is non functional and NTP is not synced. Fix that first before you look further.
Install NTPMerlin using amtm and hopefully that will fix your NTP issue.

Just a update we put NTPMerlin on the network and have got unbound working will post info next to make sure it's working thank you so much have a great weekend
 
Last edited:
The last 24 hours is the graph. Shows the data points collected over the past 24 hours.

The cache is retained since unbound manager saves stats in restart. But I do not believe that works during a reboot, in the case I believe the cache is reset.

But the cache builds back very quickly so unless you reboot every few hours it should still be fast.

@juched - please note - I am not being critical of your stats efforts ... but believe me there is a problem and it is something relatively new [maybe the transition to unbound 1.10??].

One of the major attractions of Unbound was the performance gain it gave - a significant part of which can no doubt be attributed to its cache ability. Early adopters all confirmed HIGH cache hits.

I am utterly convinced that anyone who has done a FRESH [as in totally clean] install in the last month will not see the 90% hits you are still enjoying.

It makes no sense that a router with a single laptop client cannot get above an average of 29% in cache hits over a full 24 hours connected constantly to the router.

On my main router, which has been running for a couple of weeks and on which unbound was installed many moons ago, - I have seen a gradual decline in cache hits % from high eighties to low seventies - with no reboots and very little change in activity from the 20 devices connected.

You and @Martineau are the "sponsors" of this wonderful utility - of course you are free to apply your minds openly to the information I have provided - or to move on. I believe that the TRUE cache hit rate in my case and from the spreadsheet I provided was in fact 91.57% for the 24 hour period and not 37.37% as reflected at that time on your 24 hr graph.
 
@juched - please note - I am not being critical of your stats efforts ... but believe me there is a problem and it is something relatively new [maybe the transition to unbound 1.10??].

One of the major attractions of Unbound was the performance gain it gave - a significant part of which can no doubt be attributed to its cache ability. Early adopters all confirmed HIGH cache hits.

I am utterly convinced that anyone who has done a FRESH [as in totally clean] install in the last month will not see the 90% hits you are still enjoying.

It makes no sense that a router with a single laptop client cannot get above an average of 29% in cache hits over a full 24 hours connected constantly to the router.

On my main router, which has been running for a couple of weeks and on which unbound was installed many moons ago, - I have seen a gradual decline in cache hits % from high eighties to low seventies - with no reboots and very little change in activity from the 20 devices connected.

You and @Martineau are the "sponsors" of this wonderful utility - of course you are free to apply your minds openly to the information I have provided - or to move on. I believe that the TRUE cache hit rate in my case and from the spreadsheet I provided was in fact 91.57% for the 24 hour period and not 37.37% as reflected at that time on your 24 hr graph.


I still think that this is an isolated issue affecting perhaps a handful of people. There may well be a common thread in those that are having low cache hit success rate. I myself had to reinstall from scratch 3 days ago. I used the one line install from Github rather than install from AMTM. I made sure that there was abolutely NO reference to ANY leftover Unbound parameters eg conf.add entries anywhere and all unbound directories were 100% erased. All the usual install parameters were ticked including gui stats , performance addons , scribe enabled , logging enabled etc. Left the memory , slabs, threads = 1 - ALL Standard. Log-queries set to no. IPV6 Not used. Only change I have from standard is edns-buffer-size = 1432 as my MTU is set at 1464.

I am consistently getting greater than 90% cache hit success rate on my RT-AC5300. Currently its 93%. Even when I had 2 threads my cache hit success rate was in low to mid 80s.

If its a calculation error in graphing I cant for the life of me understand why EVERYONE else is not seeing 30% cache hit success rate.

BTW when you go to unbound_manager advanced and press s - is the cache hit success rate
Code:
Summary: Cache Hits success=x%
the same value as posted in your Cache Hit % Last 24 Hours graph?

Perhaps you could also please post all your output from the ? command when using unbound_manager advanced
 
Last edited:
Ok so got it working but rebooting the router stops it again and all the rest of my programs so for my RT-AX88U Unbound Manager is unusable as soon as I uninstalled it and rebooted the router all the other programs started fine

Does anyone else have this problem?
 
Ok so got it working but rebooting the router stops it again and all the rest of my programs so for my RT-AX88U Unbound Manager is unusable as soon as I uninstalled it and rebooted the router all the other programs started fine

Does anyone else have this problem?

You need to post the output from your syslog to be able to offer any reasonable guess as to whats happening on your router.
When you say that all the rest of your programs are not working and neither is Unbound - it again points to your NTP server going AWOL. But you need to read your syslog for error messages to fault find.
 
I still think that this is an isolated issue affecting perhaps a handful of people. There may well be a common thread in those that are having low cache hit success rate. I myself had to reinstall from scratch 3 days ago. I used the one line install from Github rather than install from AMTM. I made sure that there was abolutely NO reference to ANY leftover Unbound parameters eg conf.add entries anywhere and all unbound directories were 100% erased. All the usual install parameters were ticked including gui stats , performance addons , scribe enabled , logging enabled etc. Left the memory , slabs, threads = 1 - ALL Standard. Log-queries set to no. IPV6 Not used. Only change I have from standard is edns-buffer-size = 1432 as my MTU is set at 1464.

I am consistently getting greater than 90% cache hit success rate on my RT-AC5300. Currently its 93%. Even when I had 2 threads my cache hit success rate was in low to mid 80s.

If its a calculation error in graphing I cant for the life of me understand why EVERYONE else is not seeing 30% cache hit success rate.

BTW when you got to unbound_manager advanced and press s - is the cache hit success rate
Code:
Summary: Cache Hits success=x%
the same value as posted in your Cache Hit % Last 24 Hours graph?

Perhaps you can post all your output from the ? command when using unbound_manager advanced

MANY thanks Joe - good to hear. I will now replicate your install method [save for MTU] and see if that produces better results. I remain puzzled by the declining %hit on two other routers I look after - and which have not had fresh installs and no reboots.
 
Kernol
Please post your ? command and s command when you get a chance - mine is below
PS since I use Diversion I am not using adblock

Code:
A:Option ==> ?

        Version=3.09
        Local                                           md5=f99c48a3a5e7393490b6b21919b62a1a
        Github                                          md5=f99c48a3a5e7393490b6b21919b62a1a
        /jffs/addons/unbound/unbound_manager.md5        md5=f99c48a3a5e7393490b6b21919b62a1a

        Router Configuration recommended pre-reqs status:

        [✔] Swapfile=2097148 kB
        [✔] DNS Filter=ON
        [✔] DNS Filter=ROUTER
        [✔] WAN: Use local caching DNS server as system resolver=NO
        [✔] Entware NTP server is running
        [✔] Enable DNS Rebind protection=NO
        [✔] Enable DNSSEC support=NO
        [✖] Warning Skynet's Country BAN feature is currently ACTIVE and may significantly reduce unbound performance and in some cases block sites

        Options: Auto Reply='y' for User Selectable Options ('1 4 5') unbound Logging,Performance Tweaks,Firefox DoH

        [✔] unbound Logging
        [✔] unbound CPU/Memory Performance tweaks
        [✔] Firefox DNS-over-HTTPS (DoH) DISABLE/Blocker
        [✔] Router Graphical GUI statistics TAB installed
        [✔] unbound-control FAST response ENABLED
        [✔] DNS Firewall ENABLED

        unbound Memory/Cache:

        'key-cache-size:'       8388608 (8.00 MB)
        'msg-cache-size:'       8388608 (8.00 MB)       6% used 555365  (542.35 KB)
        'rrset-cache-size:'     16777216 (16.00 MB)     10% used 1775426        (1.69 MB)

        System Memory/Cache:

                     total       used       free     shared    buffers     cached
        Mem:        515184     425944      89240          0       3004      32912
        -/+ buffers/cache:     390028     125156
        Swap:      2097148      77412    2019736

Code:
A:Option ==> s


total.num.queries=33102                 total.num.expired=1775                  total.requestlist.exceeded=0            total.tcpusage=0
total.num.queries_ip_ratelimited=0      total.num.recursivereplies=2101         total.requestlist.current.all=0         msg.cache.count=2921
total.num.cachehits=31001               total.requestlist.avg=1.03428           total.requestlist.current.user=0        rrset.cache.count=8567
total.num.cachemiss=2101                total.requestlist.max=51                total.recursion.time.avg=0.322397       infra.cache.count=2618
total.num.prefetch=2392                 total.requestlist.overwritten=0         total.recursion.time.median=0.208716    key.cache.count=487

Summary: Cache Hits success=93.00%
 
Last edited:

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top