Unbound release 1.4.12

Unbound
1

Hi,

unbound 1.4.12 is here, with two moderate serious bugfixes.
http://www.unbound.net/downloads/unbound-1.4.12.tar.gz
sha1: c46c05d1fa2402a59c10f51864fd4c62d10a472f
sha256: d7f0ee340b8a62e3fe02e505fdf6f2e4742ae7eaf8fd1da200fb38c4947e2d66

It has the ldns tarball removed from the unbound tarball. If you used
- --with-ldns-builtin, you have to change your buildscripts, and use a
proper dependency on ldns. (with --with-ldns=path you can use ldns
installed in a different location if necessary, e.g. due to different
libcrypto used, for home-users: --with-ldns=compile-dir-of-ldns works
too pointed at the build-dir of ldns).

The ID leak found by Jinmei Tatuya can leak the id bits of a previous
query in specially-crafted acl-REFUSED queries. The previous portnumber
or queryname is not leaked.

The replyaddr count bug was reported by Robert Fleischman, it can cause
unbound to stop responding to non-cached queries, but only after
dropping and jostling thousands of queries.

Bug Fixes
    * removed ldns-src tarball inside the unbound tarball.
    * [bugzilla: 395 ]
      fix that id bits of other query may leak out under conditions
    * fix replyaddr count wrong after jostled queries, which leads to
eventual starvation where the daemon has no replyaddrs left to use.
    * fix that the listening socket is not closed when too many remote
control connections are made at the same time.
    * version number in example config file.
    * fix that --enable-static-exe does not complain about it unknown.
    * iana portlist updated

Best regards,
   Wouter

2

Zitat von "W.C.A. Wijngaards" <wouter@NLnetLabs.nl>:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

unbound 1.4.12 is here, with two moderate serious bugfixes.
http://www.unbound.net/downloads/unbound-1.4.12.tar.gz
sha1: c46c05d1fa2402a59c10f51864fd4c62d10a472f
sha256: d7f0ee340b8a62e3fe02e505fdf6f2e4742ae7eaf8fd1da200fb38c4947e2d66

It has the ldns tarball removed from the unbound tarball. If you used
- --with-ldns-builtin, you have to change your buildscripts, and use a
proper dependency on ldns. (with --with-ldns=path you can use ldns
installed in a different location if necessary, e.g. due to different
libcrypto used, for home-users: --with-ldns=compile-dir-of-ldns works
too pointed at the build-dir of ldns).

May i ask if it is really needed to exclude ldns from tarball? It was really handy to not download yet-another-tarball have a look at the checksums and move it to the right destination, than do configure/make for the libs and start over with unbound again. How many people actually need it to be excluded?

Regards

Andreas

3

Hi,

>unbound 1.4.12 is here, with two moderate serious bugfixes.
>http://www.unbound.net/downloads/unbound-1.4.12.tar.gz
>sha1: c46c05d1fa2402a59c10f51864fd4c62d10a472f
>sha256: d7f0ee340b8a62e3fe02e505fdf6f2e4742ae7eaf8fd1da200fb38c4947e2d66
>
>It has the ldns tarball removed from the unbound tarball. If you used
>- --with-ldns-builtin, you have to change your buildscripts, and use a
>proper dependency on ldns. (with --with-ldns=path you can use ldns
>installed in a different location if necessary, e.g. due to different
>libcrypto used, for home-users: --with-ldns=compile-dir-of-ldns works
>too pointed at the build-dir of ldns).

May i ask if it is really needed to exclude ldns from tarball? It
was really handy to not download yet-another-tarball have a look at
the checksums and move it to the right destination, than do
configure/make for the libs and start over with unbound again. How
many people actually need it to be excluded?

I agree. I prefer installing packages on a server, but for a DNS server, I
prefer to compile the DNS server software itself, so it can be optimized etc
etc. But now I have to compile ldns as well, since the one in the latest
Ubuntu (LTS version) server is "not recent enough" :frowning: I compiled now ldns,
but unbound links to libldns now runtime, which - I guess - is not optimal,
since as far as I know shared libraries are PIC code, which causes some
performance loss (especially on 32 bit architecture because there is not
so much registers on 32 bit x86 platform). So even another difficulty now:
try to figure out how I can make unbound to use libldns.a instead of .so ...
Now I've modified libldns.la to have libldns.a as library_names but I guess
it's a very ugly solution and better way should exist ...

