Thanks Willem! Just two comments:

• line 1820 of query.c: in the spirit of future maintainability, would it not be better to define a constant, for example “ZONEVERSION_SOA-SERIAL" with value 0 and referring to https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#zoneversion-type-values , just in case new ones appear in the future?
• in my patches on an older version of nsd, I added a “(RCODE(q->packet) == RCODE_OK)” condition to the option. At the moment I don't remember the reason for that test, but couldn't it be that we're returning zonerversion on some edge condition that shouldn't happen? Sorry, but I haven't compiled the code to do live compliance testing.

Thanks Willem! Just two comments:

Thanks for the prompt review @huguei

• line 1820 of query.c: in the spirit of future maintainability, would it not be better to define a constant, for example “ZONEVERSION_SOA-SERIAL" with value 0 and referring to https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#zoneversion-type-values , just in case new ones appear in the future?

Good point! I'll add that shortly.

• in my patches on an older version of nsd, I added a “(RCODE(q->packet) == RCODE_OK)” condition to the option. At the moment I don't remember the reason for that test, but couldn't it be that we're returning zonerversion on some edge condition that shouldn't happen?

But the last paragraph of Section 3.2 of RFC 9660, Responders states that ZONEVERSION should also be returned for NXDOMAIN and for SERVFAIL. So I reckoned that if nsd could find a zone for the question (i.e. the zone field in struct query is set) it can also return a ZONEVERSION for that zone regardless the kind of response. WDYT?

Sorry, but I haven't compiled the code to do live compliance testing.

I can do that for you and serve some zones on a droplet in digital ocean ;). Do you have a zone in mind (or several zones) for you to test?
I suppose we should capture those compliance tests in a test package, so you can review that script.