Member

Daemon

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.

Daemon

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:

Code:

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.

Aspiring Daemon

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.

Aspiring Daemon

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:

Code:

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!

New Member

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.

New Member

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