Description of problem: In the unit file of unbound service: ExecStartPre=/bin/bash -c 'if [ ! "$DISABLE_UNBOUND_ANCHOR" == "yes" ]; then /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem -f /etc/resolv.conf -R; else echo "Updates of root keys with unbound-anchor is disabled"; fi' Setting DISABLE_UNBOUND_ANCHOR="yes" in /etc/sysconfig/unbound disables running unbound-anchor before starting unbound daemon. However, unbound has a Wants dependency on unbound-anchor.timer, which is enabled by default. So, unbound-anchor will still run once a day. Version-Release number of selected component (if applicable): unbound-1.13.2-1 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Using DISABLE_UNBOUND_ANCHOR="yes" does not prevent unbound-anchor from running. Expected results: Using DISABLE_UNBOUND_ANCHOR="yes" one would expect to disable it entirely. However, the intended use of DISABLE_UNBOUND_ANCHOR is not documented, it seems. Adding the following in unbound-anchor.service, should make DISABLE_UNBOUND_ANCHOR apply globally: [Service] EnvironmentFile=-/etc/sysconfig/unbound ExecStartPre=/bin/bash -c 'if [ "$DISABLE_UNBOUND_ANCHOR" == "yes" ]; then echo "Updates of root keys with unbound-anchor is disabled"; exit 1; fi' Additional info:
I think you would want to systemctl disable unbound-anchor.timer, which runs actual anchor process. DISABLE_UNBOUND_ANCHOR is in unbound-service, because that is a part of unbound.service and the service would have to be modified instead. It does multiple actions. unbound-anchor.service does not do anything useful with disabled anchor action. If it should not run, then the timer should not run as well. What is your configuration of unbound? Why do you want to avoid running unbound-anchor at its start? I think it might be more useful to provide alternative configuration file to unbound-anchor. It might be required in case DNS over TLS is the only allowed outgoing method. Is that a reason, why do you want to disable it in both cases? What is your reason to disable unbound-anchor?
I think introducing UNBOUND_ANCHOR_OPTIONS, similar to UNBOUND_OPTIONS, would be more useful. It would allow single place of configuration for unbound anchors run in both startup of unbound and periodic unbound-anchor. It might simplify direct queries not using /etc/resolv.conf. Also it would make simpler to use for example TLS channel for unbound-anchor as well. Defaults might be: UNBOUND_ANCHOR_OPTIONS="-f /etc/resolv.conf -R" Commenting that out would make skip local resolvers. "-C /etc/unbound/conf.d/tls.conf" might allow a simple way to use TLS instead. Even though DNS over TLS brings no advantage, because DNSSEC signatures are checked. Turning off unbound-anchor completely would make sense only when DNSSEC validation is never enabled.
Note: the unwanted service can also be masked by systemctl mask unbound-anchor.service That prevents running of the service if that is unwanted.
(In reply to Petr Menšík from comment #1) > What is your reason to disable unbound-anchor? I'm using OpenNIC root servers and fetched the root.key myself. Without further configuration unbound-anchor will fetch IANA's root key, which does not apply to my setup. From what I understood, asking on unbound-users mailing list ([1], [2]), providing auto-trust-anchor-file in unbound.conf will keep track of the root.key using RFC5011 querying the root-hints servers without the need for unbound-anchor. In my case root-hints points to OpenNIC's root servers. I keep them updated. (In reply to Petr Menšík from comment #2) > I think introducing UNBOUND_ANCHOR_OPTIONS, similar to UNBOUND_OPTIONS, > would be more useful. It's useful only if its use is documented. One of the motivations for this bug is that DISABLE_UNBOUND_ANCHOR currently is not. Or I was unable to find the documentation. I encountered the variable in the unbound.service file. For other services/packages available variables are included in the configuration file in /etc/sysconfig accompanied by some explanatory comment. From the name of the variable, I inferred, incorrectly, that it would turn of unbound-anchor all together. There are many different ways of turning off unbound-anchor. Disabling the timer is one of them. But the vendor preset is enabled and unbound.service declares a Wants= dependency on unbound-anchor.timer. I don't mind triggering a NOOP once a day. Hence, my suggestion of using DISABLE_UNBOUND_ANCHOR in the unbound-anchor.service file. Thus making the variable do what it's suggesting. [1] https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-June/007820.html [2] https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-June/007822.html
I have built a new version, which improves the situation in my opinion. Moved unbound-anchor into separate subpackage dependent on unbound-libs. Moved /etc/sysconfig/unbound to that unbound-anchor package, which is required also by unbound package. Now it contains UNBOUND_ANCHOR_OPTIONS= environment, which should help by setting also alternate roots. You can use it to avoid using local resolver or add "-r /etc/unbound/unbound.hints" to use custom root hints. That would allow running the anchor even with different root. I have also moved anchor from unbound.service to Wants=unbound-anchor.service. That makes the anchor service shared by unbound.service and periodic timer. Calling unbound-anchor still makes sense in some situations. For example it would restore /var/lib/unbound/root.key if it is accidentally removed or emptied. Such as in filesystem corruption case. In that way automatic maintenance of unbound itself is not enough. But I guess you would have to configure also correct certificate. Last possibility is to mask the unbound-anchor.service. It would be just ignored both from timer and at unbound startup. That should work as long as correct key is in root.key. I have kept DISABLE_UNBOUND_ANCHOR just for backward compatibility, but would discourage its use. Would that fix your expectation? https://koji.fedoraproject.org/koji/taskinfo?taskID=88803906
Yes, that sounds like it would provide an easier way of disabling unbound-anchor or modifying its behavior. I would need to take a closer look at the unit files and their dependencies. I'll install from rawhide on a test system once it has landed (currently still on '-5'). I can certainly see why unbound-anchor is useful in certain scenarios. But what's your view on the statement that unbound-anchor does not need to run periodically when auto-trust-anchor-file points to a valid key as stated on the unbound-users list (see links above)?
(In reply to Sandro from comment #6) > I'll install from rawhide on a > test system once it has landed (currently still on '-5'). Oh, wait, it's a test build right? Based on rawhide, but not pushed to it. My bad. I'll download the RPM and upgrade manually.
I upgraded to unbound-1.16.0-6.fc37. What I see looks good. DISABLE_UNBOUND_ANCHOR now does what it suggests. But I have a couple of remarks/considerations: 1. The comment above DISABLE_UNBOUND_ANCHOR in /etc/sysconfig/unbound reads "uncomment following line to skip anchor refresh before unbound start", but that's not what it does. It now disables it entirely. Since DISABLE_UNBOUND_ANCHOR is now used in unbound-anchor.service, neither unbound.service nor unbound-anchor.timer will be able to run unbound-anchor. That is how it should be, but the comment should then be "uncomment following line to disable root.key update with unbound-anchor". 2. unbound-anchor.timer is enabled by default (vendor preset). On my test system it fired right away and downloaded the IANA root key. In production I have a modified /etc/sysconfig/unbound, so an upgrade wouldn't touch that file (can you confirm?) and the already set DISABLE_UNBOUND_ANCHOR="yes" would still be in use. However on a fresh install, one will not get the chance to set DISABLE_UNBOUND_ANCHOR="yes" before unbound-anchor is executed at least once. Maybe that needs some mention.
FEDORA-2022-afc2d2e53c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-afc2d2e53c
FEDORA-2022-afc2d2e53c has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-afc2d2e53c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-afc2d2e53c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-afc2d2e53c has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.