# Tlsa update problem / dane validation

**URL:** <https://community.letsencrypt.org/t/tlsa-update-problem-dane-validation/139942>\
**Category:** Help\
**Created:** [December 7, 2020, 8:11am UTC](https://community.letsencrypt.org/t/tlsa-update-problem-dane-validation/139942 "2020-12-07T08:11:20Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![olze](https://avatars.discourse-cdn.com/v4/letter/o/ecb155/32.png) [@olze](https://community.letsencrypt.org/u/olze)\
**Post date:** [December 7, 2020, 8:11am UTC](https://community.letsencrypt.org/t/tlsa-update-problem-dane-validation/139942/1 "2020-12-07T08:11:20Z")

</div>

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. [https://crt.sh/?q=example.com](https://crt.sh/?q=example.com)), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: [trustserv.de](http://trustserv.de)

I ran this command: n/a

It produced this output: n/a

My web server is (include version): apache

The operating system my web server runs on is (include version): linux

My hosting provider, if applicable, is: netcup

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): yes, for domain name stuff from the hoster

The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you're using Certbot): n/a

i have a question regarding the tlsa updates which are required because of e3/r3 etc.

is it enough to add those 4 tlsa records ? because [https://stats.dnssec-tools.org/explore/?trustserv.de](https://stats.dnssec-tools.org/explore/?trustserv.de) says its broken.  
i added those records about an hour ago

---

<div class="post-metadata">

**Author:** ![JamesLE](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jamesle/32/49364_2.png) [@JamesLE](https://community.letsencrypt.org/u/JamesLE)\
**Post date:** [December 7, 2020, 8:32am UTC](https://community.letsencrypt.org/t/tlsa-update-problem-dane-validation/139942/3 "2020-12-07T08:32:10Z")

</div>

> [@olze](#):
>
> is it enough to add those 4 tlsa records ? because [https://stats.dnssec-tools.org/explore/?trustserv.de](https://stats.dnssec-tools.org/explore/?trustserv.de) says its broken.  
> i added those records about an hour ago

It looks like you have a matching DANE-TA (`2 1 1`) record that will be making things work OK; [dnssec-tools.org](http://dnssec-tools.org) just updates their data slowly, so they don't see it yet. Another checker, [Check a DANE SMTP Service](https://www.huque.com/bin/danecheck-smtp), shows that your domain's TLSA is working. I also did a `dig` query and it looks to me like it should work.

I think the ideal setup would be to have just a single DANE-EE (`3 1 1`) record that's for your current certificate. (Your current EE record doesn't seem to match your cert, but having a working TA record makes up for it.) When your ACME client renews a certificate, it should publish a new TLSA record to your DNS infrastructure, and then wait the same length as your TLSA record's TTL (currently 3600 seconds) before telling your mail server to use the new certificate.

That said, I know getting that all set up and automated is a bit of a pain! I haven't done it on all of my personal infrastructure yet.

One shortcut could be to publish TA (`2 1 1`) records for our `R3`, `R4`, `ISRG Root X1`, and `ISRG Root X2` certificates. Those are _not_ guaranteed to be safe for pinning long-term, so please keep an eye on our announcements - but they should be good for a long while.

---

<div class="post-metadata">

**Author:** ![olze](https://avatars.discourse-cdn.com/v4/letter/o/ecb155/32.png) [@olze](https://community.letsencrypt.org/u/olze)\
**Post date:** [December 7, 2020, 8:35am UTC](https://community.letsencrypt.org/t/tlsa-update-problem-dane-validation/139942/4 "2020-12-07T08:35:48Z")

</div>

my provider does not provide an automated way to update the dns records. unfortunately.

---

<div class="post-metadata">

**Author:** ![JamesLE](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jamesle/32/49364_2.png) [@JamesLE](https://community.letsencrypt.org/u/JamesLE)\
**Post date:** [December 7, 2020, 8:40am UTC](https://community.letsencrypt.org/t/tlsa-update-problem-dane-validation/139942/5 "2020-12-07T08:40:01Z")

</div>

Hmm, one way to work around that is to delegate authority - for just your TLSA record - to a different DNS service that does allow automated updates. So: `_25._tcp.trustserv.de` could be an `NS` record or two pointing to that other service, which would then serve your TLSA records.

Not that simple, but perhaps it'd work for you if you're aiming for stable long-term automation.

---

<div class="post-metadata">

**Author:** ![olze](https://avatars.discourse-cdn.com/v4/letter/o/ecb155/32.png) [@olze](https://community.letsencrypt.org/u/olze)\
**Post date:** [December 7, 2020, 8:47am UTC](https://community.letsencrypt.org/t/tlsa-update-problem-dane-validation/139942/6 "2020-12-07T08:47:59Z")

</div>

sounds interesting but guess this will be too complicated for me 😉  
i'll just wait until netcup provides a way for automated dns updates.

edit: just noticed i asked the hoster nearly 3 years ago and he said it is in planning. just checked the forum entry. seems like its already released 🙂  
i'll test that this weekend

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [January 6, 2021, 8:59am UTC](https://community.letsencrypt.org/t/tlsa-update-problem-dane-validation/139942/7 "2021-01-06T08:59:17Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
