Assumption about TLSA records

[John]

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 at 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.