From odsu at c20.ksac.uk  Mon May  3 11:39:17 2021
From: odsu at c20.ksac.uk (Colin Spensley)
Date: Mon, 3 May 2021 12:39:17 +0100
Subject: [Opendnssec-user] DNSKEY signature expired
Message-ID: <d02d1f66-f3af-918f-38d1-646caf0fd60d@c20.ksac.uk>

I have a zone managed by OpenDNSSEC 2 which now is not resolved by 
validating resolvers. The reason appears to be that the RRSIG over the 
DNSKEY RRset has been allowed to expire by ods-signer.

Ie. (crudely obfuscated):-

> my_domain.tld.		3600	IN	RRSIG	DNSKEY 13 3 3600 20210501213711 20210418073317 47867 my_domain.tld. BIzcTyvmGi/OcLaBdXMExes/iyHkrUC1qOhg4W4ybcjsS/zAXz65NJBa oojfCzX7gUo/DD9mXaMFZTyWm8iLpA==

The signer does run for the domain but does not regenerate this signature.

Can anyone suggest what might be causing this error?

Colin






From berry at nlnetlabs.nl  Mon May  3 12:01:36 2021
From: berry at nlnetlabs.nl (Berry van Halderen)
Date: Mon, 03 May 2021 14:01:36 +0200
Subject: [Opendnssec-user] DNSKEY signature expired
In-Reply-To: <d02d1f66-f3af-918f-38d1-646caf0fd60d@c20.ksac.uk>
References: <d02d1f66-f3af-918f-38d1-646caf0fd60d@c20.ksac.uk>
Message-ID: <97689ebc955ac76de890bb11619c9378@nlnetlabs.nl>

On 2021-05-03 13:39, Colin Spensley via Opendnssec-user wrote:
> I have a zone managed by OpenDNSSEC 2 which now is not resolved by
> validating resolvers. The reason appears to be that the RRSIG over the
> DNSKEY RRset has been allowed to expire by ods-signer.
> 
> Ie. (crudely obfuscated):-
> 
>> my_domain.tld.		3600	IN	RRSIG	DNSKEY 13 3 3600 20210501213711 
>> 20210418073317 47867 my_domain.tld. 
>> BIzcTyvmGi/OcLaBdXMExes/iyHkrUC1qOhg4W4ybcjsS/zAXz65NJBa 
>> oojfCzX7gUo/DD9mXaMFZTyWm8iLpA==
> 
> The signer does run for the domain but does not regenerate this 
> signature.
> 
> Can anyone suggest what might be causing this error?
> 

Your log should provide more information.  There should be some logging 
lines, probably in /var/log/messages indicating that "ods-signer" has 
some error.  I would suggest a grep ods-signer /var/log/messages.

\Berry

From odsu at c20.ksac.uk  Mon May  3 13:01:20 2021
From: odsu at c20.ksac.uk (Colin Spensley)
Date: Mon, 3 May 2021 14:01:20 +0100
Subject: [Opendnssec-user] DNSKEY signature expired
In-Reply-To: <97689ebc955ac76de890bb11619c9378@nlnetlabs.nl>
References: <d02d1f66-f3af-918f-38d1-646caf0fd60d@c20.ksac.uk>
 <97689ebc955ac76de890bb11619c9378@nlnetlabs.nl>
Message-ID: <e410b7d8-2515-f57a-1ade-916edaf02d6d@c20.ksac.uk>

Thank you. I should have been more diligent/comprehensive previously.

The immediate error is that ods-signer does not find a key (id: 
ca7e41658c07917f82ca1a77794a235d) that it is expecting.

May  1 05:35:11 my_server ods-signerd[1960]: [hsm] unable to get key: 
key ca7e41658c07917f82ca1a77794a235d not found
May  1 05:35:11 my_server ods-signerd[1960]: [hsm] hsm_get_dnskey(): Got 
NULL key
May  1 05:35:11 my_server ods-signerd[1960]: [hsm] unable to get key: 
hsm failed to create dnskey
May  1 05:35:11 my_server ods-signerd[1960]: [zone] unable to prepare 
signing keys for zone my_domain.tld: error getting dnskey
May  1 05:35:11 my_server ods-signerd[1960]: [worker[1]] CRITICAL: 
failed to sign zone my_domain.tld: General error
May  1 05:35:11 my_server ods-signerd[1960]: back-off task [sign] for 
zone my_domain.tld with 3600 seconds


Looking back through the logs however, this is because ods-enforcer 
purged that key from the HSM two weeks ago. The signconf file appears 
not to have been correspondingly updated though and is therefore now 
inconsistent. So I now have:-

