I have Unbound 1.4.19 running on Ubuntu 13.04 server on my LAN (private address) that I wish to use as a local caching recursive DNS server (not attempting DNSSEC). The reason I have set up Unbound is to provide caching for DNSCrypt-Proxy which is also running on this same machine. By capturing the traffic at the router level I can verify that when I do a lookup from this same Ubuntu machine it is correctly going through DNSCrypt-Proxy because there is no port 53 activity, it runs over port 443 to the OpenDNS server as expected.
The problem arises when another computer on the LAN tries to do a lookup using the Unbound computer -- the traffic then uses standard port 53 and does a full lookup starting with a TLD.
The appearance is that the local machine respects the forward-zone setting (forwards all to DNSCrypt-Proxy on 127.0.0.2) but the lookups for other machines on the LAN are not respecting the forward-zone setting.
I'm running unbound version 1.4.19 on Ubuntu 13.04 server. Thank you for your help.
-Casey
my unbound.conf
server:
verbosity: 1
statistics-cumulative: yes
interface: 127.0.0.1
interface: 10.0.1.13
outgoing-interface: 10.0.1.13
msg-cache-size: 8m
rrset-cache-size: 16m
access-control: 10.0.1.0/24 allow
username: "unbound"
logfile: "/var/log/unbound.log"
use-syslog: no
log-time-ascii: yes
private-domain: "home.lan"
prefetch: yes
module-config: "iterator"
auto-trust-anchor-file: "/etc/unbound/root.key"
dlv-anchor-file: "dlv.isc.org.key"
domain-insecure: "home.lan"
local-zone: "home.lan." static
local-data: "pfsense.home.lan. IN A 10.0.0.1"
local-data-ptr: "10.0.0.1 pfsense.home.lan"
python:
remote-control:
stub-zone:
name: "home.lan"
stub-addr: 10.0.1.1
stub-prime: no
stub-first: no
forward-zone:
name: "."
forward-addr: 127.0.0.2 # forward all to 127.0.0.2 where DNSCrypt is running!
Update: Unbound is actually not forwarding at all.
On the local machine I had my resolver set to 127.0.0.2 so it went directly to dnscrypt-proxy. Changing resolv.conf back to 127.0.0.1 results in all requests going through the normal lookup process, not to dnscrypt-proxy.
I have even tried now with the recommended setup on the dnscrypt.org page running dnscrypt on 127.0.0.1:40 and this unbound conf:
I previously posted about Unbound seemingly not observing the forward-zone settings in my setup (unbound version 1.4.19 on Ubuntu 13.04 server). My reason for using the forward-zone directive in unbound.conf is to forward all requests through dnscrypt-proxy running on the localhost:
This could be a BUG in UNBOUND ... the solution is unbound.conf MUST explicitly turn off remote control (neither of us was using remote control):
remote-control:
control-enable: no
Simply not including control-enable in the unbound.conf is not sufficient. More documentation/discussion of the issue, setup, and solution is available on the above mentioned github page.
I previously posted about Unbound seemingly not observing the
forward-zone settings in my setup (unbound version 1.4.19 on Ubuntu
13.04 server). My reason for using the forward-zone directive in
unbound.conf is to forward all requests through dnscrypt-proxy
running on the localhost:
This could be a BUG in UNBOUND ... the solution is unbound.conf
MUST explicitly turn off remote control (neither of us was using
remote control):
remote-control: control-enable: no
Simply not including control-enable in the unbound.conf is not
sufficient. More documentation/discussion of the issue, setup, and
solution is available on the above mentioned github page.
Thanks for sharing this back here. I see in the logfiles on the
github page that:
Sep 17 04:28:06 unbound[10138:0] debug: new control connection from
ip4 127.0.0.1 port 50815 (len 16)
Sep 17 04:28:06 unbound[10138:0] debug: comm point stop listening 12
Sep 17 04:28:06 unbound[10138:0] debug: comm point start listening 12
Sep 17 04:28:06 unbound[10138:0] debug: remote control connection
authenticated
Sep 17 04:28:06 unbound[10138:0] info: control cmd: forward off
It seems something else is running and calling "unbound-control
forward off". This would disable your configured forward-zone
statement at run time. Setting control-enable: no causes this
unbound-control sequence to be ignored (because you disallow
remote-control in unbound.conf).
(are you running dnssec-trigger? Uninstall it because you want to
manually configure where queries go)
So, it is not so much a bug in control-enable, there is some program
on the machine that calls unbound-control forward off and that is the
'root cause'. Or at least, a step close to a root cause for not
having the unbound configuration you want.
> I previously posted about Unbound seemingly not observing the
> forward-zone settings in my setup (unbound version 1.4.19 on Ubuntu
> 13.04 server). My reason for using the forward-zone directive in
> unbound.conf is to forward all requests through dnscrypt-proxy
> running on the localhost:
Based on your version numbers it sounds like you're using the unbound
package shipped with the Ubuntu system:
It seems something else is running and calling "unbound-control
forward off". This would disable your configured forward-zone
statement at run time. Setting control-enable: no causes this
unbound-control sequence to be ignored (because you disallow
remote-control in unbound.conf).
On Debian systems, the unbound package is integrated with the resolvconf
system for configuring the set of forwarders, which allows the sysadmin
to specify the forwarders to be used in the /etc/network/interfaces
config file using the "dns-nameservers" directive. See the
interfaces(5) and resolvconf(8) manpages for details. (I think the
resolvconf system can also learn forwarder addresses from
NetworkManager.)
The unbound package's resolvconf integration is optional but enabled by
default. It can be disabled by commenting out the line
"RESOLVCONF_FORWARDERS=true" in /etc/default/unbound (or by uninstalling
the resolvconf package), which is preferable to disabling the
remote-control mechanism entirely. (Otherwise the unbound package's
resolvconf integration script will still be run on network interface
changes and still attempt to reconfigure unbound's forwarders, it will
just silently fail.)