In zones signed by PowerDNS (so non-presigned zones), some TTL values need to be filled in by PowerDNS.
The TTL of RRSIG record sets is the TTL of the covered RRset.
-For CDS, CDNSKEY, DNSKEY, NSEC, NSEC3 and NSEC3PARAM, we use the SOA default TTL (the last number in the SOA record).
+For CDS, CDNSKEY, DNSKEY, NSEC, NSEC3 and NSEC3PARAM, we use the SOA minimum (the last number in the SOA record).
Except for CDS/CDNSKEY/DNSKEY, these TTLs are chosen because `RFC 4034 <https://tools.ietf.org/html/rfc4034>`__ demands it so.
-If you want a 'normal' TTL (3600, 86400, etc.) for your DNSKEY but a low TTL on negative answers, set your SOA default TTL to the high number, and set the TTL on the SOA record itself to the low TTL you want for negative answers.
-Note that the NSEC/NSEC3 records proving those negatives will get the high TTL in that case, and this may affect subsequent resolution in resolvers that do aggressive NSEC caching (`RFC 8198 <https://tools.ietf.org/html/rfc8198>`__).
\ No newline at end of file
+If you want a 'normal' TTL (3600, 86400, etc.) for your DNSKEY but a low TTL on negative answers, set your SOA minimum TTL to the high number, and set the TTL on the SOA record itself to the low TTL you want for negative answers.
+Note that the NSEC/NSEC3 records proving those negatives will get the high TTL in that case, and this may affect subsequent resolution in resolvers that do aggressive NSEC caching (`RFC 8198 <https://tools.ietf.org/html/rfc8198>`__).
+
+.. note::
+
+ This behaviour was changed in version 4.3.0.
+ We believe the language in RFC 4034 and 5155 about the NSEC(3) TTL is a mistake, and we have chosen to honour its spirit instead of its words.
+
+ NSEC(3) records now get the negative TTL (which is the lowest of the SOA TTL and the SOA minimum), which means their TTL matches that of an error such as NXDOMAIN.
+ The warning about RFC8198 no longer applies.
\ No newline at end of file