In signconf/<my_domain.tld>.xml
------------------------
     <Keys>
       <TTL>PT1H</TTL>
       <Key>
         <Flags>257</Flags>
         <Algorithm>13</Algorithm>
         <Locator>4017f49c5510cd7747298b8cf5b07c63</Locator>
         <KSK/>
         <Publish/>
       </Key>
       <Key>
         <Flags>256</Flags>
         <Algorithm>13</Algorithm>
         <Locator>ca7e41658c07917f82ca1a77794a235d</Locator>
       </Key>
       <Key>
         <Flags>256</Flags>
         <Algorithm>13</Algorithm>
         <Locator>87fc66abfbe9fbb4f2eb97b02f31b0f9</Locator>
         <ZSK/>
         <Publish/>
       </Key>
     </Keys>

 From ods-enforcer key list -d
-----------------------------
my_domain.tld                  KSK           omnipresent  omnipresent 
omnipresent  NA           1    1    4017f49c5510cd7747298b8cf5b07c63
my_domain.tld                  ZSK           NA           omnipresent 
NA           omnipresent  1    1    87fc66abfbe9fbb4f2eb97b02f31b0f9

 From log:
---------
Apr 21 19:09:55 my_server ods-enforcerd[1936]: [enforcer] update zone: 
my_domain.tld
Apr 21 19:09:55 my_server ods-enforcerd[1936]: [enforcer] removeDeadKeys 
deleting key: ca7e41658c07917f82ca1a77794a235d
Apr 21 19:09:56 my_server ods-enforcerd[1936]: 
[hsm_key_factory_delete_key] looking for keys to purge from HSM
Apr 21 19:09:56 my_server ods-enforcerd[1936]: [hsm_key_factory_get_key] 
removing key ca7e41658c07917f82ca1a77794a235d from HSM
Apr 21 19:09:56 my_server ods-enforcerd[1936]: [enforcer] 
removeDeadKeys: keys deleted from HSM: 1
Apr 21 19:09:56 my_server ods-enforcerd[1936]: [enforcer] update: 
key_data_update() failed
Apr 21 19:09:57 my_server ods-enforcerd[1936]: [enforce_task] No changes 
to signconf file required for zone my_domain.tld

I'm guessing the significant error is the key_data_update failure and 
that it probably relates to the change made in 2.1.8.

I suspect that just manually forcing regeneration of the signconf would 
correct the immediate failure but, as this is occurring on a domain 
which is relatively unimportant for me, I would like to try to 
understand how/why the situation has arisen and how to correct it 
properly/elegantly. I'm also anxious to reassure myself that the same 
error is not about to occur on other, more critical zones.

Colin








On 03/05/2021 13:01, Berry van Halderen via Opendnssec-user wrote:
> On 2021-05-03 13:39, Colin Spensley via Opendnssec-user wrote:
>> I have a zone managed by OpenDNSSEC 2 which now is not resolved by
>> validating resolvers. The reason appears to be that the RRSIG over the
>> DNSKEY RRset has been allowed to expire by ods-signer.
>>
>> Ie. (crudely obfuscated):-
>>
>>> my_domain.tld.??????? 3600??? IN??? RRSIG??? DNSKEY 13 3 3600 
>>> 20210501213711 20210418073317 47867 my_domain.tld. 
>>> BIzcTyvmGi/OcLaBdXMExes/iyHkrUC1qOhg4W4ybcjsS/zAXz65NJBa 
>>> oojfCzX7gUo/DD9mXaMFZTyWm8iLpA==
>>
>> The signer does run for the domain but does not regenerate this 
>> signature.
>>
>> Can anyone suggest what might be causing this error?
>>
> 
> Your log should provide more information.? There should be some logging 
> lines, probably in /var/log/messages indicating that "ods-signer" has 
> some error.? I would suggest a grep ods-signer /var/log/messages.
> 
> \Berry
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

From berry at nlnetlabs.nl  Mon May  3 13:25:38 2021
From: berry at nlnetlabs.nl (Berry van Halderen)
Date: Mon, 03 May 2021 15:25:38 +0200
Subject: [Opendnssec-user] DNSKEY signature expired
In-Reply-To: <e410b7d8-2515-f57a-1ade-916edaf02d6d@c20.ksac.uk>
References: <d02d1f66-f3af-918f-38d1-646caf0fd60d@c20.ksac.uk>
 <97689ebc955ac76de890bb11619c9378@nlnetlabs.nl>
 <e410b7d8-2515-f57a-1ade-916edaf02d6d@c20.ksac.uk>
Message-ID: <1cef605e1c899eddfc69adfbc6ef0aa2@nlnetlabs.nl>

