From berry at nlnetlabs.nl  Mon Aug  5 11:15:45 2024
From: berry at nlnetlabs.nl (Berry van Halderen)
Date: Mon, 05 Aug 2024 13:15:45 +0200
Subject: [Opendnssec-user] "ods-enforcer key export" issue with MySQL
 backend (MariaDB) on OpenDNSSEC 2.1.13
In-Reply-To: <20240731121302.7c1a37f9@860-09-011.sidn.nl>
References: <60438e02-a9a8-4ba1-a168-9329ed3e2198@restena.lu>
 <20240731121302.7c1a37f9@860-09-011.sidn.nl>
Message-ID: <ff684ab3cc177fc181fd1ccf015aa7d6@nlnetlabs.nl>

On 2024-07-31 12:13, Stefan Ubbink via Opendnssec-user wrote:
> No output, while with 2.1.12 is gives a list of all keys and their
> backup state.
> 
>> Let me know if I can submit more details to help troubleshoot this
>> issue.
> 
> Sorry, I don't have any tips for your issue, but maybe the issue is not
> present in 2.1.12.

Dear all,

I haven't checked but I don't believe so.  I've debugged the issue and
can confirm the issue.  It is present only for the MySQL backend and 
only
when using the --all without the -k option.
Apparently the authors did not anticipate this case.

I think I can roll out a fix soon-ish, as I have a working patch at the
moment, but haven't done further checks.  The release would need to 
include
another fix.

With kind regards,
\Berry

From mefystofel at yahoo.com  Fri Aug 16 09:22:21 2024
From: mefystofel at yahoo.com (Roman Serbski)
Date: Fri, 16 Aug 2024 09:22:21 +0000 (UTC)
Subject: [Opendnssec-user] Denial of existence
References: <932513597.4483942.1723800141179.ref@mail.yahoo.com>
Message-ID: <932513597.4483942.1723800141179@mail.yahoo.com>

Hello,
OpenDNSSEC 2.1.13 running on FreeBSD 13.3.
Recently, dnsviz.net started reporting the lack of "Denial of existence" DNSSEC option error for all my domains:
ad2h.mydomain.org/A has errors; select the "Denial of existence" DNSSEC option to see them.mydomain.org/CDNSKEY has errors; select the "Denial of existence" DNSSEC option to see them.mydomain.org/CDS has errors; select the "Denial of existence" DNSSEC option to see them.mydomain.org/AAAA has errors; select the "Denial of existence" DNSSEC option to see them.mydomain.org/CNAME has errors; select the "Denial of existence" DNSSEC option to see them.
Is this due to TTL commented in my kasp.xml or I miss some other settings?
<Denial>?<NSEC3>?<!-- <TTL>PT0S</TTL> -->?<!-- <OptOut/> -->?<Resalt>P100D</Resalt>? <Hash>? ?<Algorithm>1</Algorithm>? ?<Iterations>5</Iterations>? ?<Salt length="8"/>? </Hash>?</NSEC3></Denial>
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20240816/0a15bd71/attachment.htm>

From he at uninett.no  Fri Aug 16 09:54:38 2024
From: he at uninett.no (Havard Eidnes)
Date: Fri, 16 Aug 2024 11:54:38 +0200 (CEST)
Subject: [Opendnssec-user] Denial of existence
In-Reply-To: <932513597.4483942.1723800141179@mail.yahoo.com>
References: <932513597.4483942.1723800141179.ref@mail.yahoo.com>
 <932513597.4483942.1723800141179@mail.yahoo.com>
Message-ID: <20240816.115438.1524907985917119077.he@uninett.no>

> OpenDNSSEC 2.1.13 running on FreeBSD 13.3.
>
> Recently, dnsviz.net started reporting the lack of "Denial of existence" DNSSEC
> option error for all my domains:
>
> ad2h.mydomain.org/A has errors; select the "Denial of existence" DNSSEC option to
> see them.
> mydomain.org/CDNSKEY has errors; select the "Denial of existence" DNSSEC option
> to see them.
> mydomain.org/CDS has errors; select the "Denial of existence" DNSSEC option to
> see them.
> mydomain.org/AAAA has errors; select the "Denial of existence" DNSSEC option to
> see them.
> mydomain.org/CNAME has errors; select the "Denial of existence" DNSSEC option to
> see them.
>
> Is this due to TTL commented in my kasp.xml or I miss some other settings?

It's commented out, so that ought not be the issue.

> <Denial>
>  <NSEC3>
>  <!-- <TTL>PT0S</TTL> -->
>  <!-- <OptOut/> -->
>  <Resalt>P100D</Resalt>
>   <Hash>
>    <Algorithm>1</Algorithm>
>    <Iterations>5</Iterations>
>    <Salt length="8"/>
>   </Hash>
>  </NSEC3>
> </Denial>

