Thanks for speedy reply. I am assuming that past threads on TLSA records still hold. Therefore 3/1/1, with optional 2/1/1 depending upon root cert provenance.
On April 20, 2017 10:52:38 AM Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Thu, Apr 20, 2017 at 09:27:49AM -0400, John Allen wrote: On Thu, Apr 20, 2017 at 09:34:27AM -0400, John Allen wrote: On Thu, Apr 20, 2017 at 09:36:34AM -0400, John Allen wrote:
Is the following assumption reasonable?
if there are multiple TLSA dane-ee (type 3) records for a particular service, none of which match the current generated record, they can (maybe should) be deleted.
The same "rule" can be could be applied to dane type 2 records.
At all times, TLSA *RRsets* whose TTL has not yet expired (vended by either the primary or a secondary nameserver) need to contain at least one RR which matches the *current* certificate chain of the SMTP server.
To achieve this, the TLSA RRset stored in the master database needs the both the *current* certificate chain and any *new* certificate chain planned for deployment within the cache lifetime of recently served DNS responses.
There is no logical or de jure requirement to serve TLSA records that match *old* no longer deployed certificate chains. As soon as the certificate chain is replaced the old records should go.
In other words, the TLSA records reflect current and near-future certificate chain state, they need not and should not retain past state.
-- Viktor.
P.S. I deliberately said nothing about the certificate usage value, it should be clear why.