On 2021-05-03 15:01, Colin Spensley via Opendnssec-user wrote:
> Thank you. I should have been more diligent/comprehensive previously.
> 
> The immediate error is that ods-signer does not find a key (id:
> ca7e41658c07917f82ca1a77794a235d) that it is expecting.
> 
> May  1 05:35:11 my_server ods-signerd[1960]: [hsm] unable to get key:
> key ca7e41658c07917f82ca1a77794a235d not found
> May  1 05:35:11 my_server ods-signerd[1960]: [hsm] hsm_get_dnskey():
> Got NULL key
> May  1 05:35:11 my_server ods-signerd[1960]: [hsm] unable to get key:
> hsm failed to create dnskey
> May  1 05:35:11 my_server ods-signerd[1960]: [zone] unable to prepare
> signing keys for zone my_domain.tld: error getting dnskey
> May  1 05:35:11 my_server ods-signerd[1960]: [worker[1]] CRITICAL:
> failed to sign zone my_domain.tld: General error
> May  1 05:35:11 my_server ods-signerd[1960]: back-off task [sign] for
> zone my_domain.tld with 3600 seconds
> 
> 
> Looking back through the logs however, this is because ods-enforcer
> purged that key from the HSM two weeks ago. The signconf file appears
> not to have been correspondingly updated though and is therefore now
> inconsistent. So I now have:-
> 
> In signconf/<my_domain.tld>.xml
> ------------------------
>     <Keys>
>       <TTL>PT1H</TTL>
>       <Key>
>         <Flags>257</Flags>
>         <Algorithm>13</Algorithm>
>         <Locator>4017f49c5510cd7747298b8cf5b07c63</Locator>
>         <KSK/>
>         <Publish/>
>       </Key>
>       <Key>
>         <Flags>256</Flags>
>         <Algorithm>13</Algorithm>
>         <Locator>ca7e41658c07917f82ca1a77794a235d</Locator>
>       </Key>
>       <Key>
>         <Flags>256</Flags>
>         <Algorithm>13</Algorithm>
>         <Locator>87fc66abfbe9fbb4f2eb97b02f31b0f9</Locator>
>         <ZSK/>
>         <Publish/>
>       </Key>
>     </Keys>
> 
> From ods-enforcer key list -d
> -----------------------------
> my_domain.tld                  KSK           omnipresent  omnipresent
> omnipresent  NA           1    1    4017f49c5510cd7747298b8cf5b07c63
> my_domain.tld                  ZSK           NA           omnipresent
> NA           omnipresent  1    1    87fc66abfbe9fbb4f2eb97b02f31b0f9
> 
> From log:
> ---------
> Apr 21 19:09:55 my_server ods-enforcerd[1936]: [enforcer] update zone:
> my_domain.tld
> Apr 21 19:09:55 my_server ods-enforcerd[1936]: [enforcer]
> removeDeadKeys deleting key: ca7e41658c07917f82ca1a77794a235d
> Apr 21 19:09:56 my_server ods-enforcerd[1936]:
> [hsm_key_factory_delete_key] looking for keys to purge from HSM
> Apr 21 19:09:56 my_server ods-enforcerd[1936]:
> [hsm_key_factory_get_key] removing key
> ca7e41658c07917f82ca1a77794a235d from HSM
> Apr 21 19:09:56 my_server ods-enforcerd[1936]: [enforcer]
> removeDeadKeys: keys deleted from HSM: 1
> Apr 21 19:09:56 my_server ods-enforcerd[1936]: [enforcer] update:
> key_data_update() failed
> Apr 21 19:09:57 my_server ods-enforcerd[1936]: [enforce_task] No
> changes to signconf file required for zone my_domain.tld
> 
> I'm guessing the significant error is the key_data_update failure and
> that it probably relates to the change made in 2.1.8.
> 
> I suspect that just manually forcing regeneration of the signconf
> would correct the immediate failure but, as this is occurring on a
> domain which is relatively unimportant for me, I would like to try to
> understand how/why the situation has arisen and how to correct it
> properly/elegantly. I'm also anxious to reassure myself that the same
> error is not about to occur on other, more critical zones.
> 

OpenDNSSEC 2.1.9 will come out today or early tomorrow with a fix for 
this issue.
Meanwhile you can upgrade to the release candidate for it.  This will 
fix the
issue.

https://dist.opendnssec.org/source/testing/opendnssec-2.1.9rc1.tar.gz

This issue has been reported lately on the list and you situation seems 
identical,
or at least resolves this issue.  Please let me know it it works for 
you, this
will expedite my work.

\Berry

> 
> 
> 
> 
> 
> On 03/05/2021 13:01, Berry van Halderen via Opendnssec-user wrote:
>> On 2021-05-03 13:39, Colin Spensley via Opendnssec-user wrote:
>>> I have a zone managed by OpenDNSSEC 2 which now is not resolved by
>>> validating resolvers. The reason appears to be that the RRSIG over 
>>> the
>>> DNSKEY RRset has been allowed to expire by ods-signer.
>>> 
>>> Ie. (crudely obfuscated):-
>>> 
>>>> my_domain.tld.??????? 3600??? IN??? RRSIG??? DNSKEY 13 3 3600 
>>>> 20210501213711 20210418073317 47867 my_domain.tld. 
>>>> BIzcTyvmGi/OcLaBdXMExes/iyHkrUC1qOhg4W4ybcjsS/zAXz65NJBa 
>>>> oojfCzX7gUo/DD9mXaMFZTyWm8iLpA==
>>> 
>>> The signer does run for the domain but does not regenerate this 
>>> signature.
>>> 
>>> Can anyone suggest what might be causing this error?
>>> 
>> 
>> Your log should provide more information.? There should be some 
>> logging lines, probably in /var/log/messages indicating that 
>> "ods-signer" has some error.? I would suggest a grep ods-signer 
>> /var/log/messages.
>> 
>> \Berry
>> _______________________________________________
>> Opendnssec-user mailing list
>> Opendnssec-user at lists.opendnssec.org
>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