- Gábor

4

see many discussions here in the last. The debian and fedora maintainers
both asks for it to be decoupled, as the tar ball copy inside unbound is
confusing and can sometimes accidentally get linked by unbound if the
ldns dev/devel package is not installed. Staticly linked libraries on
systems are not good. If you think you have ldns 1.6.10 but unbound had
been statically linked to 1.6.9, you might have a security issue.....

Also, not every unbound requires a new ldns.

And of course, people use ldns and ldns-python without unbound.

Paul

5

Hi,

>May i ask if it is really needed to exclude ldns from tarball? It
>was really handy to not download yet-another-tarball have a look
>at the checksums and move it to the right destination, than do
>configure/make for the libs and start over with unbound again. How
>many people actually need it to be excluded?

see many discussions here in the last. The debian and fedora maintainers
both asks for it to be decoupled, as the tar ball copy inside unbound is
confusing and can sometimes accidentally get linked by unbound if the
ldns dev/devel package is not installed. Staticly linked libraries on
systems are not good. If you think you have ldns 1.6.10 but unbound had
been statically linked to 1.6.9, you might have a security issue.....

Also, not every unbound requires a new ldns.

And of course, people use ldns and ldns-python without unbound.

I can be wrong here, but as far as I know unbound only used the "built-in"
ldns only if the specific configure option was used and it was not the
default (if I am wrong, it can be done to a non-default option, so it would
be used _only_ if someone is sure that they requested it at the time of
running ./configure). So I can't see why it can cause problems that unbound
provides the usage of built-in ldns and only if it is requested by the
person who compiles it. Debian/fedora maintainers should only not use the
--with-ldns-builtin switch of ./configure, it's simply that. Or did I miss
something here? Now, I have to compile ldns too, because the LTS version of
Ubuntu Server does not have the "recent enough" libldns package. So for me
(and maybe for many people) this is just a disadvantage. Not everybody uses
"bleeding edge" distributions, I prefer more stable ones, that's why I am
using LTS versions of Ubuntu, for example. I think it's a must in a
sensitive environment, where stability is important (still, I may use
newer softwares, but I prefer to have as many packages/softwares from a
"stable" OS repository - like LTS/Ubuntu - as possible, and only compile a
single software by hand, which is the "heart" of the service the server
is created for. So I have a solid architecture I can build on).

Anyway, it's not my decision, and for sure I have no intent to start a flame
about this topic. If it's decided to be this way, it will be, period.

However, I am still having problems to get the "old behaviour". How can I
compile unbound to link against libldns statically? I couldn't figure out
without ugly hacks (see my previous mail), it seems even
"--enable-static-exe" does not work (and also it sounds a bit "dangerous"
when help of the configure script talks about "for debug purposes"), ldns
is still linked dynamically, at least output of ldd on unbound binary
shows libldns too.

6

IMHO, someone who knows how to manually hack .a files is in a much better
position to do custom downloading/compiling then those who can barely run
"./configure" and unknowingly end up with an older (possible insecure copy)
of ldns.

Also, if speed is that much of an issue, I recommend upgrading that 32bit
arch to some hardware available in the last what? five years?

As was pointed out earlier, other libraries like libevent/libev are also
not packaged with unbound, and might also be different versions compiled
with compile flags not ideal to you. Are you recompiling libevent manually
as well? Where do you draw the line?

ldns is not the unbound dns code. ldns is its own dns library used by many
other applications.

Paul

7

Zitat von Gábor Lénárt <lgb@lgb.hu>:

Hi,

>May i ask if it is really needed to exclude ldns from tarball? It
>was really handy to not download yet-another-tarball have a look
>at the checksums and move it to the right destination, than do
>configure/make for the libs and start over with unbound again. How
>many people actually need it to be excluded?

