Unbound 1.4.16 release

Unbound
1

Hi,

Here is unbound 1.4.16, fixes bug in bugfix in 1.4.15:
http://unbound.nlnetlabs.nl/downloads/unbound-1.4.16.tar.gz
sha1: 68ed8737b1a6e3f9a67812f7e962fd6740494c1e
sha256: fb71665851eb11d3b1ad5dd5f9d7b167e0902628c06db3d6fc14afd95cc970fa

Fix in bugfix that for DNSSEC validators created validation failures.
Fix so that libunbound.so is versioned correctly. These bugs are from
1.4.15.

Features
o applied patch to support outgoing-interface with ub_ctx_set_option.

Bug Fixes
o Fix validation failures (like: validation failure xx: no NSEC3
closest encloser from yy for DS zz. while building chain of trust,
because of a bug in the TTL-fix in 1.4.15, it picked the wrong rdata
for an NSEC3. Now it does not change rdata, and fixes TTL.
o Fix version-number in libtool to be version-info so it produces
libunbound.so.2 like it should.
o Fixes for port to OpenIndiana OS with gcc 4.6.
o Fix to write key files completely to a temporary file, and if that
succeeds, replace the real key file. So failures leave a useful file.

Best regards,
   Wouter

2

thanks for the new release, however I think we have one regression
wrt ownership of the autotrust file, default /etc/unbound/root.key.

This file must be owned by the user unbound is running as, e.g. the
user unbound. Starting with version 1.4.15 unbound-anchor resets the
ownership to the user running unbound-anchor, which is normaly root.

Because of that the running unbound cannot longer update the key file,
which leasds to a error message:

Feb 2 12:33:43 tor unbound: [19568:0] error: could not open autotrust
file for writing, root.key.19568-0: Permission denied

thanks and regards
Juergen

3

Hi Juergen,

Here is unbound 1.4.16, fixes bug in bugfix in 1.4.15:

thanks for the new release, however I think we have one regression
wrt ownership of the autotrust file, default
/etc/unbound/root.key.

This file must be owned by the user unbound is running as, e.g.
the user unbound. Starting with version 1.4.15 unbound-anchor
resets the ownership to the user running unbound-anchor, which is
normaly root.

That is very inconvenient. This is because it writes to a temp first,
then moves it over the first.

Because of that the running unbound cannot longer update the key
file, which leasds to a error message:

Feb 2 12:33:43 tor unbound: [19568:0] error: could not open
autotrust file for writing, root.key.19568-0: Permission denied

No, it is not allowed to create a new file in the directory. It wants
to create a tempfile to write to, when that has worked, it'll mv the
new over the old. So that failures during the write leave you with a
bootable system.

That part is working: this error may be inconvenient, but the system
still boots.

I guess you have to chown unbound /my/keydir
or chgrp unbound /my/keydir

This sort of solution becomes system specific. What would work for you?

Best regards,
   Wouter

4

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

Hi Juergen,

>> Here is unbound 1.4.16, fixes bug in bugfix in 1.4.15:
>
> thanks for the new release, however I think we have one regression
> wrt ownership of the autotrust file, default
> /etc/unbound/root.key.
>
> This file must be owned by the user unbound is running as, e.g.
> the user unbound. Starting with version 1.4.15 unbound-anchor
> resets the ownership to the user running unbound-anchor, which is
> normaly root.

That is very inconvenient. This is because it writes to a temp first,
then moves it over the first.

It should be possible for unbound-anchor to preserve the ownership and
other file attributes of the old file and set the new created to the same?
If not we have a real problem, because after each call to unbound-anchor
we have reset the autotrust file to the correct attributes.

> Because of that the running unbound cannot longer update the key
> file, which leasds to a error message:
>
> Feb 2 12:33:43 tor unbound: [19568:0] error: could not open
> autotrust file for writing, root.key.19568-0: Permission denied

No, it is not allowed to create a new file in the directory. It wants
to create a tempfile to write to, when that has worked, it'll mv the
new over the old. So that failures during the write leave you with a
bootable system.

That part is working: this error may be inconvenient, but the system
still boots.

I guess you have to chown unbound /my/keydir
or chgrp unbound /my/keydir

This sort of solution becomes system specific. What would work for you?

Giving unbound write permissioons to /etc/unbound, which is the default
directory for the root.key file, is not a good idea IMO.
I'd prefer to put the autotrust anchor-file in a subdirectory, probably
/etc/unbound/anchor, and chown that directory to the user unbound is
running as. So we have a full path of /etc/unbound/anchor/root.key to
the autotrust file.

Of course I'll use what you decide to be the new default for unbound.
But keep in mind that this will only work at all if the above point
is solved and unbound-anchor preserves the owner of the file.

best regards
Juergen

5

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Juergen,
>
> >> Here is unbound 1.4.16, fixes bug in bugfix in 1.4.15:
> >
> > thanks for the new release, however I think we have one regression
> > wrt ownership of the autotrust file, default
> > /etc/unbound/root.key.
> >
> > This file must be owned by the user unbound is running as, e.g.
> > the user unbound. Starting with version 1.4.15 unbound-anchor
> > resets the ownership to the user running unbound-anchor, which is
> > normaly root.
>
> That is very inconvenient. This is because it writes to a temp first,
> then moves it over the first.

It should be possible for unbound-anchor to preserve the ownership and
other file attributes of the old file and set the new created to the same?
If not we have a real problem, because after each call to unbound-anchor
we have reset the autotrust file to the correct attributes.

After a second look I've to say that I was wrong and all of this is not
necessary.
Looks like that unbound changes the owner of the autotrust file just before
it gives up root privileges. So putting root.key in a directory, writable
by the user unbound is running as, works.

>
> > Because of that the running unbound cannot longer update the key
> > file, which leasds to a error message:
> >
> > Feb 2 12:33:43 tor unbound: [19568:0] error: could not open
> > autotrust file for writing, root.key.19568-0: Permission denied
>
> No, it is not allowed to create a new file in the directory. It wants
> to create a tempfile to write to, when that has worked, it'll mv the
> new over the old. So that failures during the write leave you with a
> bootable system.
>
> That part is working: this error may be inconvenient, but the system
> still boots.
>
> I guess you have to chown unbound /my/keydir
> or chgrp unbound /my/keydir
>
> This sort of solution becomes system specific. What would work for you?

Giving unbound write permissioons to /etc/unbound, which is the default
directory for the root.key file, is not a good idea IMO.
I'd prefer to put the autotrust anchor-file in a subdirectory, probably
/etc/unbound/anchor, and chown that directory to the user unbound is
running as. So we have a full path of /etc/unbound/anchor/root.key to
the autotrust file.

Of course I'll use what you decide to be the new default for unbound.

But keep in mind that this will only work at all if the above point
is solved and unbound-anchor preserves the owner of the file.

Not correct, see above.

best regards
Juergen

6

hi,
This error seams to affect the Windows (7) version of unbound just as well. I get numerous messages (at boot):
Log Name: Application
Source: unbound

7

Hi Mees,

Thanks for the error description, I have just found out that rename() is
not posix compliant on Windows. It does not remove the destination file
(and thus there is a race condition). Solved with an unlink() before
the rename, on windows.

The fix is in svn trunk. I can send you a compile of that snapshot, if
you want?

The impact without the fix is that root.key remains the same, which is
harmless. (Until the root key rolls over, then you must update to a
fixed unbound version).

Best regards,
   Wouter