From berry at nlnetlabs.nl  Mon May  3 23:11:51 2021
From: berry at nlnetlabs.nl (Berry van Halderen)
Date: Tue, 04 May 2021 01:11:51 +0200
Subject: [Opendnssec-user] Release of OpenDNSSEC 2.1.9
Message-ID: <c08e3f7c64bdf15ec65dd4a689433770@nlnetlabs.nl>

Dear all,

Just released, OpenDNSSEC 2.1.9, available immediately from our regular
download site:

https://dist.opendnssec.org/source/opendnssec-2.1.9.tar.gz

SHA256: 6d1d466c8d7f507f3e665f4bfe4d16a68d6bff9d7c2ab65f852e2b2a821c28b5

This release contains two changes that avoid some problems with certain
HSM configuration, one of them is SoftHSMv2 in database back-end mode.
This can lead to temporarily not being able to sign zones, hence
upgrading is really recommended.  It does not occur on all systems
and configurations though.

Yours truly,
OpenDNSSEC

From odsu at c20.ksac.uk  Wed May  5 20:26:35 2021
From: odsu at c20.ksac.uk (Colin Spensley)
Date: Wed, 5 May 2021 21:26:35 +0100
Subject: [Opendnssec-user] DNSKEY signature expired
In-Reply-To: <1cef605e1c899eddfc69adfbc6ef0aa2@nlnetlabs.nl>
References: <d02d1f66-f3af-918f-38d1-646caf0fd60d@c20.ksac.uk>
 <97689ebc955ac76de890bb11619c9378@nlnetlabs.nl>
 <e410b7d8-2515-f57a-1ade-916edaf02d6d@c20.ksac.uk>
 <1cef605e1c899eddfc69adfbc6ef0aa2@nlnetlabs.nl>
Message-ID: <3831e9b1-7aae-0879-d95c-6f15a4c29668@c20.ksac.uk>


On 03/05/2021 14:25, Berry van Halderen via Opendnssec-user wrote:

> OpenDNSSEC 2.1.9 will come out today or early tomorrow with a fix for 
> this issue.
> Meanwhile you can upgrade to the release candidate for it.? This will 
> fix the
> issue.
> 
> https://dist.opendnssec.org/source/testing/opendnssec-2.1.9rc1.tar.gz
> 
> This issue has been reported lately on the list and you situation seems 
> identical,
> or at least resolves this issue.? Please let me know it it works for 
> you, this
> will expedite my work.
> 
> \Berry
> 

Thanks Berry and apologies for the delay in replying. I had to wait for 
2.1.9 to make it into FreeBSD ports, which it has only just done.

I confirm that on restarting the daemons following this upgrade, the 
zone which had been failing to sign was immediately resigned without any 
other actions being required.

Many thanks for all your efforts.

Colin

From F.Zwarts at KVI.nl  Thu May  6 11:40:33 2021
From: F.Zwarts at KVI.nl (Fred. Zwarts)
Date: Thu, 6 May 2021 13:40:33 +0200
Subject: [Opendnssec-user] Compilation problems in 2.1.9
Message-ID: <b189574f-53d2-0fc7-d53a-1d5eaa5e15c5@KVI.nl>

The last few weeks we had problems with 2.1.8, so today I tried to 
install 2.1.9 on our test system. When building it, we encountered some 
problems with the compilation. I saw the same problems in 2.1.8, but 
then there were more serious problems, so I forgot to mention them in 
this mail group.

This is information about the operating system:

> /etc/os-release
> ::::::::::::::
> NAME="SLES"
> VERSION="12-SP5"
> VERSION_ID="12.5"
> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP5"
> ID="sles"
> ANSI_COLOR="0;32"
> CPE_NAME="cpe:/o:suse:sles:12:sp5"

I downloaded the opendnssec-2.1.9.tar.gz file and extracted its contents 
in a directory.
I changed directory into the opendnssec-2.1.9 directory and I used 
"./configure" to prepare for building.
Then I used the "make" command, to build the programs. This continued 
for some time, but then it exited with the following messages:

