# unbound



## yhq_34 (Apr 10, 2017)

Hi;
I choose unbound as local cache dns server in freebsd.
but it didn't work. what should I modify to make it work?
resolv.conf

```
# nameserver 8.8.8.8
options edns0
nameserver 127.0.0.1
```
unbound.conf

```
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
    username: unbound
    directory: /var/unbound
    chroot: /var/unbound
    pidfile: /var/run/local_unbound.pid
    auto-trust-anchor-file: /var/unbound/root.key

include: /var/unbound/forward.conf
include: /var/unbound/lan-zones.conf
include: /var/unbound/control.conf
include: /var/unbound/conf.d/*.conf
```
forward.conf

```
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
forward-zone:
    name: .
    forward-addr: 8.8.8.8
```


----------



## yhq_34 (Apr 10, 2017)

I tried your conf, still cannot resolve. 

```
Host name lookup failure
```


----------



## Deleted member 9563 (Apr 10, 2017)

I couldn't get local `unbound` to work either, but that was a while back. I find `bind9` works without much effort and there's a lot of documentation for any situation, so that's what I use on all my DNS servers now. I'm actually a little taken aback that something in the base system does not work as advertised.


----------



## ShelLuser (Apr 10, 2017)

Have you checked unbound.conf(5)?

I'm not fully familiar with Unbound because I use my own DNS server (running on Bind and it also hosts local private domains), but after I tried it on my laptop by setting up the example configuration as mentioned in the manual page things simply worked as expected. So a `dig @127.0.0.1 google.com` got me the expected results.

From a quick peek in /etc/defaults/rc.conf I'd assume that the one thing you need is to add:


```
local_unbound_enable="YES"
```
... to /etc/rc.conf and then starting the whole thing using `# service local_unbound start` (or after reboot).

When I do this I see several files being generated in /var/unbound yet things keep working as expected on my end. This is on FreeBSD 11 by the way.

Is it possible that a firewall is getting in your way?


----------



## ronaldlees (Apr 11, 2017)

I always start with the most simple configuration file I can make work, and add complicated things later. I usually temporarily _comment out_ the include files in the example setup, and try to make unbound work without them as a first measure. I can always add those _included_ things into the config later, after the basic setup works. AFAIK unbound uses the default dns (in my case the gateway) for yet-uncached queries if nothing else is specified.  There's an "interfaces" section, and the man page says that the interface defaults to 127.0.0.1 if nothing is specified.  However; I specified the interface explicitly in my configuration, IIRC.

I usually set the following ip4/ip6 udp/tcp options.  The values I choose depends on whether or not I have ipv6 enabled (usually yes on FreeBSD, but no on some other OSes). Actually ipv6 (AAAA) queries can be made with ipv4, but I seem to have noticed some idiosyncracies related to that.  It could be (don't know, but suspect) that unbound considers the status of the local ipv6 stack before caching those kinds of queries. In other words, one may want to play with these settings:


_do-ip6_: yes
_do-ip4_: yes

_do-udp_: yes
_do-tcp_: no
I'm not the expert in this crowd.  I'm just tossing out some configs that worked for me  

When I want to use the_ unbound-control_ monitoring tool, I need to set up the auth keys.  I think the utility that does that (easily) is `unbound-control-setup`. Then it's necessary to enable some unbound config file options (towards the bottom of the example file) to make the control app work. I don't do that until the simple _unbound_ setup is working.  Then can adjust to suit, and bring in include files, etc, and see if they work.  I'm not an unbound expert yet, so this is not advice, but maybe a hint for ya.


----------



## ronaldlees (Apr 11, 2017)

Also, it doesn't hurt to make sure a very recent root is available.  Assuming that the /var/unbound/etc directory exists, then:

`wget ftp://FTP.INTERNIC.NET/domain/named.cache -O /var/unbound/etc/root.hints`

After setting appropriate permissions on the file, adding the following bit to /var/unbound/unbound.conf will bootstrap the resolver with root:


```
root-hints: "/var/unbound/etc/root.hints"
```

As a test, to make sure that I'm accessing the correct config file, I can run unbound from the command line (wouldn't normally do it that way):

`unbound -c /var/unbound/unbound.conf`


----------



## yhq_34 (Apr 11, 2017)

Hi, I add you conf to unbound.conf, likes below. Also I check unbound was started.

when I run ping still cannot resolv.
`ping: cannot resolve freebsd.org: Host name lookup failure`

unbound.conf

```
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
    username: unbound
    directory: /var/unbound
    chroot: /var/unbound
    pidfile: /var/run/local_unbound.pid
    auto-trust-anchor-file: /var/unbound/root.key
    root-hints: "/var/unbound/root.hints"

include: /var/unbound/forward.conf
include: /var/unbound/lan-zones.conf
include: /var/unbound/control.conf
include: /var/unbound/conf.d/*.conf
```
rc.conf

```
local_unbound_enable="YES"

sshd_enable="YES"

ntpd_enable="YES"

# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable

dumpdev="AUTO"
```


----------



## Deleted member 48958 (Apr 11, 2017)

Try to add "_module-config: iterator_" to /var/unbound/unbound.conf

```
server:
        username: unbound
        directory: /var/unbound
        chroot: /var/unbound
        pidfile: /var/run/local_unbound.pid
        auto-trust-anchor-file: /var/unbound/root.key
        module-config: iterator

include: /var/unbound/forward.conf
include: /var/unbound/lan-zones.conf
include: /var/unbound/control.conf
include: /var/unbound/conf.d/*.conf
```

It doesn't work for me too, without this line in unbound.conf.
Then run 
`# service local_unbound restart`


----------



## yhq_34 (Apr 11, 2017)

I found it works after add 
	
	



