Forward being overwritten by Control cmd Forward on Restart

I'm a new Unbound user, running on linux Mint 17.3.

Took me a while finding how to set everything up but now down to one question (I think!). All seems ok except forwarding.

I set up a few forward-addr lines such as...

forward-zone:
name: "."
forward-addr: 193.183.98.154 # opennic (IT)
forward-addr: 87.98.175.85 # opennic (FR)
forward-addr: 5.9.49.12 # opennic (DE)
forward-addr: 5.135.183.146 # opennic (FR)
etc...

When I restart unbound the log shows...

Dec 20 19:36:10 unbound[54448:0] info: start of service (unbound 1.4.22).
Dec 20 19:36:11 unbound[54448:0] debug: new control connection from 127.0.0.1 port 34804
Dec 20 19:36:11 unbound[54448:0] info: control cmd: forward 208.67.220.220 208.67.222.222

The problem is: the last line in the log shows the control cmd over-writing the forward IPs I set up with those from the Wired Connection IPv4 DNS servers list, so that my defined forward IPs are over-written.

I am reluctant to remove the Wired Connection IPs (and why should I?).

I can prevent the over-write by disabling Remote Control (control-enable: no).

The control cmd must be generated by something but I cannot discover what.

I am also a little confused as to the port number in the log line...

debug: new control connection from 127.0.0.1 port 34804

Can I assume this is an arbitrary port from which unbound was started?

I'm not sure what other information you require but as a start, resolv.conf contains only 127.0.0.1. I am not, at the moment, enabling any of the unbound trust features - those are my next task.

I'm a new Unbound user, running on linux Mint 17.3.

Took me a while finding how to set everything up but now down to one
question (I think!). All seems ok except forwarding.

I set up a few forward-addr lines such as...

forward-zone:
name: "."
forward-addr: 193.183.98.154 # opennic (IT)
forward-addr: 87.98.175.85 # opennic (FR)
forward-addr: 5.9.49.12 # opennic (DE)
forward-addr: 5.135.183.146 # opennic (FR)
etc...

When I restart unbound the log shows...

Dec 20 19:36:10 unbound[54448:0] info: start of service (unbound 1.4.22).
Dec 20 19:36:11 unbound[54448:0] debug: new control connection from
127.0.0.1 port 34804
Dec 20 19:36:11 unbound[54448:0] info: control cmd: forward
208.67.220.220 208.67.222.222

The problem is: the last line in the log shows the control cmd
over-writing the forward IPs I set up with those from the Wired
Connection IPv4 DNS servers list, so that my defined forward IPs are
over-written.

I am reluctant to remove the Wired Connection IPs (and why should I?).

I can prevent the over-write by disabling Remote Control
(control-enable: no).

The control cmd must be generated by something but I cannot discover what.

The unbound package on ubuntu has some triggers included for resolvconf.
These triggers will add the upstream resolvers from dhcp to your config.
I don't know which ubuntu version your mint is based on, but you might
get wiser by looking at /etc/default/unbound, especially the variable.

I am also a little confused as to the port number in the log line...

debug: new control connection from 127.0.0.1 port 34804

This is the source port that is used by the client (i.e.
unbound-control) to connect to unbound. It is indeed a just random port.

Can I assume this is an arbitrary port from which unbound was started?

I'm not sure what other information you require but as a start,
resolv.conf contains only 127.0.0.1. I am not, at the moment, enabling
any of the unbound trust features - those are my next task.

Kind regards,
  Tom

Please keep replies on list.

Thanks, Tom. Solved now by setting...

RESOLVCONF_FORWARDERS=false

Any chance of mentioning /etc/default/unbound in the docs somewhere - ie
somewhere when someone like me wouldn't miss it? Possibly a comment in
the Forward section. :slight_smile:

The /etc/default/unbound file is an ubuntu feature and not supplied by
unbound itself, so you're probably barking up the wrong tree :wink:

For reference: Mint 17.x is based on ubuntu 14.04. I'm running with
static connection not dhcp on a (soon to be) postfix mail server.

Kind regards,
  Tom