> ../../common/scheduler/worker.h:38:1: warning: C++ style comments are 
> not allowed in ISO C90 [enabled by default]
> ?//~ #include <time.h>
> ?^
> ../../common/scheduler/worker.h:38:1: warning: (this will be reported 
> only once per input file) [enabled by default]
> adapter/adapi.c: In function ?adapi_process_rr?:
> adapter/adapi.c:329:13: error: ?for? loop initial declarations are 
> only allowed in C99 mode
> ???????????? for (int i = 0; i < strlen(str); i++) {
> ???????????? ^
> adapter/adapi.c:329:13: note: use option -std=c99 or -std=gnu99 to 
> compile your code
> Makefile:801: recipe for target 'adapter/adapi.o' failed
> make[2]: *** [adapter/adapi.o] Error 1
> make[2]: Leaving directory '/downloads/opendnssec-2.1.9/signer/src'
> Makefile:483: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/downloads/opendnssec-2.1.9/signer'
> Makefile:534: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1

 From these errors I concluded that I had to add the "-std=c99" option 
to the compiler, so I used:

export CFLAGS="-std=c99"
./configure
make clean
make

But then another errors was printed:

> ./wire/notify.h:64:21: error: field ?timeout? has incomplete type
> ???? struct timespec timeout;
> ???????????????????? ^
> Makefile:801: recipe for target 'daemon/signertasks.o' failed
> make[2]: *** [daemon/signertasks.o] Error 1
> make[2]: Leaving directory '/downloads/opendnssec-2.1.9/signer/src'
> Makefile:483: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/downloads/opendnssec-2.1.9/signer'
> Makefile:534: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1


I finally found a work-around with

unset CFLAGS
./configure
make clean
make

Then, when the above error caused an exit of the make, I entered the 
signer/src directory and I copied/pasted the latest gcc command shown, 
adding the -std=c99 option. Then I returned to the main directory and 
used "make" again, which continued to compile other source files. This I 
had to do for about three source files.
I have the impression that I now have a working set of programs, 
although I am a little bit worried having linked object files with 
different compiler options.

So, two questions:

1) Is there a way to use configure such that the compilation does not 
end with errors?
2) Is a mix of object files with and without the -std=c99 option dangerous?



From berry at nlnetlabs.nl  Thu May  6 13:17:00 2021
From: berry at nlnetlabs.nl (Berry van Halderen)
Date: Thu, 06 May 2021 15:17:00 +0200
Subject: [Opendnssec-user] Compilation problems in 2.1.9
In-Reply-To: <b189574f-53d2-0fc7-d53a-1d5eaa5e15c5@KVI.nl>
References: <b189574f-53d2-0fc7-d53a-1d5eaa5e15c5@KVI.nl>
Message-ID: <111c1b1b96681a750cc475adcc5ffdb6@nlnetlabs.nl>

On 2021-05-06 13:40, Fred. Zwarts via Opendnssec-user wrote:
> From these errors I concluded that I had to add the "-std=c99" option
> to the compiler, so I used:
> 
> export CFLAGS="-std=c99"
> ./configure
> make clean
> make
> 
> But then another errors was printed:
> 
>> ./wire/notify.h:64:21: error: field ?timeout? has incomplete type
>> ???? struct timespec timeout;
>> ???????????????????? ^
>> Makefile:801: recipe for target 'daemon/signertasks.o' failed
>> make[2]: *** [daemon/signertasks.o] Error 1
>> make[2]: Leaving directory '/downloads/opendnssec-2.1.9/signer/src'
>> Makefile:483: recipe for target 'all-recursive' failed
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory '/downloads/opendnssec-2.1.9/signer'
>> Makefile:534: recipe for target 'all-recursive' failed
>> make: *** [all-recursive] Error 1
> 
> 
> I finally found a work-around with
> 
> unset CFLAGS
> ./configure
> make clean
> make
> 
> Then, when the above error caused an exit of the make, I entered the
> signer/src directory and I copied/pasted the latest gcc command shown,
> adding the -std=c99 option. Then I returned to the main directory and
> used "make" again, which continued to compile other source files. This
> I had to do for about three source files.
> I have the impression that I now have a working set of programs,
> although I am a little bit worried having linked object files with
> different compiler options.
> 
> So, two questions:
> 
> 1) Is there a way to use configure such that the compilation does not
> end with errors?

I think if you use
     -std=gnu11
in stead of -std=c11 or -std=c99 you are in the clear.  So:
   CFLAGS=-std=gnu11 ./configure
This is caused because in some installation they use a compiler which 
supports c11,
but do not have the erratum for c11 included.

> 2) Is a mix of object files with and without the -std=c99 option 
> dangerous?

I think the linking will fail in this specific case because one part 
assumes
some names to be defined while the other doesn't include them.  In 
general it
is sometimes permissible, but I would avoid this.

\Berry

> 
> 
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

From randy at psg.com  Thu May  6 23:53:53 2021
From: randy at psg.com (Randy Bush)
Date: Thu, 06 May 2021 16:53:53 -0700
Subject: [Opendnssec-user] softhsm unable to get key
Message-ID: <m2y2crl8q6.wl-randy@psg.com>

