Bug 2322697

This is a problem with accepting custom TLD zones like .lan, .internal and such. The problem is not about SOA queries to ".", that is just less important manifest. But I think unwanted too.

What we do in dnsconfd is using forward definitions for those custom zones, not existing in normal DNS tree. Problem with authoritative data on client is any redirection via forwarding has lower priority. If authoritative copy of root zone is on the same instance, all forward definitions will get ignored. No matter whether forwarded via configuration file or via unbound-control forward_add. It just prevents using forwarders.

I also think downloading root copy is okay for network-wide resolvers, but we want unbound used *also* as localhost DNS cache. I doubt root operators would approve downloading root zone to every laptop and periodic maintenance for the zone. We haven't found simple way to disable local copy when uncommented in default config.

It seems to me we should ship our downstream defaults in /usr/share/unbound directory, in spirit with uapi-group spec:
https://github.com/uapi-group/specifications/blob/main/specs/configuration_files_specification.md

From there it might be included from /etc/unbound/unbound.conf. Just commenting out single include might allow omitting some defaults, like this one.

Something like generating:
/usr/share/unbound/conf.d/local-root.conf - authoritative root zone copy, used for whole network. Could have an own subpackage this way. Maybe unbound-network-resolver?
/usr/share/unbound/conf.d/private-networks.conf - insecure-domains for lan, test, internal and similar known domains. Suitable for unbound, which should forward even private queries to local network resolver. Maybe unbound-local-resolver?
/usr/share/unbound/conf.d/fedora.conf - Customized unbound defaults, which we use in general. Instead of patching multiple times example config file, just move only our modifications to common file.

Advantage of /usr/share config files it makes clear distinction what file is supposed to be maintained by distribution vendor. /etc/unbound would be just user-specific.

In /etc/unbound/unbound.conf, we would just put:
include: "/usr/share/unbound/conf.d/*.conf"
include: "/etc/unbound/conf.d/*.conf

What would you think about such solution? We do not know how the user wants to use unbound, but could prepare a recommended set for usage as network-wide resolver and another for localhost defaults.

Problem is systemd and libeconf implement /etc/ preference if the same named file exists also in /etc/, as well as in /usr/share. I do not think something similar is possible with unbound directly. Workaround might be symlink put into /etc/unbound/conf.d/$CONF.conf, leading to /usr/share/unbound/conf.d/$CONF.conf. User deleting symlink and replacing it with empty or custom file would deactivate that config. That seems best we can do with existing unbound features.

Paul, would you have better idea how to solve provided defaults, which can be user overriden?

Prepared PR: https://src.fedoraproject.org/rpms/unbound/pull-request/17#

That creates separate 2 files:
- unbound-as112-networks.conf - helper to easily forward all private addresses from your unbound. Useful when it acts as localhost resolver only and you are using internal private resolver. Which should handle all private ranges, home.arpa zone etc.
- unbound-local-root.conf - this contains uncommented local root auth zone definition. It would be disabled by default, but can be easily enabled.

To enable some of those, just:
cd /etc/unbound/conf.d/ && ln -rs /usr/share/unbound/conf.d/unbound-local-root.conf

I propose to have unbound-local-root.conf used on network-wide resolver, but instead unbound-as112-networks.conf on localhost resolvers. Because we do not know how the user wants it used, we can only make his decision simpler.

FEDORA-2024-8bb71c1fd7 (unbound-1.22.0-7.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8bb71c1fd7

FEDORA-2024-aecc7c321e (unbound-1.22.0-7.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-aecc7c321e

FEDORA-2024-aecc7c321e has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-aecc7c321e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-aecc7c321e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-deb9b3f394 (unbound-1.22.0-8.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-deb9b3f394

FEDORA-2024-deb9b3f394 (unbound-1.22.0-8.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2024-aecc7c321e has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-aecc7c321e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-aecc7c321e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-aecc7c321e (unbound-1.22.0-8.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days