see many discussions here in the last. The debian and fedora maintainers
both asks for it to be decoupled, as the tar ball copy inside unbound is
confusing and can sometimes accidentally get linked by unbound if the
ldns dev/devel package is not installed. Staticly linked libraries on
systems are not good. If you think you have ldns 1.6.10 but unbound had
been statically linked to 1.6.9, you might have a security issue.....

Also, not every unbound requires a new ldns.

And of course, people use ldns and ldns-python without unbound.

I can be wrong here, but as far as I know unbound only used the "built-in"
ldns only if the specific configure option was used and it was not the
default (if I am wrong, it can be done to a non-default option, so it would
be used _only_ if someone is sure that they requested it at the time of
running ./configure). So I can't see why it can cause problems that unbound
provides the usage of built-in ldns and only if it is requested by the
person who compiles it. Debian/fedora maintainers should only not use the
--with-ldns-builtin switch of ./configure, it's simply that. Or did I miss
something here? Now, I have to compile ldns too, because the LTS version of
Ubuntu Server does not have the "recent enough" libldns package. So for me
(and maybe for many people) this is just a disadvantage. Not everybody uses
"bleeding edge" distributions, I prefer more stable ones, that's why I am
using LTS versions of Ubuntu, for example. I think it's a must in a
sensitive environment, where stability is important (still, I may use
newer softwares, but I prefer to have as many packages/softwares from a
"stable" OS repository - like LTS/Ubuntu - as possible, and only compile a
single software by hand, which is the "heart" of the service the server
is created for. So I have a solid architecture I can build on).

Anyway, it's not my decision, and for sure I have no intent to start a flame
about this topic. If it's decided to be this way, it will be, period.

However, I am still having problems to get the "old behaviour". How can I
compile unbound to link against libldns statically? I couldn't figure out
without ugly hacks (see my previous mail), it seems even
"--enable-static-exe" does not work (and also it sounds a bit "dangerous"
when help of the configure script talks about "for debug purposes"), ldns
is still linked dynamically, at least output of ldd on unbound binary
shows libldns too.

Me too!!
The systems i use Unbound don't have libldns from the OS packages at all because nothing is using it there. So without --with-libldns-builtin my options are:
- Install ldns from source with bad things happen if one day another application is using ldns from the OS
- Install ldns from the distribution but this are way too old on many systems (1.2.1 on Ubuntu 8.04 LTS)
- Try to hack around and get the old behaviour :frowning:
- Stick with Unbound provided from the distribution :frowning:

Regards

Andreas

8

>I agree. I prefer installing packages on a server, but for a DNS server, I
>prefer to compile the DNS server software itself, so it can be optimized etc
>etc. But now I have to compile ldns as well, since the one in the latest
>Ubuntu (LTS version) server is "not recent enough" :frowning: I compiled now ldns,
>but unbound links to libldns now runtime, which - I guess - is not optimal,
>since as far as I know shared libraries are PIC code, which causes some
>performance loss (especially on 32 bit architecture because there is not
>so much registers on 32 bit x86 platform). So even another difficulty now:
>try to figure out how I can make unbound to use libldns.a instead of .so ...
>Now I've modified libldns.la to have libldns.a as library_names but I guess
>it's a very ugly solution and better way should exist ...

IMHO, someone who knows how to manually hack .a files is in a much better
position to do custom downloading/compiling then those who can barely run
"./configure" and unknowingly end up with an older (possible insecure copy)
of ldns.

Ok, no flame war please, I didn't want that either :slight_smile: I am just thinking
that it's a bit odd explanation for me: it's about the situation that people
and distribution maintainers are confused that built-in version of ldns (in
unbound) is compiled, which can be confusing. Ok, that's a point. But it
should not be the default (I am not sure it was or not, I always specified
for the configure script), so then it's not so possible that someone using
the built-in copy of the ldns by mistake, since it must be asked from the
configure script to do so! So the real reason of my mail was only about
this question what made me thinking on the problem of this "confusing"
situation, which is not the case, at least in my opinion. Also, if unbound
ships ldns, it's not so possible to have an "old and buggy" ldns compiled in
by mistake, since if I upgrade unbound (by downloading and recompiling a
newer version) I will get a newer copy of ldns - at least I hope :slight_smile: -. By
contrast, it's possible that the distribution ships an outdated version of
ldns (like in my case: the newest LTS version of Ubuntu contain ldns which
is too old) so I think this can cause the "false feeling of security" not
the opposite when unbound ships ldns source as well. Anyway ...

