Auth: TTL of NSEC3PARAM

[jpmens]

When PowerDNS 3.4.3 slaves a zone, it assigns a TTL to the NSEC3PARAM which is derived from the SOA minimum:

dd.test. 3600    IN      NSEC3PARAM 1 0 5 BB4ACC9FD05587

irrespective of the TTL of the master zone. For example, OpenDNSSEC assigns a TTL of 0 to NSEC3PARAM records as does BIND, even though RFC 5155 says

The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL field.

So, the signed zone in OpenDNSSEC has the following 0 TTL:

dd.test. 0       IN      NSEC3PARAM      1 0 5 bb4acc9fd05587

The change in TTL for the record causes zone validators such as validns to complain:

$ dig @172.24.1.8 +onesoa dd.test axfr > dnstest.pdns3.axfr
$ ./validns dnstest.pdns3.axfr
dnstest.pdns3.axfr:23: dd.test. RRSIG's original TTL differs from corresponding record's
echo $?
1

Is there any way we can specify a TTL of 0 for the NSEC3PARAM record?

[klaus3000]

fyi: same problem is reported by dnssec-verify:

Verifying the zone using the following algorithms: RSASHA256.
TTL mismatch for example.at NSEC3PARAM keytag 31653

[Habbie]

Note that a 0 TTL will make caching for ANY queries suck.

[klaus3000]

Probably, and initially the problem occours due to Bind/OpenDNSSEC uses a TTL of 0. Nevertheless, changing the content of a pre-signed zone will cause validation errors.

[Habbie]

Does it cause validation errors in actual validating resolvers?

[Habbie]

OpenDNSSEC 1.3.11:

OPENDNSSEC-330: NSEC3PARAM TTL should be set to zero.

OpenDNSSEC 1.4.3:

OPENDNSSEC-330: NSEC3PARAM TTL can now be optionally configured in kasp.xml. Default value remains PT0S.

[vcunat]

Does it cause validation errors in actual validating resolvers?

Resolvers/validators shouldn't fail on lowered TTL. That's how forwarding can work.