Unbound unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server) - General questions / discussion thread 2

[L&LD]

@raion969, with your very specific usage, you will have to tell us.

 

[SomeWhereOverTheRainBow]

yea but the blocking of ads with diversion dont help gaming performance maybe ?

just wanted to know if it ts good to use the ad blocking service in unbound or to use diversion ? do they both do the same job, same good ?

I find it easier to use diversion for ad blocking. Unbound can adblock, but on the router, it is very limited because of the routers limited resources.

 

[Milan]

I find it easier to use diversion for ad blocking. Unbound can adblock, but on the router, it is very limited because of the routers limited resources.

I don't see the difference in ad blocking with diversion or unbound. In both cases ads are gone ...
I am playing games too and i don't see any lags (fallout76, WoW ..)

 

[raion969]

i mostly play cs go and just want best performance lowst latency and so on ^^ i juse flexqos, amtm, unbound,´....

or are there any tweaks/scripts that i can do to improve performance?

 

[heysoundude]

has anyone posted a "how-to" for DoT setup in unbound? what are the pros and cons? I'd rather stay away from CloudFlare and Google if possible - are the Auth DNS doing DoT?

 

[Treadler]

has anyone posted a "how-to" for DoT setup in unbound? what are the pros and cons? I'd rather stay away from CloudFlare and Google if possible - are the Auth DNS doing DoT?

There are directions in the ‘original’ Unbound thread I think.

Using DoT with Unbound? Might as well use the native Merlin DoT & be done with it, because the Auth DNS don’t do DoT. (DNSSEC only), & the whole point of Unbound is not to use a public resolver.

 

[heysoundude]

There are directions in the ‘original’ Unbound thread I think.

Using DoT with Unbound? Might as well use the native Merlin DoT & be done with it, because the Auth DNS don’t do DoT. (DNSSEC only), & the whole point of Unbound is not to use a public resolver.

I need to re-read about stubby/DoT and unbound to get the picture clear in my head again. I asked so to start the various bits that ARE there to re-coalesce...use it or lose it.

 

[juched]

Found that when I use dnsmasq disable (so unbound is the listener on port 53), my guestnetwork (192.168.101.x) for example doesn't get a DNS. When I added the dhcp-option 6 to give 192.168.101.1 as the DNS, unbound doesn't reply. I needed to add:

interface: 192.168.101.1

to my unbound.conf.addgui file and now it responds. Perhaps the default conf conf be updated to automatically include 101 and 102 to the conf so it works for others. Just a suggestion... perhaps I am missing something.

Also found that when using a custom DNS, the unbound.postconf script messes up the dhcp-option 6. I am playing with Adguard and using unbound to resolve the adguard lookups needed. This gives a nicer frontend, but does introduce a hop.

 

[juched]

Back to running Merlin after a few weeks of trying out the latest official beta to see if guest network issues are fixed (they aren’t).

To tie me over during this time I setup Adguard Home as a local DNS forwarder and was using it to test quad 9, cloud flare and Canadian Shield. All good DNS services, and still had ad filtering similar to diversion or unbound can provide.

The cool part is that with Adguard you can clearly see DNS performance and I was very happy with 20-40ms response for most requests, some as low as 16ms and some has high as 250ms. This is where using parallel requests and taking the first response was cool to try.

Anyway, back on Merlin and unbound and decided to turn off ad blocking in unbound and continue to test with Adguard but using my unbound as the DNS. My local unbound is regularly hitting sub-1ms response times with most at 1ms.
This confirms the snapper feeling when browsing.

That being said there are times when a new lookup was needed for a new domain or one which expired from the cache and I would see 200-300ms ( or more) to resolve. Unbound is configured to return expired results which helps but only expired in the last 60 minutes. If you have something which polls longer than that then you will have a delay. Larger DNS servers don’t have this issue as they get much higher volume which keeps things being renewed more quickly.

I decided to change the setting for how old an expired result needs to be to still return it (note it does issue an update at the same time so it should get fresh data in parrellel) to 3 days. This way things that poll on longer times can be quick and still not grow the cache forever. I did this based on the official docs suggesting 1 to 3 days.

