for those who care about unbound (resolvconf and DNSSEC)
 

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)

* enabling DNSSEC validation by default. (#594911)

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.

* 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.

--
Robert Edmonds
edmonds@debian.org

for those who care about unbound (resolvconf and DNSSEC)
 

On 02/17/2011 05:07 AM, Robert Edmonds wrote:
> 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

in order to do that for the first two that involve resolvconf, does that
mean you're going to add a depends on resolvconf (rather than e.g. a
recommends)? i'd prefere to not have resolvconf pulled in hard.

--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D5CD40E.8030006@progress-technologies.net">http://lists.debian.org/4D5CD40E.8030006@progress-technologies.net

for those who care about unbound (resolvconf and DNSSEC)
 

On 2011-02-17, Daniel Baumann <daniel.baumann@progress-technologies.net> wrote:
> On 02/17/2011 05:07 AM, Robert Edmonds wrote:
>> 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
>
> in order to do that for the first two that involve resolvconf, does that
> mean you're going to add a depends on resolvconf (rather than e.g. a
> recommends)? i'd prefere to not have resolvconf pulled in hard.

let me rephrase: the resolvconf options would be enabled by default, but
would be no-ops unless resolvconf is installed. and i think the package
would only Suggest: resolvconf.

--
Robert Edmonds
edmonds@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: ijina1$b0k$1@dough.gmane.org">http://lists.debian.org/ijina1$b0k$1@dough.gmane.org

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D5CF693.5090403@msgid.tls.msk.ru">http://lists.debian.org/4D5CF693.5090403@msgid.tls.msk.ru

for those who care about unbound (resolvconf and DNSSEC)
 

On 02/17/2011 09:46 AM, Robert Edmonds wrote:
> let me rephrase: the resolvconf options would be enabled by default, but
> would be no-ops unless resolvconf is installed. and i think the package
> would only Suggest: resolvconf.

thanks.

--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D5D789E.6040300@progress-technologies.net">http://lists.debian.org/4D5D789E.6040300@progress-technologies.net

for those who care about unbound (resolvconf and DNSSEC)
 

Robert Edmonds wrote:
> i'd like to get some feedback on whether i should implement some changes
> in the unbound debian packaging:

i'm also looking into building the python bindings for libunbound.
unfortunately upstream uses autotools / libtool to build and link the
python module, which results in the python extension module being linked
against every library the configure script can find.

short of rewriting the upstream build system i could only come up with
the following to make the build link against only the required
libraries:

# XXX gross hack to prevent python module from linking against everything
rm -f _unbound.la
sed -i -e 's/^dependency_libs=.*/dependency_libs='/' libunbound.la
make _unbound.la LIBS=""
install -m 0644 .libs/_unbound.so.2.*.*
debian/python-unbound/usr/lib/pyshared/python2.6/_unbound.so

but that's really gross.

--
Robert Edmonds
edmonds@debian.org