However, you didn't quote what the <Denial> stanza in your
<Policy>'s <Signature> / <Validity> entry looks like.  Mine looks
like this:

   <Policy name="xxx">
     <Signatures>
...
      <Validity>
        <Default>P21D</Default>
        <Denial>P21D</Denial>
      </Validity>
...

and I don't think I'm seeing this issue flagged from dnsviz.net.
We're also running OpenDNSSEC 2.1.13.

The current operational recommendation is to use
<Iterations>0</Iterations>, though, ref. RFC 9276 section 3.1.

Hm, I notice that the recomendation is also to have a zero salt
length, see the same RFC.

Transitioning from this config to the new, if you do OpenDNSSEC
as a "bump on the wire", you may need to remove OpenDNSSEC's
temporary files (copies of zones + parameters), and re-transfer
them by restarting OpenDNSSEC.  "Buyer beware!"  (I had to do
that when going to Iterations=0, anyway.  Your mileage may vary.)

Regards,

- H?vard

From he at uninett.no  Fri Aug 16 15:16:23 2024
From: he at uninett.no (Havard Eidnes)
Date: Fri, 16 Aug 2024 17:16:23 +0200 (CEST)
Subject: [Opendnssec-user] Removing a zone-less key?
Message-ID: <20240816.171623.1315180403363312783.he@uninett.no>

Hi,

I'm running OpenDNSSEC 2.1.13 and SoftHSM 2.6.1.

For some reason or other, "ods-enforcer key list -v" has started
showing this particular key:

(null)                          KSK      unknown   now                      2048  13         43ff9e6e2c011cd6165f25aa7ac6db83 SoftHSM     45696

It appears that the presence of this key makes "ods-enforcer key
list -z <any-zone>" crash ods-enforcerd with a SEGV, because in
perform_keystate_list() it doesn't check the return value of
key_data_get_zone() (which has several return paths which return
NULL) and consequently ends up calling zone_db_name() with a NULL
argument (which returns NULL), and using that as the first
argument to strcmp(), with predictable results.

The question is: how do I convince OpenDNSSEC that it should
forget about this key?

One would have thought that "ods-enforcer key purge -p <policy>"
would get rid of it.  Not so.  This command essentially does:

  for all zones in policy
     for all keys belonging to this zone
        if key is "dead"
           remove key

and since this particular key is not attached to a zone, it does
not get purged.

To work around this rather annoying issue, I have concocted this
particular patch to OpenDNSSEC:

