dnssec-tools-users Mailing List for dnssec tools

We've published the first pre-release of our upcoming 1.6 version of
DNSSEC-Tools.  You can get it from:

  http://www.dnssec-tools.org/download/

The quick list of "what's changed" is below:

 - New Features:
    - convertar:    - A new tool to translate a trust-anchor-repository
                      (TAR) from one format to another.  Supports
                      itar, xml, csv, bind, and libval TA formats.
    - rollerd:      - A new -noreload option to rollerd to not call rndc
    - dtconfchk     - Improved support for checking dnssec-tools.conf
                      content validity
    - dtinitconf:   - -genroothints supports fetching root.hints from the web
    - zonesigner:   - Supports setting the revoke bit
    - rollmgr:      - Supports Solaris now
    - lskrf         - Supports output of revoked keys
    - test suite:   - A new test suite for testing the tools (cd testing;
                      make test)
    - binaries:     - Support for producing self-contained
                      packed-binaries of the tools.  You can download
                      ones we build from http://www.dnssec-tools.org/download/
    - dtreqmods:    - A new script to check for DNSSEC-Tools required
                      perl modules.

 - libval changes:
    - Changed function prototypes and error codes to keep them compliant 
      with the current (-07) Validator API draft 
    - Added initial RFC 5155 NSEC3 support (configure --with-nsec3)
    - Optimized the referral processing and glue fetching logic so that 
      libval does a better job in trying to determine the referral zonecut, 
      and so that it is less aggressive in fetching missing glue. Also 
      allow for glue to be fetched on demand. 
    - Miscellaneous bug fixes 

 - Many miscellaneous small enhancements and bug fixes



-- 
Wes Hardaker
Cobham Analytic Solutions

Several of the DNSSEC-Tools scripts run other programs as part of their
execution.  As the tools are currently written, the full paths to the other
programs must be specified in the config file.

However, the DNSSEC-Tools group has had some discussion about this recently.
The possibility has been mentioned of changing the tools' behavior such that
the path is no longer required.  If the programs were specified just by name,
then the first instance in the user's path would be executed.  This would
allow for greater flexibility and for possibly making DNSSEC-Tools tool usage
easier when BIND, etc., are upgraded.  Specifying the absolute path would
continue to run that specific program.

The flexibility given by this is countered by the received wisdom of the
insecurity of path variables.  This holds that it is unsafe to rely on a
user's path variable, since path ordering is critical and may place
potentially unsafe directories before system directories in the search order.

As users of the DNSSEC-Tools scripts, what are your thoughts?  Do you want the
flexibility of using the user's path?  Do you think the potential insecurity
of relying on a user's path is overrated?

To get an idea of the choice we should have as a default, which of these
would you use:

         1) specified absolute paths
         2) user path-based invocations

Thanks for your help!

Wayne Morrison
SPARTA National Security Sector
Cobham Analytic Solutions

Hello Patrick,

I've been meaning to take a look at this for a while, but I've fallen  
a bit behind.

I believe that it should be possible to support split views with  
dnssec-tools using multiple keyref and rollrec files, but I need to  
explore this a little more and put together a wiki page on this. I'll  
start looking at this shortly.

Thanks!
Suresh

On Sep 16, 2009, at 12:09 PM , Patrick H. Piper wrote:

> Has there been any discussion on the use of Bind Views and dnssec- 
> tools?  Currently, dnssec-tools would not be able to fully support  
> Bind views due to the fact that you can define the same domain name  
> in different views.  I am pretty certain Rollerd and keyrecs don’t  
> have the ability to handle this condition currently.
>
> For example, the rollrec file would need to differentiate the  
> condition of zone.com that is defined in the “internal” view vs. the  
> “external” view.  In perl-speak, this would be analogous to a  
> HashOfHashes where the views are the outer hash keys and the list of  
> zones are contained in the inner hash.
>
> While I realize that it would not be best practice for implementing  
> “split” DNS using Bind Views and implementing DNSSEC on both views,  
> but it is a possible configuration none the less.
>
> Has there been any thought to this?
>
> Thanks!
>
> Patrick H. Piper
> NETLINX, Inc.
> pp...@ne...
> www.netlinxinc.com
> 435-649-3367 (office)    |    980-721-7694 (cell)
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf_______________________________________________
> dnssec-tools-users mailing list
> dns...@li...
> https://lists.sourceforge.net/lists/listinfo/dnssec-tools-users