serve-expired-ttl: <seconds>
Limit serving of expired responses to configured seconds after
expiration. 0 disables the limit. This option only applies when
serve-expired is enabled. A suggested value per RFC 8767 is
between 86400 (1 day) and 259200 (3 days). The default is 0.

I suggest for our smaller loaded DNS servers to use 1to 3 days for that setting instead of just 60 minutes.

 

[heysoundude]

I've made a mental note to pay attention to this when I re-do my router at v386 (Final, Release) upgrade.
I showed my result graph (with that HUGE 0-1usec spike) to my IT-dept at a utility cousin and I could see some lights start flashing behind his eyes. dunno if it's for his servers at home or if he has a work application (or both) but I suspect he's going to be digging deeper into unbound

 

[Milan]

Back to running Merlin after a few weeks of trying out the latest official beta to see if guest network issues are fixed (they aren’t).

To tie me over during this time I setup Adguard Home as a local DNS forwarder and was using it to test quad 9, cloud flare and Canadian Shield. All good DNS services, and still had ad filtering similar to diversion or unbound can provide.

The cool part is that with Adguard you can clearly see DNS performance and I was very happy with 20-40ms response for most requests, some as low as 16ms and some has high as 250ms. This is where using parallel requests and taking the first response was cool to try.

Anyway, back on Merlin and unbound and decided to turn off ad blocking in unbound and continue to test with Adguard but using my unbound as the DNS. My local unbound is regularly hitting sub-1ms response times with most at 1ms.
This confirms the snapper feeling when browsing.

That being said there are times when a new lookup was needed for a new domain or one which expired from the cache and I would see 200-300ms ( or more) to resolve. Unbound is configured to return expired results which helps but only expired in the last 60 minutes. If you have something which polls longer than that then you will have a delay. Larger DNS servers don’t have this issue as they get much higher volume which keeps things being renewed more quickly.

I decided to change the setting for how old an expired result needs to be to still return it (note it does issue an update at the same time so it should get fresh data in parrellel) to 3 days. This way things that poll on longer times can be quick and still not grow the cache forever. I did this based on the official docs suggesting 1 to 3 days.


I suggest for our smaller loaded DNS servers to use 1to 3 days for that setting instead of just 60 minutes.

i set this to one day and now surprisingly rate is about 97 %

 

[Ubimo]

Where can I also set this?

 

[JaimeZX]

Well, I set mine to 24 hours, and after 24 hours I have gone from 73% to 86%.

Where can I also set this?