# uname -a
FreeBSD rip.psg.com 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC  amd64
# pkg info opendnssec2 | head -1
opendnssec2-2.1.8
# pkg info softhsm | head -1
softhsm-1.3.8

all worked until a reboot this morning

none recently changed
# ls -l `which ods-signerd`
-rwxr-xr-x  1 root  wheel  385632 Mar 13 19:56 /usr/local/sbin/ods-signerd*
# ls -l `which ods-enforcerd`
-rwxr-xr-x  1 root  wheel  482984 Mar 13 19:56 /usr/local/sbin/ods-enforcerd*
# ls -l `which softhsm`
-rwxr-xr-x  1 root  wheel  57200 Jul  7  2019 /usr/local/bin/softhsm*

May  6 23:08:15 rip ods-signerd[705]: [hsm] unable to get key: key c659db9ce13d7f18518cd1bbe0a2f0d8 not found
May  6 23:08:15 rip ods-signerd[705]: [hsm] hsm_get_dnskey(): Got NULL key
May  6 23:08:15 rip ods-signerd[705]: [hsm] unable to get key: hsm failed to create dnskey
May  6 23:08:15 rip ods-signerd[705]: [zone] unable to prepare signing keys for zone sol.int: error getting dnskey
May  6 23:08:15 rip ods-signerd[705]: [worker[1]] CRITICAL: failed to sign zone sol.int: General error

and same for all signed zones

but

    # sqlite3 /usr/local/var/softhsm/slot0.db ".backup foo"
    # ls -l foo
    -rw-r--r--  1 root  wheel  316416 May  6 23:29 foo

still duckduckgoing for how to see if sqlite3 has that key, c659db9ce13d7f18518cd1bbe0a2f0d8

but

    # softhsm --show-slot
    Available slots:
    Slot 0 
	       Token present: yes
	       Token initialized: yes
	       User PIN initialized: yes
	       Token label: opendnssec

and

    # softhsm --export test --slot 0 --pin no-way --id c659db9ce13d7f18518cd1bbe0a2f0d8
    Error: Could not find the private key with ID = c659db9ce13d7f18518cd1bbe0a2f0d8

but

    # ods-enforcer key list -v -z ymbk.com
    Keys:
    Zone:                           Keytype: State:    Date of next transition: Size: Algorithm: CKA_ID:                          Repository: KeyTag:
    ymbk.com                        KSK      active    2021-06-28 21:37:27      2048  8          52d55ded0e4a06b444774b9daf9ad050 SoftHSM     53482
    ymbk.com                        ZSK      active    2021-06-28 21:37:27      2048  8          a7f2aa72ecb73b40970abe2b4ffc353e SoftHSM     52456

though i am not sure enforcer is calling softhsm or just looking in its
back pocket

so i

restarted opendnssec
played my backup script
    ods-enforcer backup prepare
    sqlite3 /usr/local/var/softhsm/slot0.db ".backup `date '+%y%m%d'`.softhsm-copy.db"
    ods-enforcer backup commit
tried a reboot

an hour searching the net of a million lies was no help.  similar
problems with much older versions.

i once tried to upgrade to softhsm2 and had to back off after major
mess.  willing to try again if i can find a recipe.

the only possible hint is from a couple of days back, port upgrade of
sqlite3

    bind-tools-9.16.13                 <   needs updating (remote has 9.16.15)
    bind916-9.16.13                    <   needs updating (remote has 9.16.15)
    sqlite3-3.34.1_1,1                 <   needs updating (remote has 3.35.5,1)

clues very much appreciated

randy

---
randy at psg.com
`gpg --locate-external-keys --auto-key-locate wkd randy at psg.com`
signatures are back, thanks to dmarc header butchery

From berry at nlnetlabs.nl  Fri May  7 00:22:00 2021
From: berry at nlnetlabs.nl (Berry van Halderen)
Date: Fri, 07 May 2021 02:22:00 +0200
Subject: [Opendnssec-user] softhsm unable to get key
In-Reply-To: <m2y2crl8q6.wl-randy@psg.com>
References: <m2y2crl8q6.wl-randy@psg.com>
Message-ID: <7b6fb9618956d3ce4c0ffe8cb77e7468@nlnetlabs.nl>

On 2021-05-07 01:53, Randy Bush via Opendnssec-user wrote:
> # uname -a
> FreeBSD rip.psg.com 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC  
> amd64
> # pkg info opendnssec2 | head -1
> opendnssec2-2.1.8
> # pkg info softhsm | head -1
> softhsm-1.3.8

Dear Randy,

OpenDNSSEC 2.1.9 is out, which solves this issue I think.

The problem is that certain HSMs (amongst which SoftHSM in database
backend mode) have a funny behaviour.

\Berry