Also, if speed is that much of an issue, I recommend upgrading that 32bit
arch to some hardware available in the last what? five years?

If you give me money, I do :slight_smile: Till that, I am trying to solve the
performance problem at the software side, even if it sounds odd. :frowning:

As was pointed out earlier, other libraries like libevent/libev are also
not packaged with unbound, and might also be different versions compiled
with compile flags not ideal to you. Are you recompiling libevent manually
as well? Where do you draw the line?

ldns is not the unbound dns code. ldns is its own dns library used by many
other applications.

Ok, your point is clear, and valid, I have to admit. And please do not treat
my mails as a flame topic starter ones. It's also clear that as an unbound
user I have to accept the decision of its developers, as I've already stated
in a previous mail of mine, too. Maybe I've already done some over-talking
on this topic, so I don't want to waste anyone's energy further here :slight_smile:

Thanks for your answer.

Regards,

- Gábor

9

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

May i ask if it is really needed to exclude ldns from tarball? It was really handy to not download yet-another-tarball have a look at the checksums and move it to the right destination, than do configure/make for the libs and start over with unbound again. How many people actually need it to be excluded?

see many discussions here in the last. The debian and fedora maintainers
both asks for it to be decoupled, as the tar ball copy inside unbound is
confusing and can sometimes accidentally get linked by unbound if the
ldns dev/devel package is not installed. Staticly linked libraries on
systems are not good. If you think you have ldns 1.6.10 but unbound had
been statically linked to 1.6.9, you might have a security issue.....

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

Also, not every unbound requires a new ldns.

But it is no error to use latest unbound with latest ldns, no?

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

Regards

Andreas

10

Our (Men & Mice) solution is to build ldns to be in /usr/local/ldns and
install it into its own directory (/usr/local/ldns-<version>), then
having a symlink /usr/local/ldns-1.6.10 -> /usr/local/ldns

We build Unbound with '--with-ldns=/usr/local/ldns'

This scheme prevents clashes with the ldns delivered with the OS.

free downloads of ldns build this way (RedHat, Solaris 10) are available
from
http://goo.gl/9ZC3U

We build libevent and libev the same way, as well as Unbound itself.

This allows multiple versions of the same software/library to be
installed and the versions can be switched by changing the symlink.

the private ldns is not in the library search path, it will not be used
by OS packaged applications.

Best regards

Carsten Strotmann

11

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

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

Paul

12

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

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.

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

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

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

Many Thanks

Andreas

13

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?

I don't know if NLnetlabs does that.

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

Just to clarify, I am Paul Wouters, not Wouter Wijngaards. Wouter runs the unbound
project, I merely ship it for fedora/rhel/centos.

Paul

14

Our (Men & Mice) solution is to build ldns to be in /usr/local/ldns and
install it into its own directory (/usr/local/ldns-<version>), then
having a symlink /usr/local/ldns-1.6.10 -> /usr/local/ldns

FWIW, there's a neat little utility that manages those symlinks for me.
It's called stow [1], and it allows me to switch between versions
easily. I've got a tiny writeup on stow at [2].

        -JP

[1]: http://www.gnu.org/software/stow/
[2]: http://jpmens.net/2010/11/24/flexible-package-management-for-your-local-system/

15

Hello,

May i ask if it is really needed to exclude ldns from tarball? It was
really handy to not download yet-another-tarball have a look at the
checksums and move it to the right destination, than do configure/make
for the libs and start over with unbound again. How many people
actually need it to be excluded?

