Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 602288 - net-dns/unbound-1.5.1-r2 - DNSSEC anchor placed outside chroot directory
Summary: net-dns/unbound-1.5.1-r2 - DNSSEC anchor placed outside chroot directory
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Marc Schiffbauer
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-10 19:46 UTC by Simon Siemonsma
Modified: 2018-10-26 20:24 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Siemonsma 2016-12-10 19:46:41 UTC
Trying to set up unbound with DNSSEC.
unbound-anchor will update /etc/dnssec/root-anchors.txt
In unbound.conf I uncommented:
auto-trust-anchor-file: "/etc/dnssec/root-anchors.txt"

systemctl enable unbound
systemctl enable unbound-anchor

When rebooting my log file contains:
unbound-checkconf[2238]: [1481395408] unbound-checkconf[2238:0] fatal error: auto-trust-anchor-file: "/etc/dnssec/root-anchors.txt" does not exist in chrootdir /etc/unbound
systemd[1]: unbound.service: Control process exited, code=exited status=1
systemd[1]: Failed to start Unbound recursive Domain Name Server.
Comment 1 Marc Schiffbauer gentoo-dev 2016-12-18 01:49:58 UTC
I am sorry, but I think this is not a bug, but a configuration problem: If you use unbound's chrooting feature you have to relocate your trust anchor file so that it is inside your chroot.

Or do I miss something here?

Please repoen if you still think this is a bug. Thanks!
Comment 2 Simon Siemonsma 2016-12-21 19:34:11 UTC
I would expect that when I emerge Unbound the different parts of a standard installation expect critical files at the same location.
So I expect that:
-when systemctl start/enable unbound
-when systemctl start/enable unbound-anchor
-running unbound-anchor

They all will work with the file location.

As it looks now in a standard install everything which handles keeping the anchor up to date looks in /etc/dnssec
The process using the anchor looks in /etc/dnssec within a chrooted environment, which is a different location.

This doesn't look logical to me.
All following options look more logical to me:
1. the processes which update the anchor work in the same chroot
2. the process using the anchor doesn't run chrooted (problably not the best option)
3. in the chrooted environment is some symlink/harlink which links to the anchor outside the chrooted environment (don't know if this is even possible)

Option 1 sounds most logical to me.

Simon Siemonsma
Comment 3 Simon Siemonsma 2016-12-21 21:40:46 UTC
I created a directory /etc/unbound/etc/dnssec
made a bind mount to /etc/dnssec
chown unbound /etc/dnssec

off course in /etc/unbound/unbound.cft uncommented the line: auto-trust-anchor-file: "/etc/dnssec/root-anchors.txt"

This seems to work.
Some more info on:
https://www.unbound.net/documentation/howto_anchor.html

Hope this will helpful for someone who is able to make a more elegant solution.

Simon
Comment 4 Marc Schiffbauer gentoo-dev 2016-12-29 20:54:00 UTC
The unbound ebuild depends on root-anchor file provided by net-dns/dnssec-root so unbound will be build to use /etc/dnssec/root-anchors.txt by default. Also the defaults that unbound tools are using are configured at build time.

If you decide to enable the auto-trust-anchor-file feature so that the root-anchors file will be updated automatically I would recommend not to try to make unbound overwrite the original file /etc/dnssec/root-anchors.txt but use some different path because its not good to auto-update a file owned by another package.

At least this might be a bad choice for a default setting in the ebuild.
You may rely on the trust-anchor that is provided by the dnssec-root package.

All this can only work if you disable unbounds chrooting feature or you otherwise have to copy/mount/link/whatever the trust-anchor file into the chroot like you already described. I agree that this is not an ideal solution.

I will think about this some more and maybe come with a saner solution in a later release.

Until then I suggest to copy the auto-trust-anchor-file into some subdir like /etc/unbound/var, make the directory and file owned by unbound so that unbound can write into it or let and go this way.

However, for a good default configuration we have to find something that will work with chroot enabled out of the box. And using bind mounts here seems not ideal as it would be too invasive. Symlinks will not work with chroot. Hardlinks also would not work because AFAIK the inode will change on root-key update.