$ cd /tmp/mnt/KingstonScript/entware/var/lib/unbound [Note you'll have to select your drive and not mine.]
$ nano unbound.conf

(scroll waaaay down)

change

serve-expired-ttl: 86400

The number is expiry time in seconds.

ctrl_x, [Y]es

Then, presumably reboot? I did it shortly before my automatic weekly reboot anyway so I just left it from there...

 

[juched]

Well, I set mine to 24 hours, and after 24 hours I have gone from 73% to 86%.



$ cd /tmp/mnt/KingstonScript/entware/var/lib/unbound
$ nano unbound.conf

(scroll waaaay down)

change

serve-expired-ttl: 86400

The number is expiry time in seconds.

ctrl_x, [Y]es

Then, presumably reboot? I did it shortly before my automatic weekly reboot anyway so I just left it from there...

No need to reboot, but will need restart unbound.

Or, you can use advanced mode and change it in memory using the command:

"ox serve-expired-ttl 86400"

 

[New2This]

I have changed some of my settings like @L&LD did back in the original forum , wow. What a difference, I have mine set for 86400-ttl

 

[heysoundude]

ok, while we're back to looking at .conf files, does anyone have any insight into the ip-ratelimit setting?
does it make a difference for our purposes?

https://man.linuxreviews.org/man5/unbound.conf.5.html offers food for thought:

ip-ratelimit: <number or 0>Enable global ratelimiting of queries accepted per ip address. If 0, the default, it is disabled. This option is experimental at this time. The ratelimit is in queries per second that are allowed. More queries are completely dropped and will not receive a reply, SERVFAIL or otherwise. IP ratelimiting happens before looking in the cache. This may be useful for mitigating amplification attacks.

setting a 1 seems about right - 1 query of unbound's cache per second per IP on the network before it starts looking beyond... if I'm reading things correctly.
will it take 0.25, for 1 query per IP every 4 seconds or 0.125, for one every 8sec?
would that speed something up?

 

[dave14305]

ok, while we're back to looking at .conf files, does anyone have any insight into the ip-ratelimit setting?
does it make a difference for our purposes?

https://man.linuxreviews.org/man5/unbound.conf.5.html offers food for thought:

ip-ratelimit: <number or 0>Enable global ratelimiting of queries accepted per ip address. If 0, the default, it is disabled. This option is experimental at this time. The ratelimit is in queries per second that are allowed. More queries are completely dropped and will not receive a reply, SERVFAIL or otherwise. IP ratelimiting happens before looking in the cache. This may be useful for mitigating amplification attacks.

setting a 1 seems about right - 1 query of unbound's cache per second per IP on the network before it starts looking beyond... if I'm reading things correctly.
will it take 0.25, for 1 query per IP every 4 seconds or 0.125, for one every 8sec?
would that speed something up?

I don’t think that’s the intention of the parameter. It’s meant to prevent malicious amplification attacks, not desirable queries from your users. It also has limits when Unbound sits behind dnsmasq because all queries appear to come from 127.0.0.1 (same IP). I know I see many queries per second on my router.

 

[umd325]

I installed unbound manager through amtm. Everything is working and snappy. One question I have though is after installing the unbound stats GUI, the pie chart shows a slice with 'Server failed to complete the DNS request.' Just wondering if that is normal. The unbound statistics report below the pie chart seems ok.

 

[heysoundude]

I don’t think that’s the intention of the parameter. It’s meant to prevent malicious amplification attacks, not desirable queries from your users. It also has limits when Unbound sits behind dnsmasq because all queries appear to come from 127.0.0.1 (same IP). I know I see many queries per second on my router.

hmmm, I was thinking it was more of a scheduling device -QoS for the DNS server- but I failed to take dnsmasq into account, so that's a valid point.
however...you don't truly know limits until you push things to breaking, do you? Maybe I'll mess with it before I flash the release of 386.1

 

[Martineau]

I installed unbound manager through amtm. Everything is working and snappy. One question I have though is after installing the unbound stats GUI, the pie chart shows a slice with 'Server failed to complete the DNS request.' Just wondering if that is normal. The unbound statistics report below the pie chart seems ok.

View attachment 29189

The Pie chart is representing the unbound statistics variable num.answer.rcode.SERVFAIL

Even with only a small number of DNS queries (3798), my system shows 58 resulted in SERVFAIL. - 1.5% failure

e  = Exit Script [?]

A:Option ==> s rcode

total.num.queries=3798              total.num.expired=1584              total.requestlist.exceeded=0           total.tcpusage=0
total.num.queries_ip_ratelimited=0  total.num.recursivereplies=630      total.requestlist.current.all=0        msg.cache.count=1460
total.num.cachehits=3168            total.requestlist.avg=8.33783       total.requestlist.current.user=0       rrset.cache.count=3331
total.num.cachemiss=630             total.requestlist.max=153           total.recursion.time.avg=5.145098      infra.cache.count=1579
total.num.prefetch=1667             total.requestlist.overwritten=0     total.recursion.time.median=0.0737925  key.cache.count=181

Summary: Cache Hits success=83.00%

num.answer.rcode.NOERROR=3747    num.answer.rcode.SERVFAIL=58    num.answer.rcode.NOTIMPL=0    num.answer.rcode.nodata=651
num.answer.rcode.FORMERR=0       num.answer.rcode.NXDOMAIN=11    num.answer.rcode.REFUSED=0

If you enable unbound logging you can see which requests result in SERVFAIL

e.g. see the following post for methods to investigate

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

Just got home now and pushed another update. Everything is working fine now :)

www.snbforums.com