This is a standard Unix-way to split projects into small, reusable and
replaceable pieces. As a Gentoo user I highly appreciate that bundled
package was removed from the tarball. This is a Gentoo policy to
use system libraries instead of bundled libs whenever possible, and
this is the very good policy I must say: this way system is kept
up-to-date for all affected applications.

Best regards,
Andrew Savchenko

16

Hello,

17

Paul Wouters wrote:

see many discussions here in the last. The debian and fedora maintainers
both asks for it to be decoupled, as the tar ball copy inside unbound is
confusing and can sometimes accidentally get linked by unbound if the
ldns dev/devel package is not installed. Staticly linked libraries on
systems are not good. If you think you have ldns 1.6.10 but unbound had
been statically linked to 1.6.9, you might have a security issue.....

actually i don't think i've requested ldns to be unbundled from unbound
(i think that was ondrej, who is the ldns package maintainer), but i'm
happy to see the unbound source tarball a bit smaller and for it to be
impossible for bundled ldns to be used.

18

Hello,

19

[...]

However, I am still having problems to get the "old behaviour". How can I
compile unbound to link against libldns statically? I couldn't figure out
without ugly hacks (see my previous mail), it seems even
"--enable-static-exe" does not work (and also it sounds a bit "dangerous"
when help of the configure script talks about "for debug purposes"), ldns
is still linked dynamically, at least output of ldd on unbound binary
shows libldns too.

Build but _not_ install ldns <somewhere> with the configure option
--disable-shared. After that configure unbound to use your just built
ldns with --with-ldsn=<somewhere>, thats all :wink:

best regards
Juergen

20

Re,

> Not everybody uses
> "bleeding edge" distributions, I prefer more stable ones, that's why I am
> using LTS versions of Ubuntu, for example.

Then why are you using bleeding edge version of unbound? Really, you
should either not mix stable and most recent packages or mix them at

Hmmm, Bleeding edge means unstable (or at least the risk of unstability,
untested status, often alpha/beta/whatever quality, etc). Do you mean, that
the latest version of unbound is considered as unstable and/or not (safe)
"production ready"? I am not native English speaker (as you can notice it
for sure), but according to the definition, I've found:

"Bleeding edge technology refers to technology that is so new that it could
have a high risk of being unreliable and may incur greater expense in order
to use it."

So for example unbound 1.4.12 falls into this category? According to you it
is, since you name unbound 1.4.12 as "bleeding edge". As far as I can see,
newer unbound versions nowdays usually fixes bugs (ok, sometimes introducing
new features as well), but I never thought that they are not stable and/or
not recommended in production. But the opposite: it's a good idea to
upgrade especially if there are security fixes, for example. I think, if
most recent versions of unbound would be so "dangerous" and "new" ones,
security fixes would be provided against older versions too, but I don't
know about this in case of unbound, at least according to the site of
unbound 1.4.12 is simple the "current version" and the page also mentiones
that it fixes some issues.

When I speak about "bleeding edge" distributions (I talked about GNU/Linux
distributions, and NOT about unbound when I told "bleeding edge"), I also to
this meaning: like "Debian unstable" or testing, whatever. Though it can be
argueed that Debian is usually quite stable (even when called as
"unstable"): even the distributor use terms like "unstable" and "testing" to
name their distributions. I believe that they know what they're doing: if
they say, "unstable" and "development", then I don't use them in production
at least (my own computer/hobby server etc are another question). I don't
know too much about Fedora (I've never used it) but as far as I read about
it, it can also contain greater amount of very new solutions/software
versions/etc most distributions would use it later when it becomes more
stable and tested. So in this sense these are bleeding edge (so: not so
stable but the other hand: quite new stuffs, and maybe new and great
features, which can even generate flames, like systemd in Fedora, etc)
distributions.

Really, you should either not mix stable and most recent packages or mix them at
your own risk with your own responsibility, however the latter will
likely broke your system eventually.

"stable" and "most recent packages". Here, I guess you mean that "most
recent" = "not so stable" (as you mentioned "stabe" before as the opposite).
Then again: is version 1.4.12 of unbound is not stable? I thought it is.
I would call SVN repository of unbound as unstable/development/etc versions,
and released versions are stable. Am I wrong here?