Anyone using Knot-resolver?

Thank you for this clear explanation.

As you can see in the above published configurations, both knot-resolver and unbound have the necessary configuration options to store a copy of the root zone locally. I assume that this implies the information for the .com domain only is retrieved when the resolvers (unbound and knot-resolver) refresh that information.

Nice to know. I always changed the values in the dnsmasq source, before compiling it, as the values can not be changed at runtime. Any idea why Simon choose these aggressive values?

1 Like

So then what's your opinion on the Unbound guide in the Pi-Hole docs, which sets min and max TTL in the config? Should that be removed?

Well, in this case extend my example to something that is not the root zone, e.g., with its many subdomains.


Probably, we will discuss this internally.

1 Like

When compiling unbound from source, unbound comes with a unbound.conf, listing (all?) possible settings.

Partial content of this file:

	# the time to live (TTL) value lower bound, in seconds. Default 0.
	# If more than an hour could easily give trouble due to stale data.
	# cache-min-ttl: 0

	# the time to live (TTL) value cap for RRsets and messages in the
	# cache. Items are not cached for longer. In seconds.
	# cache-max-ttl: 86400

	# the time to live (TTL) value cap for negative responses in the cache
	# cache-max-negative-ttl: 3600

I always used to run Knot without min/max TTL becuase I think it handles that on its own by caching popular domains. The manual says:

Get or set minimum cache TTL. Any entry inserted into cache with TTL lower than minimal will be overridden to minimum TTL. Forcing TTL higher than specified violates DNS standards, use with care.

Yes, this information is also contained in the unbound.conf man page.

Everyone of the team agreed to remove the lines, however, I'm traveling and it will take some time until I can do it.

After running both unbound and knot-resolver for a week now, both with cache settings:

unbound: cache-min-ttl: 3600 - cache-max-ttl: 86400
knot-resolver: cache.min_ttl(3600) - cache.max_ttl(86400)

knot-resolver appears to be the preferred (fastest response) resolver by pihole-FTL.

knot-resolver-IPv4 25%
knot-resolver-IPv6 20.5%
unbound-IPv4 6.5%
unbound IPv6 10.7%

1 Like

I'm experiencing the exact opposite which is weird, I really expected Knot to be faster. Not sure why, maybe something is wrong with my setup. Could you please post your Knot-config again?


The only thing I added to this version are the cache-ttl (knot-resolver: cache.min_ttl(3600) - cache.max_ttl(86400)) settings you suggested.

Ah ok, thanks! I removed my cache-settings from both Unbound and Knot... interesting. I think Knot needs a bit of time to predict the popular domains though...hmmm.

I added the cache settings to knot resolver because:

  • you were right to add them to knot-resolver, I forgot they also are a part of the unbound configuration.
  • I never had any problems with these cache settings in unbound.
  • I think you can only get in trouble with these cache settings if you visit a site, using a DNS name that depends on dynamic DNS. Apparently, since I have no problems, that's NOT an issue for me.

Thanks, I'll have to do some more testing. :slight_smile:

1 Like

Just a simple question from a rookie: Is there a guide available how to set up PiHole with unbound AND Knot-resolver? Currently I´m running PiHole on an ARMbian/Rock64 platform and it works like a charm. I like the idea of having a backup solution for unbound but my skills are limited how to set up Pihole using both; unbound and knot-resolver. All these different aspects getting me confused: unbound, knot-resolver, cloudflared, stubby, etc...
If someone feels like pointing me to the right direction please don´t hesistate. Thanks in advance.

Use the Pi-Hole unbound guide, and then use whatever knot resolver guides exist on the internet and put knot on a port other than 53 or 5353, and you are set.

Cloudflared and Stubby are different methods of encrypting DNS traffic to an upstream server. Unbound and knot are usually run in recursive mode, doing the same thing as the upstream servers (i.e. directly querying the authoritative name servers).

1 Like

Just setup unbound, preferably the compiled version (the instructions don't work if you already installed unbound using apt-get)
Configure unbound to use a unique IP and port, for example IP port 5551.
Look at the configuration example listed earlier in this topic.
After completing the configuration, restart unbound and check if the resolver responds correctly by entering:

dig @ -p 5551 +dnssec

Now install knot-resolver, using the instructions here. Select your platform and follow the instructions under Add repository and install manually
Configure knot-resolver to use a unique IP and port, for example IP port 5552.
Again, look at the configuration example listed earlier in this topic.
After completing the configuration, restart knot-resolver and check if the resolver responds by entering:

dig @ -p 5552 +dnssec

Edit /etc/dnsmasq.d/01-pihole.conf and remove all server= entries.
Create a new file /etc/dnsmasq.d/04-servers.conf, content (as per provided examples):


restart pihole-FTL.


The changes made to /etc/dnsmasq.d/01-pihole.conf will be undone by pihole -up and pihole -r, so ensure the server entries are removed from this file after upgrading or reconfiguring.

1 Like

I run four instances of unbound on four separate Pi/Pi-Hole installs and have not had a problem with unbound on any of them. As a result, I have not found that a backup is necessary.

1 Like

But as a previous commenter noted, unbound was faster for them. So, mileage may vary, But either way, in my opinion no backup is required as either is a reliable DNS server.

Well, if you use the settings page instead of editing the files directly, then subsequent calls to pihole commands will know what you want and won't reset the settings.

I concur. Thanks for pointing this out. Everyone is free to set this up if they feel they need it, but it should be made clear that it is typically not needed. Work that can be avoided, one might say.

1 Like

Don't stop with just Knot and Unbound, try BIND, PowerDNS and the others as well.

1 Like