This PR (still a draft because I need to add tests and discuss the extra parameter) fixes handling of implicit TTLs. The value from $TTL is used if available (propagated to $INCLUDEs too), otherwise the last stated TTL is used. There's one scenario (two actually) where TTLs must be handled differently and that is with SIG and RRSIG RRs. I've added an additional flags parameter to the callback signature so that the application can detect whether the TTL was specified implicitly or explicitly. If implicit, NSD (or any other application) might choose to fix-up the TTL after the covered RRSet has been parsed. Alternatively, NSD may choose to error out if the TTL was specified explicitly and it did not match the TTLs of the RRSet? To some extend, it depends on what is the usual way to handle mismatching TTLs. (functionality removed after internal discussion) @wcawijngaards, @wtoorop any thoughts on the chosen solution?
This PR (still a draft because I need to add tests and discuss the extra parameter) fixes handling of implicit TTLs. The value from
$TTLis used if available (propagated to$INCLUDEs too), otherwise the last stated TTL is used.There's one scenario (two actually) where TTLs must be handled differently and that is with(functionality removed after internal discussion) @wcawijngaards, @wtoorop any thoughts on the chosen solution?SIGandRRSIGRRs. I've added an additionalflagsparameter to the callback signature so that the application can detect whether the TTL was specified implicitly or explicitly. If implicit, NSD (or any other application) might choose to fix-up the TTL after the covered RRSet has been parsed. Alternatively, NSD may choose to error out if the TTL was specified explicitly and it did not match the TTLs of the RRSet? To some extend, it depends on what is the usual way to handle mismatching TTLs.