Auth: TTL of NSEC3PARAM

jpmens commented 9 years ago

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 commented 7 years ago

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 commented 7 years ago

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

klaus3000 commented 7 years ago

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 commented 7 years ago

Does it cause validation errors in actual validating resolvers?

Habbie commented 2 years ago

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 commented 2 years ago

Does it cause validation errors in actual validating resolvers?

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

PowerDNS / pdns

Auth: TTL of NSEC3PARAM #2304