TL;DR If you're using DANE-TA(2) (certificate usage 2) TLSA records with Let's Encrypt cert chains, you need to augment the TLSA RRSet with additional digests for the upcoming "R3" and/or "E1" issuer CAs.
DANE-survey says, nobody has done this yet. Best to get on with it proactively.
See the dane-users post for more details.
Don't stop with just R3/E1. At any moment, Let's Encrypt can switch to the backup facility and start issuing from R4/E2 without prior notice. You should rather put all the possible TLSA records in, that means current X3 and X4 and future R3/E1 and R4/E2.
Also, don't forget to configure the server to provide proper intermediary certificate, otherwise those TLSA records are useless.
Yes, with DANE-TA(2) it is essential to use fullchain.pem (if using certbot) or more generally ensure that the server is configured to vend not only the leaf cert, but also the issuing intermediate certificate (or even the root CA cert, if publishing/relying on DANE-TA(2) records for a root CA).
Of course configuring a complete chain is also required in general, it is just less obvious because browsers come preloaded with or dynamically retrieve intermediate certs, but that's neither required nor universal.
While publishing also the backup CAs, don't go overboard with multiple TLSA record selectors or matching types, just "2 1 1" will do! You do not need "2 0 1", "2 1 2", ...
Publication of the new LE hashes is moving rather slowly:
# | CA
-----+----
978 | X3
32 | X4
15 | R3
9 | R4
15 | E1
10 | E2
By far the majority of MX hosts with LE DANE-TA(2) are still publishing just X3... 
Please update your TLSA DANE-TA(2) RRs before they start failing once your certificate updates are using R3 or E1 or the backup R4 and E2.
Users publishing DANE-TA(2) TLSA records matching just the "X3" CA really should get moving along, please see:
Thank you for the heads up, also my domain is on the list. One question; my domain/MTA just received a new cert:
root@box:/etc/letsencrypt/live/example.com# openssl x509 -text -in cert.pem |grep Issuer |grep Authority Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
root@box:/etc/letsencrypt/live/example.com# openssl x509 -text -in chain.pem |grep "Encrypt Authority" Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
and I publish these:
_25._tcp.example.com. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
Is it needed for me to publish the new one (with 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d) now already, or when my cert renewed / is issued with R3?
Got mail about this yesterday, Im on of those that didnt update yet, simply because I'm runing a script that after cert renew, it checks, if dane records are still correct and if they are not, doesnt not reload server configs and alerts me...
Is it known already when switch will be made? Because wasnt last date 29th of September and time tables where already moved couple of times... and also waiting for ISRG Root X2 to be active for my ECDSA certs, so i can get full ECDSA chain...
You should pre-publish the new CA hashes. That way, when the rollover happens, any DNS caches that have previously queried your TLSA records will already have the matching values. Otherwise, when your certificate rolls over, there'll be a temporary outage of your email system until all the caches expire.
This is in fact generally true of TLSA records, the matching value (be "2 1 1", "3 1 1", or whatever) needs to be in place a few TTLs (to also take into account replication latency to secondary DNS servers, ...) before the actual certificate deployment that depends on the new hash!
If you're manually activating newly obtained certificates only after TLSA records are updated, and have "aged" sufficiently long (at least 2*TTL is what I generally recommend, but this is not a precise requirement), then indeed you can wait to publish the hashes till then, though frankly it is not clear how delaying is helpful with "2 1 1".
With "3 1 1", and if the key rolled each time, then you can generate the TLSA RR when the key + cert are obtained, but before either is deployed, wait a few TTLs and then deploy. With "2 1 1" and the hashes already known, I don't see much point in delay.
Im using 2 0 1 + 3 1 1, however I do admit, I only wait an hour+ (3600s TTL on records) only if I remember (and usually i dont), but thing is its nothing is really critical on that domain, its just my home web&mail server that is not in high use anyway and is mostly testing enviroment... Why Im updating dane records only when I need to is simple, I want to keep DNS records clean and doing it like this is easier to track what should be there and is relevant and what is obsolete and again its my home testing environment for me, my brother and 2 coworkers, so if something is not accessible for an hour, its not the end of the world.
I understand your reasoning, and it makes some sense, but the risk is that if enough receiving systems have fragile DANE TLSA records that fail some fraction of the time, then sending systems have disincentives to deploy DANE. The sites sending you email may decide to disable DANE for your domain, or just not enable it at all, because otherwise avoidable email delays. So I'd like to encourage you to take a more disciplined approach, even if it is not compelling based on your requirements alone...
sorry for being late to the party - just received a notification mail
I updated my TLSA records for any dane secured services (apache and james) to use a 311 using the spki of my cert and 201 of the X1, X2 and X2-cross-by-X1 root certs
validators show now issues (one says "all TLSAs are good") - but as I requested my new cert it's still signed by the X3 - aren't new certs supposed to be issue by the new R3/E1 certs only?
for anyone interested: I'm usin the acme4j lib and request the cert via DNS validation (as required for wildcard certs)
X3 is still the active issuer. The switchover has not yet happened, which is a good thing, because you can take care of the required changes before you're surprised by breakage. As for new TLSA records, I strongly recommend "2 1 1" (with hashes of the public key) rather than "2 0 1" (hashes of the entire cert). I know that's a change from RFC 7671 (which I co-wrote), but sometimes one learns as one goes along...
Also, you should probably not use DANE-TA(2) with root CAs, they tend to not end up in your certificate chain files (e.g. certbot does not put them there), and some TLS stacks omit self-signed CAs from your chain even if you put them in the chain file. In the mean time DANE requires that DANE-TA(2) trust anchor certs be included in the presented chain. So publish the issuer CAs (R[34] and E[12]) not the roots.
well - feel free to correct me - but I don'T see any significant difference between hashing an entire certificate and just extracting the spki and hashing - typical certs are usually only a few 100 bytes at max - even when considering low-power devices like smartphones every device which does DANE validation should have enough power to also hash an entire cert instead of just a bytes of key material - as for validating a certificates signature it has to be hashed completely anyways ...
also: wikipedia says that a usage of 0 and 2 points to a trust ANCHOR - which, as far as I understand PKI, is the top-most root certificate - not some intermediate (aside from it's almost always root-intermediate-leaf certs - encounter 4 levels in the wild is extremely rare - and I've never seen any chain with more than 4 levels - even when there's some cross-sign stuff goin on which often is the 4th level in a otherwise just 3 level deep chain) - so as there're only two top-level certs and one cross-signed by the other every chain can be verified X1 - so instead of using R and E certs and even X2 just have one "2 0/1 1" record pointing to X1 should be sufficient for as long as X1 is valid - and after X1 runs out a record of X2 is the top of all ...
anyway - as I also have a record with usage 3 with a hash of my spki I shouldn't require any usage 2 at all - as using a usage 3 record tells the validator: "screw the whole PKI stuff - just validate this very cert - or just the key for that matter if the selector says so" - and unless the domain is secured by dnssec DANE is screwed anyway
but - maybe I'm completely wrong and need someone to tell me "common practice" ...
You can issue multiple certificates for the same keys. It is reasonable, unless you believe the keys leaked, to assume that say, a 2048-bit RSA key you minted in 2019 is still safe in 2021, but in the Web PKI nobody will issue you a certificate lasting so long. By default Certbot will just create new keys every time, but you can (and for DANE perhaps should) choose to pick a key less often and just issue new certificates for that same key when they need to be renewed, until you decide to replace the key. For normal security it seems perfectly reasonable to me to generate fresh 2048-bit RSA keys when new hardware is installed, and expect to use those keys for the entire normal economic life (often 3 years) of the hardware.
By writing DANE records for the key rather than certificate, you avoid having to emit new DANE records every few weeks when certificates are renewed, as the existing DANE record is acceptable for any certificate with that key.
Bindings to the SPKI are more robust. With EE certs you get the option to renew with the same key, avoiding the need to update the DNS with every automated cert renewal. With TA certs, you avoid depending on the exact details of the issuer's certificate, which may be presented with different signers (cross-certs) or may be renewed with the same key (though that 2nd scenario hasn't happened yet with Let's Encrypt CAs, and perhaps they just don't do that).
Anyway, it isn't about the CPU cycles, it is just that you gain nothing other than more fragile chain validation by specifying the full cert.
Roughly 1/3rd of the way there, but progress seems to have slowed considerably, it would be good if more operators took note and updated their DNS. Still too many MX hosts with DANE-TA(2) TLSA records list only X3:
# | CA
-----+----
929 | X3
230 | X4
372 | R3
254 | R4
286 | E1
237 | E2