```
module-config: iterator
```
. Thanks a lot.
PS; How can I setup to make all other computer in LAN use this computer as dns server to resolv?


----------



## ronaldlees (Apr 11, 2017)

yhq_34 said:


> ...
> PS; How can I setup to make all other computer in LAN use this computer as dns server to resolv?



You'll probably have to touch the _"access-control:"_ values to allow other clients to access your "local" resolver.

I usually also look at _cache-min-ttl, cache-max-ttl, msg-cache-size, rrset-cache-size, and infra-cache-numhosts_ values, since I'd rather have data that's a little stale than have my cache run dry. Caveats apply to all of those items.  _ Cache-min-ttl: 0_ is safest, so I'm not advising anything different!  It's as I say, not as I do on this one, and surely my tweaks are not advice for anyone.  It's said that for safety, things should never be cached longer than originally intended.  Then again the next fetch isn't perfectly safe either, so it's no perfect world, and it might work (or not) either way. But ... I'm taking my cache off-grid.

My only gripe has been that occasionally the thing seems not to want to cache ipv6 AAAA records even when I have told it to cache them:


```
do-ip6: yes
```

I can't quite nail it down, and it could be my misconfig rather than any kind of bug. My general process should be to set-up liberal resources in unbound, run it for a week, and then firewall outgoing port 53.  There's zero DNS tracking from then on, albeit sometimes I'll have to open the firewall to cache new sites. Again, I run the risk of stale data, but for my purposes (general browsing, nothing important) - it's OK.  I wouldn't recommend it when address accuracy is required, like for banking (LOL).  Of course that hitchup could be the case with any cached value and with any TTL.  Bending the rules is always at ones own risk. I.E. - during the cache period, the IP was allocated to phishRus  - therefore this is NOT any suggestion or advice!


----------



## brisonic (Sep 4, 2017)

There is a bug here. With a plain vanilla 11.0 or 11.1 install, I can ping something like www.ibm.com by name and it works, but update.freebsd.org cannot be pinged unless i stick a forwarder in my resolv.conf above the localhost address. Unless someone beats me to it, I will file this soon.


----------



## brisonic (Sep 5, 2017)

background first. I installed both 11.0 and 11.1 this am, using the 299MB boot only iso on a compaq with a q6600 core2 quad. After it booted i pointed it at usa mirror 4 to get the rest of the files.

I have not directly modified any of those files. i did do a freebsd-update toget me from the 11.1 release to the 1st update version.
FreeBSD fbsd 11.1-RELEASE-p1 FreeBSD 11.1-RELEASE-p1 #0: Wed Aug  9 11:55:48 UTC 2017     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

root@fbsd:/etc/unbound # more unbound.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
        username: unbound
        directory: /var/unbound
        chroot: /var/unbound
        pidfile: /var/run/local_unbound.pid
        auto-trust-anchor-file: /var/unbound/root.key

include: /var/unbound/forward.conf
include: /var/unbound/lan-zones.conf
include: /var/unbound/control.conf
include: /var/unbound/conf.d/*.conf

root@fbsd:/etc/unbound # more forward.conf
# Generated by resolvconf

forward-zone:
        name: "attlocal.net"
        forward-addr: 192.168.1.254

forward-zone:
        name: "."
        forward-addr: 192.168.1.254

root@fbsd:/etc/unbound # more lan-zones.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
        # Unblock reverse lookups for LAN addresses
        unblock-lan-zones: yes
        insecure-lan-zones: yes

root@fbsd:/etc/unbound # more control.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
remote-control:
        control-enable: yes
        control-interface: /var/run/local_unbound.ctl
        control-use-cert: no

I also have a root.key file with today's date.


----------



## PaddyMac (May 23, 2018)

I know this thread is a little old, but I wanted to reply because I had this same problem and finally found the cause of the problem and the proper solution. Perhaps anyone Googling and finding this thread will finally get a good answer.

In short, I also tried the above solution of adding "module-config: iterator" to the config file and got DNS resolution working with unbound. But I didn't feel satisfied with this. After running through some troubleshooting steps suggested by a FreeBSD dev and an entire afternoon of reading and tinkering, I learned a few things. I learned that unbound, by default, enables DNSSEC. I also learned that the DNS service I was using at the time, OpenDNS, does not support DNSSEC. The reason that DNS resolution was failing is because my DNS nameserver of choice did not support DNSSEC, and the reason that adding "module-config: iterator" to the config file made DNS resolution work is because it disabled DNSSEC validation in unbound. Once I learned all this, I simply changed the DNS nameservers in my router to a service that definitely supports DNSSEC (in my first attempt, I used Quad9), I deleted /etc/resolv* and /var/unbound/*, and I rebooted so that all of those files would be automatically repopulated at boot without anything in RAM affecting the results. Upon reboot, DNS resolution was working properly and with DNSSEC enabled.

So while I suppose there could be other causes, I would suggest that anyone experiencing DNS resolution failure with unbound ensure than their DNS nameserver of choice supports DNSSEC. I hope this helps someone!


----------



## ShelLuser (May 23, 2018)

PaddyMac said:


> So while I suppose there could be other causes, I would suggest that anyone experiencing DNS resolution failure with unbound ensure than their DNS nameserver of choice supports DNSSEC. I hope this helps someone!


Nice find.

Another option can be to simply disable DNSSEC in Unbound, which is what I would do:


```
harden-dnssec-stripped: no
disable-dnssec-lame-check: yes
```
.... as far as I can tell this should be enough for that, the options can be added to unbound.conf.


----------



## Franconian_Witchcraft (Mar 18, 2020)

Thanks for the info 
Apparantly my PiHoles don't do DNSSEC and this got me the same issue.


----------

