Best practice TLSA RRs for CA-issued certs

[Viktor Dukhovni]

[ This assumes you are willing to trust your issuer CA to not
  misissue certificates for your domain, and include the CA
  certificate in your server chain file. ]

One approach to making sure that DANE TLSA records are less likely
to fail that should work well for sites using CA-issued certificates
is to publish both "3 1 1" and "2 1 1" TLSA records:

    mx.example. IN TLSA 3 1 1 <digest of server public key>
    mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key>

    * The "3 1 1" record protects against "expiration" accidents, and
      unexpected changes in the issuer's public key (if new certificate
      chain deployment is automated).

    * The "2 1 1" record protects against key rotation errors should a
      a new server private key be deployed without updating the TLSA
      RRs.  Provided the new certificate is issued by the same CA
      is unexpired, ... the "2 1 1" record will match.

With a bit of monitoring to ensure that both records match,
simultaneous failure of both is much less likely.

This even makes it possible to avoid pre-deployment DNS TLSA records
updates when rotating certificates, provided at least one of the
issuer public key or the server public key is unchanged in the new
chain.

In particular, this is the best practice with Let's Encrypt
issued SMTP server certificates, as explained in:

    https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/

-- 
	Viktor.