When rollerd reaches phases 6, an email is sent via the subroutine
dt_adminmail().  When running dnssec-tools on a secure appliance (linux
32-bit variant) without sendmail installed this fails.  Dt_adminmail() uses
Mail::Send to do its work, which cycles through different mailers. It should
be possible to configure the dt_adminmail() subroutine to use SMTP instead
of sendmail and/or qmail etc.  

 

To get this to work, I manually updated dt_adminmail() with a change to line
124 of the release I was working with to:

 

$mh = $msg->open('smtp', Server=>'10.1.10.100');

 

This allowed our appliance to send mail w/o using sendmail and/or qmail. 

 

A suggestion would be to add a parameter or two to the dnssec-tools.conf
that specifies the mailer <ip|fqdn> and the mailer_type
<smtp|sendmail|qmail> and have the dt_adminmail() pick that up accordingly. 

 

Thoughts? 

 

Comments?

 

Thanks!

 

 

Patrick H. Piper

NETLINX, Inc.

 <mailto:pp...@ne...> pp...@ne...

 <http://www.netlinxinc.com> www.netlinxinc.com

435-649-3367 (office)    |    980-721-7694 (cell)

 

Has there been any discussion on the use of Bind Views and dnssec-tools?
Currently, dnssec-tools would not be able to fully support Bind views due to
the fact that you can define the same domain name in different views.  I am
pretty certain Rollerd and keyrecs don't have the ability to handle this
condition currently.  

 

For example, the rollrec file would need to differentiate the condition of
zone.com that is defined in the "internal" view vs. the "external" view.  In
perl-speak, this would be analogous to a HashOfHashes where the views are
the outer hash keys and the list of zones are contained in the inner hash.

 

While I realize that it would not be best practice for implementing "split"
DNS using Bind Views and implementing DNSSEC on both views, but it is a
possible configuration none the less. 

 

Has there been any thought to this? 

 

Thanks!

 

Patrick H. Piper

NETLINX, Inc.

 <mailto:pp...@ne...> pp...@ne...

 <http://www.netlinxinc.com> www.netlinxinc.com

435-649-3367 (office)    |    980-721-7694 (cell)

 

I would be interested in knowing if anyone has thought to implement
dnssec-tools with an HSM to store the keys and use PKCS#11 API.  Is it
possible? I am particularly interested in getting this working with SoftHSM
part of OpenDNSSEC's project. 

 

Any comments regarding the use of an HSM would be welcome. 

 

Patrick H. Piper

NETLINX, Inc.

 <mailto:pp...@ne...> pp...@ne...

 <http://www.netlinxinc.com> www.netlinxinc.com

435-649-3367 (office)    |    980-721-7694 (cell)

 

>>>>> On Tue, 15 Sep 2009 10:50:25 -0600, "Patrick H. Piper" <pp...@ne...> said:

PHP> I thought I had seen a recent thread on this. Sorry to bring it up without
PHP> doing more research. But, yes, I would expect to allow it to do its thing
PHP> unless explicit --prefix is provided. 

Ok, thanks for the input.  The most recent thread was a voice discussion
between a few of us, so you didn't miss it :-)

I thought I had seen a recent thread on this. Sorry to bring it up without
doing more research. But, yes, I would expect to allow it to do its thing
unless explicit --prefix is provided. 


Patrick H. Piper
NETLINX, Inc.
pp...@ne...
www.netlinxinc.com
435-649-3367 (office)    |    980-721-7694 (cell)

-----Original Message-----
From: Wes Hardaker [mailto:har...@us...] 
Sent: Tuesday, September 15, 2009 10:25 AM
To: Patrick H. Piper
Cc: dns...@li...
Subject: Re: [Dnssec-tools-users] how can the scripts be redirected to other
bindir?

>>>>> On Tue, 15 Sep 2009 09:52:58 -0600, "Patrick H. Piper"
<pp...@ne...> said:

PHP> When building and installing the dnssec-tools the script files are
PHP> getting installed in different bin directories depending on the
PHP> system I build on.

Patrick,

Thanks for the note and in fact we've recently been discussing just that
issue.

