Comment 9 for bug 1771545

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