Unbound configuration overwritten

Hi, please could someone kindly point me in the right direction. I am trying to configure unbound on a FreeBSD VM to serve my local network. The unbound package is installed and running. There are some modifications I would like to make to the main config file. Unbound is running in chroot, so there are 2 config files:
Code:
/var/unbound/unbound.conf
/etc/unbound/unbound.conf

Both files contain a warning:

Code:
This file was generated by local-unbound-setup. Modifications will be overwritten.

I am looking for a correct, supported way of making modifications to unbound.conf. So far, I have not figured this out. Any advice would be appreciated. Thank you.
 
You can just edit the unbound configuration files.
Just be carefull with the resolfconf service so it does not overwrite the configuration.
 
Hi Alain De Vos, thank you for your reply. I can make modifications to "/var/unbound/unbound.conf", and then restart the unbound daemon. This works fine. But if I re-run "local-unbound-setup", my changes get over-written. Maybe I do not understand the purose of "local-unbound-setup"...
 
What specifically is the problem? Since you set it manually, and it says that modifications will be overwritten, why do you run "local-unbound-setup" again?
 
The problem is to understand how I am *supposed* to make modifications to unbound.conf if the file clearly states not to make modifications to it. What is the correct mechanism for including additional options, such as allowing the entire network to use the DNS service.

Code:
This file was generated by local-unbound-setup. Modifications will be overwritten.
 
By editing files? Also, if your modifications are working why are you restoring the factory settings? Besides, if your modifications work and the files are not swapped, until you run "local-unbound-setup" why do you enable local-unbound-setup again?
 
Dear mbrijun,
there is a commented file /usr/local/etc/unbound/unbound.conf.sample which explains all options. For allowing the network to use you can check the config items interface and access-control. On my system the config allows communication via lo1 which is typical for jails:
Code:
    interface: 10.0.0.254
    access-control: 10.0.0.0/8 allow
.
Of course the configuration has more items.
 
The official answer is that the local unbound service is not intended for your use case. Use the `dns/unbound` port instead.

The unofficial answer is that you can add files in `/var/unbound/conf.d` with your modifications, e.g.

Code:
% cat /var/unbound/conf.d/access-control.conf
server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/24 allow
    interface: 192.168.0.1
    access-control: 192.168.0.0/24 allow

Remember to run `service local_unbound reload` after adding, removing, or modifying these files.
 
Are there serious differences between local_unbound from base and dns/unbound from ports ?
If I am not wrong dns/unbound can listen on any address. The version in base can listen to localhost only. In my setp I run the ports version (better to say the binary/packaged version provided by the FreeBSD package server) to be able to listen to lo1 which is used by jails.
 
This is not the case.
Is it more accurate to say "the default configuration for the version in base is set to listen on localhost only?" I'm going based on how configuration for FreeBSD has been done for a while.
 
Is it more accurate to say "the default configuration for the version in base is set to listen on localhost only?" I'm going based on how configuration for FreeBSD has been done for a while.
The setup script does not specify a listen address. Unbound defaults to localhost only. Use the interface and access-control directives in a server section (see the example I posted above) to change this.
 
  • Like
Reactions: mer
des@ Thank you for the clarification. So unbound by design tries to be lightweight and do what most people want (caching resolver) and if you want more you need to change the configuration. I think that is a good position for it to take.
 
So unbound by design tries to be lightweight and do what most people want (caching resolver) and if you want more you need to change the configuration.
Out of the box, Unbound is a local, caching, validating, recursing resolver. The local unbound service in FreeBSD 10+ sets up a local, caching, forwarding resolver with slightly relaxed validation, because strict validation breaks many typical corporate and public WiFi scenarios.
 
Dear des@,
does the local unbound as it is in base honors a configuration file as /usr/local/etc/unbound/unbound.conf? Is the ports version just the development version and the version in base just a few releases behind but mature?
 
does the local unbound as it is in base honors a configuration file as /usr/local/etc/unbound/unbound.conf? Is the ports version just the development version and the version in base just a few releases behind but mature?
1. No, it has been patched to read /var/unbound/unbound.conf instead, which is created by the rc script.
2. The base version lags behind the ports version because it takes a lot more work to update.
 
Out of the box, Unbound is a local, caching, validating, recursing resolver. The local unbound service in FreeBSD 10+ sets up a local, caching, forwarding resolver with slightly relaxed validation, because strict validation breaks many typical corporate and public WiFi scenarios.
This is a good explanation. Given the clear and narrow purpose of this daemon, it makes sense to enforce its specific configuration options and to remove any "special sauce" added by the user.
 
If I am not wrong dns/unbound can listen on any address. The version in base can listen to localhost only. In my setp I run the ports version (better to say the binary/packaged version provided by the FreeBSD package server) to be able to listen to lo1 which is used by jails.
Ok, I have given it a try. In my configuration unbound should listen to 10.0.0.254 on lo1. The local_unbound works with that configuration. But at startup there are error messages as below:
Code:
# service local_unbound onestart
Starting local_unbound.
Waiting for nameserver to start...[1661871362] unbound-control[15416:0] warning: control-enable is 'no' in the config file.
[1661871362] unbound-control[15416:0] error: connect: Connection refused for 127.0.0.1 port 8953
.[1661871363] unbound-control[15419:0] warning: control-enable is 'no' in the config file.
[1661871363] unbound-control[15419:0] error: connect: Connection refused for 127.0.0.1 port 8953
.[1661871364] unbound-control[15425:0] warning: control-enable is 'no' in the config file.
[1661871364] unbound-control[15425:0] error: connect: Connection refused for 127.0.0.1 port 8953
.[1661871366] unbound-control[15428:0] warning: control-enable is 'no' in the config file.
[1661871366] unbound-control[15428:0] error: connect: Connection refused for 127.0.0.1 port 8953
.[1661871367] unbound-control[15455:0] warning: control-enable is 'no' in the config file.
[1661871367] unbound-control[15455:0] error: connect: Connection refused for 127.0.0.1 port 8953
 giving up
"giving up" seems to be related to 127.0.0.1 only. I have no idea where the port number comes from. But local_unbound listens on 10.0.0.254 and answers to requests. To avoid the error I will stick with the packaged version.
 
Just use local_unbound because it is more compatible ?
I am not sure about the meaning of compatible with respect to the unbound versions. But if unbound should listen to 127.0.0.1 one can use the local_unbound because it is already part of the base infrastructure.
 
Back
Top