The problem, is unfortunately complex.  Perl has *its* notion of where
things should go, and configure/autoconf has *its* notion of where
things should go.  Right now, perl is taking precedence and our recent
thought was that we should let it unless configure is given with a
--prefix argument, in which case we'll force perl to use a different
install path.

Sound like an acceptable solution to you?  (if so, that'll be a good
data-point for us)
-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

>>>>> On Tue, 15 Sep 2009 09:52:58 -0600, "Patrick H. Piper" <pp...@ne...> said:

PHP> When building and installing the dnssec-tools the script files are
PHP> getting installed in different bin directories depending on the
PHP> system I build on.

Patrick,

Thanks for the note and in fact we've recently been discussing just that
issue.

The problem, is unfortunately complex.  Perl has *its* notion of where
things should go, and configure/autoconf has *its* notion of where
things should go.  Right now, perl is taking precedence and our recent
thought was that we should let it unless configure is given with a
--prefix argument, in which case we'll force perl to use a different
install path.

Sound like an acceptable solution to you?  (if so, that'll be a good
data-point for us)
-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

When building and installing the dnssec-tools the script files are getting
installed in different bin directories depending on the system I build on. 

 

I'm using build 4705 out of the SVN.

 

When I build on Fedora Linux the scripts/* get installed in /usr/local/bin

When I build on secure appliance (32-bit linux variant) the scripts/* get
installed in /usr/bin

 

How can I control where the scripts/* get installed?  I would like the
scripts to get installed in /usr/local/bin as it does on Fedora. I have
tried the following at the top level:

 

      cd dnssec-tools

    ./configure                 \

       --with-nsec3             \

       --with-dlv               \

       --with-ipv6              \

       --prefix=/usr/local      \

       --exec-prefix=/usr/local \

       --binddir=/usr/local/bin

 

This places only a few binaries in /usr/local/bin but the perl scripts are
still placed in /usr/bin.

 

If I examine the Makefile.PL in src/dnssec-tools/tools/scripts it shows that
INSTALLBIN=/usr/bin.  Is there something I can pass into that script to
force the paths to be /usr/local/bin?

 

Please advise. 

 

Thanks!

 

Patrick H. Piper

NETLINX, Inc.

 <mailto:pp...@ne...> pp...@ne...

 <http://www.netlinxinc.com> www.netlinxinc.com

435-649-3367 (office)    |    980-721-7694 (cell)

 

Grzegorz,
Can you post the rollrec file in use, please?  The zone file, the zone's
keyrec file, and the relevant chunks of the rollerd log file might also be
helpful.  Feel free to anonymize the names and addresses within the zone
file if you don't want to share that level of intimate detail.

				Wayne Morrison

--
Wayne Morrison
SPARTA National Security Sector
Cobham Analytic Solutions

>>>>> On Thu, 03 Sep 2009 14:27:08 +0200, Grzegorz Janoszka <Grz...@Ja...> said:

>> I recently got an email from rollerd. In fact it has been already about 
>> 6 months, when I deployed nssec. In the email rollerd asks to transfer 
>> the keyset to the parent.
>> 
>> I found an old dsset-* file in the zone directory, but there is no new 
>> one. Could you please point me, how I can generate new dsset file to be 
>> published at ripe db?
>> 
>> Thanks for any help, regards,

GJ> Hmmm... nobody uses rollerd for rolling keys? I do not want to start 
GJ> everything from scratch every six months.

Grzegorz,

Sorry for the delay.  I've been personally swamped with writing a
document this week and haven't gotten back to you about your question
(and apparently no one else has either).  We obviously need more
documentation for what information you need to transfer to your parent.

The dssset-* file should have *2* lines in it now, one DS record for
each of your keys.  It's both of those lines that need to be published
by your parent.  If your parent isn't signed and/or can't publish DS
records for you, you actually don't need to do anything. (in fact,
rollerd should have an option that you would allow you to specify that a
particular zone doesn't have a signed parent and it shouldn't pause
waiting for you to do a task that is meaningless).

Some parents may require the full public keys to be uploaded instead.
If that's the case, you'll need to give it your public key for the zone
that are named Kexample.com*.key for example.

-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

Grzegorz Janoszka wrote:
> I recently got an email from rollerd. In fact it has been already about 
> 6 months, when I deployed nssec. In the email rollerd asks to transfer 
> the keyset to the parent.
> 
> I found an old dsset-* file in the zone directory, but there is no new 
> one. Could you please point me, how I can generate new dsset file to be 
> published at ripe db?
> 
> Thanks for any help, regards,

Hmmm... nobody uses rollerd for rolling keys? I do not want to start 
everything from scratch every six months.

-- 
Grzegorz Janoszka

Hi,

I recently got an email from rollerd. In fact it has been already about 
6 months, when I deployed nssec. In the email rollerd asks to transfer 
the keyset to the parent.

I found an old dsset-* file in the zone directory, but there is no new 
one. Could you please point me, how I can generate new dsset file to be 
published at ripe db?

Thanks for any help, regards,

-- 
Grzegorz Janoszka

We're in the process now of moving the DNSSEC-Tools project's public
interfaces to different infrastructure.  Most of this move will be
transparent to end-users with a few exceptions (listed below).  I'll
send out further details as the rest of these changes become 

[I'd also like to take this time to apologize to the few people that
have sent patches or suggestions to the list recently that we haven't
responded to yet; be assured your messages were seen and will be
responded to shortly].

DNSSEC-Tools user-visible changes:

1) The mailing lists will be replaced with new ones with slightly
   different names.  You'll be notified when you are appropriately
   re-added to the future replacement lists.  You'll also be
   automatically removed from the older list as well.

2) The SVN repository URL will change.  When the switch is made I'll
   send another announcement regarding the "svn switch" command that
   you can run to change any SVN checkouts you have to point to the new
   repository site. 

3) We'll be switching to "Trac" for tracking bug reports and feature
   requests.  The DNSSEC-Tools website will direct you to the right
   place when the switch is made, so no further announcement is needed.

If you experience any problems with any of our web pages in the near
future as we make the changes, please let us know.  There isn't expected
to be any actual downtime since the services will be simply switched
live via DNS or other instantaneous changes.

-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

Hi, im trying to compile mozilla firefox from scratch with DNSSEC tools options

I've donwloaded and extracted dnssec-tools-1.5
and under validator
./configure
make all
make install all

Then I've download and extracted firefox-1.5.0.10-source.tar.bz2
I followed the section FIREFOX FROM SOURCE
dnssec-tools-1.5/apps/mozilla/README.firefox

and then mozilla errors like this:
./configure --enable-application=browser
make

.
.
.
gmake[3]: Entering directory `/root/mozilla/dbm/tests'
gcc -o lots  -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe  -DNDEBUG -DTRIMMED -O lots.o      -L../../dist/bin -L../../dist/lib -lmozdbm_s @VAL_LIBS@ -ldl -lm
gcc: @VAL_LIBS@: No such file or directory
gmake[3]: *** [lots] Error 1
gmake[3]: Leaving directory `/root/mozilla/dbm/tests'
gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory `/root/mozilla/dbm'
gmake[1]: *** [tier_1] Error 2
gmake[1]: Leaving directory `/root/mozilla'
make: *** [default] Error 2
[root@fc8 mozilla]#

I've also followed this:
http://www.dnssec-tools.org/wiki/index.php/Installing_on_Fedora

and started the mozilla firefox again, same error
my system is: Linux fc8 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:18:33 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

Im sure that what im asking is beyond the scope of dnssec-tools, but im no dev, so im a bit confused why the standard libraries are installed and these are not.


Thanks!



      

On Wed, Apr 22, 2009 at 10:33 AM, Casey Deccio <ca...@de...> wrote:
> I've been thinking about the case where a server might host multiple
> views (e.g., internal and external).  In this case, it seems that
> using the same set of keys on both views is the correct path.
> However, when the keys are rolled, the signing of zones from both
> views must be coordinated, and wait period must consider the max TTL
> from either zone.
>
> The current keyrec file specification doesn't seem to support this
> (that I'm aware of).  Has this come up before, or are there any
> thoughts as to how this might be handled?  Would the addition of a
> "view" record type (acquiring many of the current options from the
> "zone" type) be a useful addition to the keyrec file to support this?
>

I've attached a first attempt at implementing this in the 1.5 code.
Note that this only modifies the keyrec.pm module and the zonesigner
script; changes to other files have not been made at this point.  The
behavior is summarized below:

- Introduces a zoneview keyrec type, which assumes the zonefile,
signedzone, and serial fields (potentially the szopts field could be
added too).
- If a previous-generation keyrec file does not have a zoneview
keyrec, then one is created automatically with a default view
- The zone file manipulation and signing happens to the zone file for
each corresponding view for the zone, rather than just one
- If more than one view for a zone is detected (only possible through
a manually created or modified keyrec file at the moment), then any
filenames given on the command-line are discarded, in favor of those
specified in the views for the zone, as configured in the keyrec file.
 Warnings are issued if that happens.
- zone files, intermediate files, and signed files must be unique
across all views

There were also a couple of bugs:
- zonesigner uses $zonefile.".signed" over the signedzone field
specified in the keyrec file
- the double-dotting fix for "..signed" on the signed zone file was a
copy/paste error from "..zs"

It *shouldn't* change behavior for single view usage, but I haven't
done extensive testing yet.  Thoughts and feedback are welcome.

Regards,
Casey

Hi,

I've been thinking about the case where a server might host multiple
views (e.g., internal and external).  In this case, it seems that
using the same set of keys on both views is the correct path.
However, when the keys are rolled, the signing of zones from both
views must be coordinated, and wait period must consider the max TTL
from either zone.

The current keyrec file specification doesn't seem to support this
(that I'm aware of).  Has this come up before, or are there any
thoughts as to how this might be handled?  Would the addition of a
"view" record type (acquiring many of the current options from the
"zone" type) be a useful addition to the keyrec file to support this?

Regards,
Casey

Hi,

The serialincr() function in zonesigner uses the zonefile to increment
the serial.  In the case of dynamic zones the zonefile may not
necessarily be up-to-date, and it could change.  While the
administrator should probably be aware of this when running it
manually, I might suggest wrapping the calls to zonesigner from
rollerd with 'rndc freeze' and 'rndc unfreeze' of the zone.

There are, of course, caveats to this.  If there are multiple views,
then the view needs to be specified (to rndc), which means rollerd
needs to have some details about this view.  Also, if a zone isn't
dynamic rndc will return an error, which has the same exit status as
an error in freezing a legitimate zone (e.g., because it's already
frozen).  I'm not sure what other cases there might be, but in both
these cases, it seems safe to ignore the error--from the rollerd
perspective.  It should also be careful to always unfreeze the zone
regardless of any errors that happen after the freeze.

Thoughts?

Regards,
Casey

>>>>> On Tue, 14 Apr 2009 11:57:49 -0700, Ryan Cross <rya...@ho...> said:

RC> This posting may belong on the bugs mailing list, but that list looks
RC> overridden with spam.

The bugs list is actually supposed to be for notices from stuff
submitted to the bug database.

RC> The documentation (man pages and command syntax) for zonesigner v1.5
RC> lists the option to enable nsec3 support as "-nsec3" but the option is
RC> actually "-usensec3".

Thanks for pointing it out.  Fixed for the future!
-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

Hi,

This posting may belong on the bugs mailing list, but that list looks overridden with spam.

The documentation (man pages and command syntax) for zonesigner v1.5 lists the option to enable nsec3 support as "-nsec3" but the option is actually "-usensec3".

Ryan

_________________________________________________________________
Rediscover Hotmail®: Get quick friend updates right in your inbox. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates1_042009

>>>>> On Sun, 05 Apr 2009 23:05:45 +0200, Grzegorz Janoszka <Grz...@Ja...> said:

>> Rollerd isn't currently looking at the dnssec-tools.conf file for
>> zonesigner's location.  It uses the configured "prefix" +
>> "/bin/zonesigner". It appears that the prefix for your dnssec-tools
>> installation is set to '/'.

GJ> Yes, indeed it was. Are there plans for rollerd to use
GJ> dnssec-tools.conf file?

Yes, it should be using that file.  I actually think it's a bug because
I believe the original intent was to use the values from that file.
We'll track it down shortly and fix it for future releases.

GJ> Is it not possible to make rollerd just to look for the programs using 
GJ> the PATH variable? I think it would be much easier.

The original author of the rollerd program was strongly against using
the path for looking for programs.  Maybe an acceptable compromise would
be allowing for the dnssec-tools.conf file to allow for the word "path"
to indicate that searching via the path is the preferred lookup mechanism.

-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

Michael Baer wrote:
> Rollerd isn't currently looking at the dnssec-tools.conf file for
> zonesigner's location.  It uses the configured "prefix" +
> "/bin/zonesigner". It appears that the prefix for your dnssec-tools
> installation is set to '/'.

Yes, indeed it was. Are there plans for rollerd to use dnssec-tools.conf 
file?

> If you are using source, re-run configure with the '--prefix' option
> specified, make and install.  (if you did build previously with
> --prefix=/ and zonesigner was installed in /usr/local/bin, let us
> know as that shouldn't happen)

I was using source. I reconfigured it with prefix /usr/local, but again 
it was wrong, because it thought named binaries were in /usr/local/sbin. 
Now I reconfigured it again adding adequate option for sbin binaries, I 
am waiting for zsk cache expire to check if it is OK.

Is it not possible to make rollerd just to look for the programs using 
the PATH variable? I think it would be much easier.

Thank you for the support.

-- 
Grzegorz Janoszka

>>>>> On Mon, 30 Mar 2009 13:10:58 -0700, Ryan Cross <rya...@ho...> said:

RC> I am running DNSSEC-Tools Version 1.5.rc2.  "donuts" and "rollerd"
RC> both appear to have problems with SPF records in the zonefile.  For
RC> example, dounts aborts with the error:

RC> WARNING: failed to read [zonefile] for an unknown reason
RC> unrecognized type, line 20

Thanks for the info.  SPF records aren't being parsed by the
Net::DNS::ZoneFile::Fast module as you correctly noted.  I've attached a
patch that should fix this issue (and will apply it for future releases
as well; I'll publish a new copy of the module in CPAN immediately as well).
-- 
Wes Hardaker
SPARTA National Security Sector
Cobham Analytic Solutions

>>>>> On Sat, 28 Mar 2009 22:17:16 +0100, Grzegorz Janoszka <Grz...@Ja...> said:

Hi Grzegorz,

responses inline below,

    Grzegorz> Hello,

    Grzegorz> I tried using rollerd, but it has problem finding my
    Grzegorz> zonesigner binary. I have configured zonesigner
    Grzegorz> location in /etc/dnssec-tools/dnssec-tools.conf, but
    Grzegorz> it seems rollerd does not read this file.  I have
    Grzegorz> zonesigner in /usr/local/bin/zonesigner, but rollerd
    Grzegorz> logs:

    Grzegorz> Mar 28 14:31:06 2009: 8.f.a.1.2.0.0.2.ip6.arpa: ZSK
    Grzegorz> phase 4 (Adjusting keys in the keyrec and signing the
    Grzegorz> zone with new ZSK) Mar 28 14:31:06 2009:
    Grzegorz> 8.f.a.1.2.0.0.2.ip6.arpa: executing "//bin/zonesigner
    Grzegorz> -rollzsk 8.f.a.1.2.0.0.2.ip6.arpa
    Grzegorz> 8.f.a.1.2.0.0.2.ip6.arpa.signed" Mar 28 14:31:06 2009:
    Grzegorz> 8.f.a.1.2.0.0.2.ip6.arpa: ZSK phase 4: unable to
    Grzegorz> adjust ZSK keyrec

    Grzegorz> What should I do to force rollerd to use correct path
    Grzegorz> to zonesigner instead of //bin/zonesigner? I know I
    Grzegorz> can make a symlink at /bin, but it is not a solution,
    Grzegorz> it is a workaround...

Rollerd isn't currently looking at the dnssec-tools.conf file for
zonesigner's location.  It uses the configured "prefix" +
"/bin/zonesigner". It appears that the prefix for your dnssec-tools
installation is set to '/'.

A fix will depend on what kind of install you have (the version,
whether it's rpm or source). But if you have a new enough version of
the tools, you can set the environmental variable 'DT_PREFIX' before
running rollerd and it will use it as the prefix (e.g. for
/usr/local/bin/zonesigner, DT_PREFIX=/usr/local).

If you are using source, re-run configure with the '--prefix' option
specified, make and install.  (if you did build previously with
--prefix=/ and zonesigner was installed in /usr/local/bin, let us
know as that shouldn't happen)

If you are using an RPM install, you could try a newer rpm if
available (rebuilding the source rpm might work), or remove the rpm
and install from source.

-Mike

-- 
Michael Baer
ba...@us...