Maintained by: NLnet Labs

New to Unbound

Oscar Ricardo Silva
Thu Mar 16 16:20:36 CET 2017


We currently run several BIND recursive, caching servers, with anycast 
and are looking to diversify with other DNS packages. This is my first 
exposure to Unbound and I'm soliciting any tips/tricks/links that might 
help in converting some of these BIND servers or for general 
use/configuration. So far I've been reading: "How to Setup", "How to 
Optimise", "How to Statistics", as well as other documents but we all 
know there's always those "gotchas", those config options/tricks, that 
you only learn once you've used something for awhile.


1. Redhat Enterprise Linux (kernel 3.10)
2. OSPF (via quagga) for anycast
3. BIND 9 (built from source)

Here's what we're doing with our servers:

1. BIND runs in a chroot environment. Should I continue this with 
Unbound or is this not as much an issue?

2. Minimal responses to queries (I see how Unbound does that)

3. Resolve RFC1918 addresses (we currently forward those to our 
authoritative servers and I believe I see how to do this with Unbound)

4. Gathering statistics and graphing queries per second (not sure how to 
accomplish this)

5. Logging queries (I see how this is done)

6. keep multiple logs to help with troubleshooting (queries in one log, 
errors in another, etc)

7. Handle approx. 3,000 queries per second

Right now I've downloaded, compiled, and installed Unbound 1.6.1

Some specific questions:

1. Can I define a specific set of name servers to forward queries to and 
then use that "set" name in each forward statement? This way if anything 
changes I only need to change the entries in the set instead of in each 
config line

2. Can I separate out logs into different files. For example, query logs 
into one file, errors into another, etc.

3. Regarding the "ip-ratelimit" config option: just to be sure, this 
limits the number of queries accepted FROM AN IP ADDRESS? Sometimes 
devices are setup without name services caching (ex. nscd, dnsmasq) and 
our servers get flooded with thousands of queries per second. This 
feature is marked as experimental but is it stable or should I avoid it 
for now?

4. For resolving RFC1918 addresses, should I use forward or stub zones? 
Sometimes zones are delegated from the authoritative 
servers and so the recursive server may get back delegation information