[Unbound-users] Unbound release 1.4.12

[Paul Wouters]

On Mon, 18 Jul 2011, lst_hoe02 at kwsoft.de wrote:

> I thought that one have to explicit set --with-ldns-builtin to get this 
> behavior??

That was the case after I managed to accidentally ship a version of unbound
in Fedora that used a linked ldns because the build env didnt have ldns-devel
installed. So yes it does, but it caused problems in the past, and makes
maintainers nervous.

>> Also, not every unbound requires a new ldns.
>
> But it is no error to use latest unbound with latest ldns, no?

But where do you draw the line? Do you also recompile libevent every yime you
recompile unbound? If not, why are you doing so for ldns but not libevent?
If unbound HAS to use a certain new minimal version of ldns, that is you HAVE
to upgrade, then its ./configure should catch it for you and alert you to upgrade.

>> And of course, people use ldns and ldns-python without unbound.
>
> For sure, but many people use unbound without anything other using ldns so an 
> option to simply built unbound with static linked ldns would be nice to have. 
> A normal update from source with unbound was far below an hour, with 1.4.12 
> i#m struggling since two days :-(

Why did it take 2 days?

wget http://www.nlnetlabs.nl/downloads/ldns-1.6.10.tar.gz
tar zxf ldns-1.6.10.tar.gz
cd ldns-1.6.10
./configure --disable-rpath --disable-static --with-sha2 --with-pyldns
make
make doc
make install
make install-doc
ldconfig


note that your old method also introduces problems

1) if your other app wants to use ldns (or ldns-python or drill) which ldns is
    it using?
2) where are the ldns headers to compile against? If you find them are those the
    system ldns ones or the ones used by unbound?
3) if there is an ldns issue in version 1.6.X, how are you going to find out
    which ldns version unbound uses? (sometimes it even shipped non-full-release
    code of ldns inside the unbound tar ball)
4) how would a less knowledgable sysadmin who did not compile the unbound on a
    system ever know there is a vulnerable ldns statically linked into some binaries?

It is really much better from a sysadmin point of view to clearly separate the two.

It might be a little more work sometimes, but it is for the best :)

Paul