[Unbound-users] Unbound release 1.4.12

[lst_hoe02 at kwsoft.de]

Zitat von Paul Wouters <paul at xelerance.com>:

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

 From my point of view libevent is more kernel related, while libldns  
as said was and is not used on any of my systems beside from unbound,  
but as always YMMV.

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

One system (dev) had by accident installed libldns (but no dev-header)  
from OS distribution. After fiddling around to get unbound compile  
with a downloaded libldns i end up with a version finally using the  
old OS provided. On the second system compiling it the same way worked  
but starting unbound failed because of missing libldns. Next system  
with Ubuntu 8.04 LTS has libldns installed in version 1.2.1 and it  
took some hours to find out that it was not needed so can be replaced.  
I choose to use unbound from source in the first place because it was  
really easy to compile and run on nearly any system, but with this  
split it isn't any more IMHO.

>
> 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?

The OS provided because this will be installed from the packages i guess

> 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?

As said it were the one from source, but more of an accident.

> 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)

If it is shipped with unbound there will be a new unbound "release" in  
this case, no?

> 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 does not know today either at least on Ubuntu because its coming  
from "universe" which has no support guarantie for security updates.  
This was an additional reason why i compile unbound from source.

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

Are there at least security notifications on the unbound list or do i  
have to subscribe to yet-another-list?

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

It is your project and your decision, so nothing more to say from my  
point of view.

Many Thanks

Andreas