Re: for those who care about unbound (resolvconf and DNSSEC)
17.02.2011 07:07, Robert Edmonds wrote:
> hi,
>
> i'd like to get some feedback on whether i should implement some changes
> in the unbound debian packaging:
>
> * integration with resolvconf as a provider of recursive DNS
> resolution. (#562031)
>
> * retrieving a list of upstream recursive DNS servers from
> resolvconf and automatically configuring these servers as
> forwarders, and deconfiguring them when they are no longer
> available. (#567879)
Yes, both of these are really useful. I have this done long
ago locally on some notebook - trivially doable based on bind9
scripts. I just can't find it right now.
But indeed, this (#567879) needs unbound-control working, or
else it's impossible to change unbound config at runtime.
This is not a problem IMHO, to enable unbound-control by
default in new install. Check for 'control-enable: no'
in unbound.conf (ie, if it is explicitly disabled) before
enabling it, and log a warning if updating list of
forwarders failed in dhcp script (if updating is enabled
in /etc/default/unbound)
> * enabling DNSSEC validation by default. (#594911)
This is very useful, but questionable, since it makes
unbound to require writable files (now it does not write
anything except of the pid file). This in turn makes it
difficult to chroot it properly - it can only be chrooted
into /etc, and I'd rather keep /etc read-only during normal
operations. However, debian initscript does not have
provisions for chrooting it.
> i'm inclined to implement all three of these features and make them each
> individually toggle-able via /etc/default/unbound, and to enable these
> features by default, but i would like to hear some wider opinions. (i
> have never even used resolvconf before.)
>
> there are some sub-issues such as:
>
> * automatically creating key material and configuration for
> unbound-control (a la bind9 and rndc) so that unbound-control can
> be used to reload the forwarder configuration without dumping the
> cache.
>
> * making sure we don't accidentally attempt to configure ourselves
> as a forwarder.
What do you mean here?
> * how, or whether to include the root trust anchor. unbound now has
> a utility called unbound-anchor which attempts to fetch an updated
> root trust anchor from https://data.iana.org/root-anchors/, using
> a built-in copy of the ICANN HTTPS cert (so, it doesn't rely on
> x509 PKI); failing that, it writes out a built-in copy of the root
> trust anchor.
>
> it would be possible to invoke unbound-anchor in the unbound
> postinst in order to write out a trust anchor file into e.g.
> /var/cache/unbound, which is then referenced by the unbound config
> file, and it would also be possible to re-invoke unbound-anchor in
> the unbound init script. this would mean that a DNS server with
> the unbound package would cause HTTPS connections to be made,
> although if these connections failed there would be a fall-back
> trust anchor used.
>
> it's possible that at some point in the future old versions of
> unbound-anchor would no longer be able to securely generate an
> up-to-date root trust anchor file, but i believe this could be
> adequately handled by a stable-security or stable point release
> update.
That's all good points. Maybe a debconf question (whenever to enable
dnssec and to fetch the root keys etc) is in order.
Thanks!
/mjt
Reply to: