root.key might be missing

[Alexander Traud]

Not the underlying package libunbound2 but only the big DNS resolver package unbound contains a script to install/copy the root.key. If you install just unbound-anchor, unbound-host, or -dev, this does not happen and all tools which rely on libunbound.so might not work.

Steps to Reproduce
1) install Ubuntu 18.04 LTS for Desktop (in my case, Minimal)
2) $ sudo apt remove unbound
3) $ sudo apt install unbound-anchor
4) $ sudo unbound-anchor

Expected Result
This should install a root.key at /var/lib/unbound/, because that is the default location, given unbound-anchor at compile time.

Actual Result
libunbound error: unable to open /var/lib/unbound/root.key for reading: No such file or directory
libunbound error: error reading auto-trust-anchor-file: /var/lib/unbound/root.key
libunbound error: validator: error in trustanchors config
libunbound error: validator: could not apply configuration settings.
libunbound error: module init for module validator failed

Notes
This happens *even* after changing the file
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf
and its "auto-trust-anchor-file" to "/usr/share/dns/root.key" (package dns-root-data). The same issue happens with $ unbound-host -D example.com
I am not sure how to solve this. My first guess would be that not the package unbound but the package libunbound2 should install that key file (script root_trust_anchor_update). This affects not only -anchor and -host but all apps which rely on libunbound.so, because those tools expect that "/var/lib/unbound/root.key" exists.

Workarounds
A) create the file yourself:
sudo mkdir /var/lib/unbound
sudo cp /usr/share/dns/root.key /var/lib/unbound/
B) specify the key of the package dns-root-data as command-line option:
sudo unbound-anchor -a "/usr/share/dns/root.key"
   I was not able to use this approach for unbound-host.
C) install the whole DNS resolver:
sudo apt install unbound
D) in your own app, instead of one, try two files:
if (0 == access("/var/lib/unbound/root.key", R_OK)) {
 status_unbound = ub_ctx_add_ta_file(ub_context, "/var/lib/unbound/root.key");
} else {
 status_unbound = ub_ctx_add_ta_file(ub_context, "/usr/share/dns/root.key");
}

[Andreas Hasenack (ahasenack)]

Thanks for filing this bug in Ubuntu.

I understand your case: applications linked with libunbound2 will eventually lookup the root.key file, but it's only installed by the unbound server package. I'm not sure what's expected here, to be honest, as I'm not familiar with unbound. What you say does make sense to me, though.

We mostly take this package from Debian as is, only applying small changes regarding apparmor profiles, and it's in Universe, not Main. Would you mind filing this bug in Debian via bugs.debian.org?

[Andreas Hasenack (ahasenack)]

Maybe related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641704

[Simon Déziel (sdeziel)]

Currently, the root.key is managed by a helper script shipped with the unbound package. It would make sense to have the root.key managed automatically for apps relying on libunbound2 for DNS resolution. As such, I think a possible way to achieve this would be to have the helper script shipped with unbound-anchor and make unbound-anchor a dependency (recommends?) for libunbound2. The helper script should be called at some frequency to ensure that root KSK rollovers are processed properly. For that part, a cron job or a systemd timer unit would do.

[Simon Déziel (sdeziel)]

Reported to Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900241

[Alexander Traud (traud)]

Simon, thank you very much for taking over. I am very much with your proposal: Moving that script from unbound to unbound-anchor plus making unbound-anchor a dependency of libunbound2. That was my first thought as well.

However, there might be another approach: The package "dns-root-data" is not just in Universe but in Main and is one of the sources of that root.key already. Perhaps it is easier to update the package "dns-root-data" manually and then
- simply symlink the root.keys or/and
- change libunbound2 to use that root.key on default directly (set at compile time).

With such an approach, no script and no timer would be needed. Nevertheless, I am not sure whether this approached is "allowed" security vise because an (additional) individual has control about the root.key – at least in Debian world, then.

Andreas, yes that other report is about the very same symptom. I completely forgot to mention that report as I found this issue and that report already with Ubuntu 14.04 LTS. I was not able to investigate this issue until now. Thanks for adding it. My report is a bit broader because it affects all apps which rely on libunbound2 actually. But yes, the cause is the very same. By the way in that other report, to answer the section ‘PS’ asked by Thue-Janus: unbound-host must be invoked with parameter -D to trigger the expected error.

[Simon Déziel (sdeziel)]