--- enforcer/src/keystate/keystate_list_cmd.c.orig      2024-08-16 14:50:50.834836266 +0000
+++ enforcer/src/keystate/keystate_list_cmd.c
@@ -199,7 +199,11 @@ perform_keystate_list(int sockfd, db_con
         hsmkey = key_data_get_hsm_key(key);
         key_data_cache_key_states(key);
         tchange = map_keytime(zone, key); /* allocs */
-        if ((printkey != NULL) && (!zonename || !strcmp(zone_db_name(zone), zonename)) && (!keytype || !strcasecmp(keytype,key_data_role_text(key))) && (!keystate || !strcasecmp(keystate, map_keystate(key))))
+        if ((printkey != NULL) && 
+           (!zonename || (zone && !strcmp(zone_db_name(zone), zonename))) && 
+           (!keytype || !strcasecmp(keytype,key_data_role_text(key))) && 
+           (!keystate || !strcasecmp(keystate, map_keystate(key)))
+          )
             (*printkey)(sockfd, zone, key, tchange, hsmkey);
         free(tchange);
         hsm_key_free(hsmkey);

which fixes the crash in ods-enforcerd, and does not print that
un-attached key when you list the keys for a specific zone.
However, the key remains inside OpenDNSSEC even though I think I
managed to delete it from SoftHSM using pkcs11-tool from the
opensc package.

"Help!"

Regards,

- H?vard

From berry at nlnetlabs.nl  Wed Aug 21 13:45:55 2024
From: berry at nlnetlabs.nl (Berry van Halderen)
Date: Wed, 21 Aug 2024 15:45:55 +0200
Subject: [Opendnssec-user] Removing a zone-less key?
In-Reply-To: <20240816.171623.1315180403363312783.he@uninett.no>
References: <20240816.171623.1315180403363312783.he@uninett.no>
Message-ID: <16bb6d97da9785953f1879c5474bfe01@nlnetlabs.nl>

On 2024-08-16 17:16, Havard Eidnes via Opendnssec-user wrote:
> 
> For some reason or other, "ods-enforcer key list -v" has started
> showing this particular key:
> 
> (null)                          KSK      unknown   now
>      2048  13         43ff9e6e2c011cd6165f25aa7ac6db83 SoftHSM
> 45696
> 
> It appears that the presence of this key makes "ods-enforcer key
> list -z <any-zone>" crash ods-enforcerd with a SEGV, because in
> perform_keystate_list() it doesn't check the return value of
> key_data_get_zone() (which has several return paths which return
> NULL) and consequently ends up calling zone_db_name() with a NULL
> argument (which returns NULL), and using that as the first
> argument to strcmp(), with predictable results.
> 
> The question is: how do I convince OpenDNSSEC that it should
> forget about this key?

Hi Havard,

This is a very peculiar one.  Data corruption in OpenDNSSEC isn't 
something
one experiences, but this is one.  I'm very much wondering how this come 
to
bear.  Had you a crash that caused this one or something?
This is an orphaned key, but still attached to a zone, just that the 
zone is
gone.  So I can only see this happening when a zone deletion had a very
strange thing going on.
You probably can't find the cause back, so I'll contact you by e-mail 
how to
resolve this.  As keys have some connections to zones that also need 
cleaning,
and this isn't something for the list.  There's no way a normal command 
line
will resolve this and some DB queries are needed.

With kind regards,
\Berry

From oej at edvina.net  Wed Aug 21 14:07:22 2024
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 21 Aug 2024 16:07:22 +0200
Subject: [Opendnssec-user] SoftHSM is leaving the mothership
Message-ID: <1ADA23CB-3C36-449D-814A-8DA0A2488785@edvina.net>

Hi!

As you know, SoftHSM was created as a part of OpenDNSsec in the early days. Jakob and I have decided that it is time for SoftHSM to grow up and leave the mothership. We?re trying to allocate
resources to be able to handle open issues, PRs and taking SoftHSM into the future of post quantum crypto. NLnet labs are taking part in these discussions too.

If you or your company are interested in helping or are using SoftHSM - please let us know.

One problem is that someone has registred the name ?softhsm? on Github and we can?t get through and reach that person through Github. We?re met by too many legalities to be able to reach out. If you know who registred that name in Github let them know that we?re interested in moving in. It?s currently an empty project that needs some code, energy and HSM love.

We?re going to organise a virtual meet-and-greet for SoftHSM users in September. Let us know and you?ll be invited!

With PKCS11 greetings!

/Olle & Jakob


From list at mens.de  Wed Aug 21 14:22:14 2024
From: list at mens.de (Jan-Piet Mens)
Date: Wed, 21 Aug 2024 16:22:14 +0200
Subject: [Opendnssec-user] Removing a zone-less key?
In-Reply-To: <16bb6d97da9785953f1879c5474bfe01@nlnetlabs.nl>
References: <20240816.171623.1315180403363312783.he@uninett.no>
 <16bb6d97da9785953f1879c5474bfe01@nlnetlabs.nl>
Message-ID: <ZsX4Fq1s7XnJQvB9@rabbit.ww.mens.de>

>As keys have some connections to zones that also need cleaning,
>and this isn't something for the list.  There's no way a normal 
>command line will resolve this and some DB queries are needed.

It might interest the list how to resolve this, even if it's just
for posterity. https://xkcd.com/979/

	-JP

From he at uninett.no  Wed Aug 21 18:42:14 2024
From: he at uninett.no (Havard Eidnes)
Date: Wed, 21 Aug 2024 20:42:14 +0200 (CEST)
Subject: [Opendnssec-user] Removing a zone-less key?
In-Reply-To: <16bb6d97da9785953f1879c5474bfe01@nlnetlabs.nl>
References: <20240816.171623.1315180403363312783.he@uninett.no>
 <16bb6d97da9785953f1879c5474bfe01@nlnetlabs.nl>
Message-ID: <20240821.204214.1141284272050907516.he@uninett.no>

> This is a very peculiar one.  Data corruption in OpenDNSSEC
> isn't something one experiences, but this is one.  I'm very
> much wondering how this come to bear.  Had you a crash that
> caused this one or something?

There is a slight time-correlation with me upgrading the
installed package of OpenDNSSEC at the time, using a new binary:

-opendnssec2-2.1.13nb3 OSS for a fast and easy DNSSEC deployment
+opendnssec2-2.1.13nb4 OSS for a fast and easy DNSSEC deployment

(And I've of course since re-built it from source with that patch
I posted earlier.)

I think that at the same time, the softhsm package was
re-installed (version 2.6.1nb17, and yes, that "nb<num>" suffix
is from the packaging system I'm using).

The OS itself has not crashed, and this host has an, uhm, 338
days uptime at the time of writing.  (Which indicates that it's
probably time to re-fresh the base OS.)

> This is an orphaned key, but still attached to a zone, just
> that the zone is gone.  So I can only see this happening when a
> zone deletion had a very strange thing going on.  You probably
> can't find the cause back, so I'll contact you by e-mail how to
> resolve this.  As keys have some connections to zones that also
> need cleaning, and this isn't something for the list.  There's
> no way a normal command line will resolve this and some DB
> queries are needed.

Thanks a lot, I see that other message, and just need to "man up"
to doing the operation.

At least I found a patch / workaround to OpenDNSSEC which allowed
it to continue working even with this orphaned key present.

Best regards,

- H?vard