> all worked until a reboot this morning
> 
> none recently changed
> # ls -l `which ods-signerd`
> -rwxr-xr-x  1 root  wheel  385632 Mar 13 19:56 
> /usr/local/sbin/ods-signerd*
> # ls -l `which ods-enforcerd`
> -rwxr-xr-x  1 root  wheel  482984 Mar 13 19:56 
> /usr/local/sbin/ods-enforcerd*
> # ls -l `which softhsm`
> -rwxr-xr-x  1 root  wheel  57200 Jul  7  2019 /usr/local/bin/softhsm*
> 
> May  6 23:08:15 rip ods-signerd[705]: [hsm] unable to get key: key
> c659db9ce13d7f18518cd1bbe0a2f0d8 not found
> May  6 23:08:15 rip ods-signerd[705]: [hsm] hsm_get_dnskey(): Got NULL 
> key
> May  6 23:08:15 rip ods-signerd[705]: [hsm] unable to get key: hsm
> failed to create dnskey
> May  6 23:08:15 rip ods-signerd[705]: [zone] unable to prepare signing
> keys for zone sol.int: error getting dnskey
> May  6 23:08:15 rip ods-signerd[705]: [worker[1]] CRITICAL: failed to
> sign zone sol.int: General error
> 
> and same for all signed zones
> 
> but
> 
>     # sqlite3 /usr/local/var/softhsm/slot0.db ".backup foo"
>     # ls -l foo
>     -rw-r--r--  1 root  wheel  316416 May  6 23:29 foo
> 
> still duckduckgoing for how to see if sqlite3 has that key,
> c659db9ce13d7f18518cd1bbe0a2f0d8
> 
> but
> 
>     # softhsm --show-slot
>     Available slots:
>     Slot 0
> 	       Token present: yes
> 	       Token initialized: yes
> 	       User PIN initialized: yes
> 	       Token label: opendnssec
> 
> and
> 
>     # softhsm --export test --slot 0 --pin no-way --id
> c659db9ce13d7f18518cd1bbe0a2f0d8
>     Error: Could not find the private key with ID =
> c659db9ce13d7f18518cd1bbe0a2f0d8
> 
> but
> 
>     # ods-enforcer key list -v -z ymbk.com
>     Keys:
>     Zone:                           Keytype: State:    Date of next
> transition: Size: Algorithm: CKA_ID:
> Repository: KeyTag:
>     ymbk.com                        KSK      active    2021-06-28
> 21:37:27      2048  8          52d55ded0e4a06b444774b9daf9ad050
> SoftHSM     53482
>     ymbk.com                        ZSK      active    2021-06-28
> 21:37:27      2048  8          a7f2aa72ecb73b40970abe2b4ffc353e
> SoftHSM     52456
> 
> though i am not sure enforcer is calling softhsm or just looking in its
> back pocket
> 
> so i
> 
> restarted opendnssec
> played my backup script
>     ods-enforcer backup prepare
>     sqlite3 /usr/local/var/softhsm/slot0.db ".backup `date
> '+%y%m%d'`.softhsm-copy.db"
>     ods-enforcer backup commit
> tried a reboot
> 
> an hour searching the net of a million lies was no help.  similar
> problems with much older versions.
> 
> i once tried to upgrade to softhsm2 and had to back off after major
> mess.  willing to try again if i can find a recipe.
> 
> the only possible hint is from a couple of days back, port upgrade of
> sqlite3
> 
>     bind-tools-9.16.13                 <   needs updating (remote has 
> 9.16.15)
>     bind916-9.16.13                    <   needs updating (remote has 
> 9.16.15)
>     sqlite3-3.34.1_1,1                 <   needs updating (remote has 
> 3.35.5,1)
> 
> clues very much appreciated
> 
> randy
> 
> ---
> randy at psg.com
> `gpg --locate-external-keys --auto-key-locate wkd randy at psg.com`
> signatures are back, thanks to dmarc header butchery
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

From randy at psg.com  Fri May  7 00:37:58 2021
From: randy at psg.com (Randy Bush)
Date: Thu, 06 May 2021 17:37:58 -0700
Subject: [Opendnssec-user] softhsm unable to get key
In-Reply-To: <7b6fb9618956d3ce4c0ffe8cb77e7468@nlnetlabs.nl>
References: <m2y2crl8q6.wl-randy@psg.com>
 <7b6fb9618956d3ce4c0ffe8cb77e7468@nlnetlabs.nl>
Message-ID: <m2v97vl6op.wl-randy@psg.com>

>> # uname -a
>> FreeBSD rip.psg.com 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC
>> amd64

> OpenDNSSEC 2.1.9 is out, which solves this issue I think.

no binary package yet.  jaap!  puhleeze!  making from source drags in
massively

randy

---
randy at psg.com
`gpg --locate-external-keys --auto-key-locate wkd randy at psg.com`
signatures are back, thanks to dmarc header butchery

From randy at psg.com  Fri May  7 00:39:48 2021
From: randy at psg.com (Randy Bush)
Date: Thu, 06 May 2021 17:39:48 -0700
Subject: [Opendnssec-user] softhsm unable to get key
In-Reply-To: <m2v97vl6op.wl-randy@psg.com>
References: <m2y2crl8q6.wl-randy@psg.com>
 <7b6fb9618956d3ce4c0ffe8cb77e7468@nlnetlabs.nl>
 <m2v97vl6op.wl-randy@psg.com>
Message-ID: <m2tunfl6ln.wl-randy@psg.com>

> no binary package yet.  jaap!  puhleeze!  making from source drags in
> massively

and pulls softhsm2; and i had a massive mess last time i tried to
upgrade from v1

randy

From jaap at NLnetLabs.nl  Fri May  7 07:06:13 2021
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Fri, 07 May 2021 09:06:13 +0200
Subject: [Opendnssec-user] softhsm unable to get key
In-Reply-To: <m2v97vl6op.wl-randy@psg.com>
References: <m2y2crl8q6.wl-randy@psg.com>
 <7b6fb9618956d3ce4c0ffe8cb77e7468@nlnetlabs.nl> <m2v97vl6op.wl-randy@psg.com>
Message-ID: <202105070706.14776DRO090283@bela.nlnetlabs.nl>

 Randy Bush via Opendnssec-user writes:

 > >> # uname -a
 > >> FreeBSD rip.psg.com 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC
 > >> amd64
 >
 > > OpenDNSSEC 2.1.9 is out, which solves this issue I think.
 >
 > no binary package yet.  jaap!  puhleeze!  making from source drags in
 > massively

The binary packages are made in the FreeBSD kitchen, not by me. The
packet buildings machinery might takes days.

	jaap

From jaap at NLnetLabs.nl  Fri May  7 07:35:05 2021
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Fri, 07 May 2021 09:35:05 +0200
Subject: [Opendnssec-user] softhsm unable to get key
In-Reply-To: <m2tunfl6ln.wl-randy@psg.com>
References: <m2y2crl8q6.wl-randy@psg.com>
 <7b6fb9618956d3ce4c0ffe8cb77e7468@nlnetlabs.nl> <m2v97vl6op.wl-randy@psg.com>
 <m2tunfl6ln.wl-randy@psg.com>
Message-ID: <202105070735.1477Z5Cb047832@bela.nlnetlabs.nl>

 Randy Bush via Opendnssec-user writes:

 > > no binary package yet.  jaap!  puhleeze!  making from source drags in
 > > massively
 >
 > and pulls softhsm2; and i had a massive mess last time i tried to
 > upgrade from v1
 >

When building port, pulling in softhsm is optional (and default it
is off). When it is on, reconfigure the port (of make rmconfig).


	jaap

From randy at psg.com  Fri May  7 15:14:18 2021
From: randy at psg.com (Randy Bush)
Date: Fri, 07 May 2021 08:14:18 -0700
Subject: [Opendnssec-user] softhsm unable to get key
In-Reply-To: <7b6fb9618956d3ce4c0ffe8cb77e7468@nlnetlabs.nl>
References: <m2y2crl8q6.wl-randy@psg.com>
 <7b6fb9618956d3ce4c0ffe8cb77e7468@nlnetlabs.nl>
Message-ID: <m24kfepodx.wl-randy@psg.com>

> OpenDNSSEC 2.1.9 is out, which solves this issue I think.

the kindness of dr akkerhuis allowed me to install on a binary-only
freebsd.

i am not positive that 2.1.9 fixed the problem; but it definintely
suppressed the error messages :)

thanks!!

randy

From randy at psg.com  Fri May  7 19:58:37 2021
From: randy at psg.com (Randy Bush)
Date: Fri, 07 May 2021 12:58:37 -0700
Subject: [Opendnssec-user] logging
Message-ID: <m2fsyynwnm.wl-randy@psg.com>

2.1.9 on freebsd 12

conf.xml

        <Common>
            <Logging>
                <!-- Command line verbosity will overwrite configure file -->
                <Verbosity>3</Verbosity>
                <Syslog><Facility>local2</Facility></Syslog>
            </Logging>
	...

/etc/syslog.conf

    !opendnssec
    local2.*              /var/log/signer

and /usr/local/etc/rc.d/opendnssec does not alter logging in the start
command as far as i can tell

but

    # cat /var/log/signer
    #

randy

From jaap at NLnetLabs.nl  Sun May  9 11:26:21 2021
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Sun, 09 May 2021 13:26:21 +0200
Subject: [Opendnssec-user] logging
In-Reply-To: <m2fsyynwnm.wl-randy@psg.com>
References: <m2fsyynwnm.wl-randy@psg.com>
Message-ID: <202105091126.149BQLf4007830@bela.nlnetlabs.nl>

 Randy Bush via Opendnssec-user writes:

 > /etc/syslog.conf
 >
 >     !opendnssec
 >     local2.*              /var/log/signer
 >

Actyally, one needs something like:

!*
:programname, regex, "^ods.*"
local2.*                /var/log/signer

	jaap

PS. I too hate syslog.conf