On 2018-05-31 08:30 AM, Alexander Traud wrote:
> However, there might be another approach: The package "dns-root-data"
> is not just in Universe but in Main and is one of the sources of that
> root.key already. Perhaps it is easier to update the package
> "dns-root-data" manually and then - simply symlink the root.keys
> or/and - change libunbound2 to use that root.key on default directly
> (set at compile time).

A symlink wouldn't do as unbound wants to write to that file to keep it
current.

> With such an approach, no script and no timer would be needed.
> Nevertheless, I am not sure whether this approached is "allowed"
> security vise because an (additional) individual has control about
> the root.key – at least in Debian world, then.

The package-helper script tries to use the dns-root-data
provided root.key as initial seed if present.

The idea behind dns-root-data was to have a single package to maintain
and distribute a fresh root.key (and root NS hints) but newer versions
were not backported to Ubuntu. Also, KSK rollovers utilize a mechanism
(RFC5011) to securely introduce new keys and this might be faster than
deploying updated versions of dns-root-data. Not everyone deploy updates
swiftly so having the RFC5011 method would cover those users.

IMHO, it would be best to use both methods: have unbound-anchor schedule
updates and push fresh versions of dns-root-data to all supported releases.

Regards,
Simon

[Alexander Traud (traud)]

> unbound wants to write to that file to keep it current.

Sorry for asking as I am not so much into root.key and package updates. However I do not understand that sentence yet and I am terrible curious. From the user perspective: The user needs a current root.key file to do validation. What is the difference whether that happens via a package update/backport, or unbound-anchor, or both? In other words, if unbound-anchor writes to "/usr/share/dns/root.key", why is that bad? If dns-root-data is updated/backported and writes to the very same file, why is that bad? In both cases, a different technology is used to get a current root.key. Does that qualify to separate things?

Furthermore, I am not sure about the role of the package dns-root-data, yet. I am asking because the answer could void my workaround D. dns-root-data was/is never backported. Uhh? Did I understand that correctly? unbound-anchor needs a working and valid starting point. What happens when the package dns-root-data is so terrible outdated that unbound-anchor cannot use it as starting point anymore?

In other words: I do not understand why Debian world needs RFC 5011 when they have a much "better" update mechanism already, the package management. It is nice to have unbound-anchor (and its RFC 5011) as well, but isn’t the Debian/Ubuntu package management better and therefore should be the primary choice? A symlink would create that "primary", I thought.

[Simon Déziel (sdeziel)]

On 2018-06-01 04:52 AM, Alexander Traud wrote:
>> unbound wants to write to that file to keep it current.
>
> Sorry for asking as I am not so much into root.key and package
> updates. However I do not understand that sentence yet and I am
> terrible curious.
>> From the user perspective: The user needs a current root.key file
>> to do
> validation. What is the difference whether that happens via a
> package update/backport, or unbound-anchor, or both? In other words,
> if unbound- anchor writes to "/usr/share/dns/root.key", why is that
> bad? If dns- root-data is updated/backported and writes to the very
> same file, why is that bad? In both cases, a different technology is
> used to get a current root.key. Does that qualify to separate
> things?

I'm not that experienced with package policy but I _think_ that a given
package cannot write to files provided by another package.

> Furthermore, I am not sure about the role of the package
> dns-root-data, yet.

It ships a root.hints file as well which can be useful to resolvers when
they start up.

> I am asking because the answer could void my workaround D. dns-
> root-data was/is never backported. Uhh? Did I understand that
> correctly? unbound-anchor needs a working and valid starting point.

unbound-anchor has a built-in copy of the root DS trust anchor. This
copy is embedded when upstream makes a release.

> What happens when the package dns-root-data is so terrible outdated
> that unbound-anchor cannot use it as starting point anymore?

This is a bad situation as it breaks DNS resolution completely if DNSSEC
is required.

> In other words: I do not understand why Debian world needs RFC 5011
> when they have a much "better" update mechanism already, the package
> management. It is nice to have unbound-anchor (and its RFC 5011) as
> well, but isn’t the Debian/Ubuntu package management better and
> therefore should be the primary choice?

Not everyone apply package updates frequently. Those lagging behind risk
losing all capability to do DNS lookups if a root KSK rollover occurred
and they didn't pick up the new KSK using RFC 5011.

That's why having the 2 update mechanisms is the best way in my opinion.

Regards,
Simon