Modification of NSEC3 iteration and salt error/warning outputs

[vaceklu6]

Hello,
I would like to open disscussion about improvement of NSEC3 error and warning description.

Here is Lukas Vacek from CZ.NIC and we are running Zonemaster app in Czechia as TLD register. From our support team we know that some people have strugles with NSEC3 iteration and salt values. You can see the source of strugles in the picture. Error/Chyba says about wrong value of iterations.

I understand that this message is based on RFC 9276 and this RFC has in its tittle "best current practice". Something that recommends how to configure the NSEC3 parameters. I am, as a DNS administrator, for leave the error flag there but suggest to add to error message extra description. I would apriciate to see there why the Zonemaster app is telling me that this value is wrong. I would like to see some redirect to RFC based on why you have decided to recommend this value.

If someone takes values from latest proposed standard then the number of iterations can be over 150 (https://datatracker.ietf.org/doc/html/rfc5155#section-10.3)...

I looking forward to your thoughts.

Kind regards,
Lukas Vacek

[matsduf]

@vaceklu6, nice to get some input from you!

The test case specification has the motivation and references, https://doc.zonemaster.net/latest/specifications/tests/DNSSEC-TP/dnssec03.html. You will find the messages and their levels there, too.

I think that you ask for more verbose messages, or references to more verbose messages. We agree on that, especially the latter. The messages could be expanded, but not too much.

Do you also think that Zonemaster is too harsh on non-zero iterations and non-empty salt? If you read RFC 5155 it says that it has been updated by RFC 9276.

Yours,
Mats

[vaceklu6]

@matsduf, thank you for the answer. I did not know the link about motivation and references. It helps me to understand the messages.

Yes, I agree with any variant of verbose messages. We as a TLD registr do regularly checks of zones in registry. We run Zonemaster app on them. If there is something critical or error we send message to owner and notify them. Owners then look at the app output and see NSEC3 errors. Lot of time owners do not understand fully DNSSEC or NSEC3 and ask our support. I would like to have messages that self explain yourself. In best scenario it satisfied them and then they do not ask our support. To be honest I understand to them. In my opinion DNSSEC and NSEC3 is so complex and have many variables so it is hard to master it.

I do not think that Zonemaster is too harsh on non-zero iterations. RFC 9276 describes its benefits well. English is not my native language, but I think that is just odd to mark iterations as "Error" and then in message say "recommended". I would expect different word. About non-salt. I do not think that have any salt is bad. It can bring some security and do not break anything.

Thank you.

Kind regards,
Lukas Vacek

[matsduf]

I can agree with you that "ERROR" and "recommended" do not match well, and I am not that ERROR on non-zero iterations is reasonable. Maybe WARNING is better.

The messages are found in the specification on Github, https://github.com/zonemaster/zonemaster/blob/develop/docs/public/specifications/tests/DNSSEC-TP/dnssec03.md#summary. Could you look at those and suggest updates (longer messages) on the ones that you feel needs better wording? A pull-request would be great, or else an issue with your proposals.

When comes to salt I lean on https://www.rfc-editor.org/rfc/rfc9276.html#section-2.4 that argues that salt just costs without adding value.

[jtalir]

Hi @matsduf, do you think that changing ERROR to WARNING for non-zero iterations is doable? I understand that we could make a local change but we are afraid that different results from different instances would be confusing.

[matsduf]

Do you mind creating a pull request or an issue on that? Not on the implementation, but for the specification? I will support such a change.

[jtalir]

#1352

[jtalir]

Hi @matsduf, is there anything new with this pull request?

[matsduf]

Closed as resolved by #1352