Run in a chroot
Drop privileges to
Address/interface to listen on
Use 0.0.0.0 to listen on all
interface: 127.0.0.1 # interface: 192.168.1.1
We also have the option of specifying the outgoing interface
This is applicable if you have multiple links to the internet
and wish to restrict vpn traffic to a particular one
Types of queries to accept
do-ip6: no do-ip4: yes do-udp: yes do-tcp: yes
Specify the CIDR blocks to allow or deny
On an internet reachable host, use iptables too
access-control: 127.0.0.0/8 allow access-control: 10.0.0.0/8 allow access-control: 192.168.0.0/16 allow access-control: 172.16.0.0/12 allow access-control: 0.0.0.0/0 refuse
Next, we manually download the root hints
"wget -qO root.hints https://www.internic.net/domain/named.cache"
The trust anchors are taken care of by the unbound-anchor utility. It runs a cron job to ensure they are up-to-date
What are trust anchors? In DNSSEC, there is a chain of trust.
The parent zone must have records that verify the child zone
These are generally DS records which are hashes of the Zone signing key
A traversal works like this
DS records in root verify the DNSKEYs for .net
DS records in .net verify the DNSKEYs for etherarp.net
The DNSKEYs for etherarp.net verify the resource records.
So the chain of trust needs a starting point,
this key provided by ICANN is used to verify the root zone
Hide our peers from seeing info about this instance
hide-identity: yes hide-version : yes
Will trust glue only if it is within the servers authority.
Suppose I want to set ns.etherarp.net as the NS for etherarp.net,
then I need to set recotd 'ns' as a glue record
A zone we expect to be secure only responds with non-secure/conventional DNS. What to do?
By default, we repudiate the non-secure records, rendering the domain unreachable. This is the same behavior as receiving dnssec data that cannot be validated by the anchor
If set to no, it just accepts the unverified data at face value
behaving as though it was a conventional dns zone
Keep this set to yes
When sending a query to the authority NS,
PeRtUrB cAsEof rhw queries.
Best to leave this set to "no" (default) as it can cause unreliability
Performance and computational options.
If you don't have a multicore/hyperthreaded machine (e.g. running on embedded router) then set num-threads to 1 (disable multithreading )
The slabs must take a value approximately double the number of threads
this value must be a power of 2
num-threads: 4 msg-cache-slabs: 2 rrset-cache-slabs: 2 key-cache-slabs: 2 infra-cache-slabs: 2
The RRset cache record values like A,NS
These values are appropriate for a desktop or server
On a small embedded device like a router, use values like 2m
Message cache size.
Msg cache contains metadata, things like AD bit etc
This should be 1/2 the size of the rrset-cache
Prefetch the message cache
When popular entries are about to expire, we
Override records with short TTL (time to live)
we do --not-- update records below this time
Don't make it longer than ~300s, you may get stale records
Override records with long TTL
Don't keep cached records for longer than 30h (10800)
Suppose you have a special dns provider for accessing US netflix
You can set a forward zone here so that queries to netflix are selectively forwarded to that server
forward-zone: name: "netflix.com" forward-addr: 198.51.100.0/24
There is also a type of zone known as a stub zone.
A forward zone is expected to be recursive and can completely answer queries
A stub zone points to the 'next hop'
stub-zone: name: "2.4.10.in-addr.arpa." stub-addr: "10.4.0.53"
local-data: "gateway IN A 192.168.1.1" local-data: "foo-pc IN A 192.168.1.2" local-data: "bar-pc IN A 192.168.1.3" local-data-ptr: "gateway IN A 192.168.1.1"
We can split our config into multiple files.
Let's add a file containing local records to block ad domains
Forward along to another server.
If you don't want to look up recursive queries yourself
forward-zone: name: "." forward-addr: 188.8.131.52 forward-addr: 184.108.40.206