Hello,
It seems i have trouble adding TXT records to my dedyn.io domain.
To be more specific, if i add “test” as subname, and any value between ““ as record, it works ie. i’m able to query it using host -t txt.
But if i add as a subname anything with special chars such as “_” and “-” it does not work: host -t txt returns NXDOMAIN. This is an issue, because it prevents _acme-challenge subname…
Same behaviour either through the UI or through the API directly.
What am i doing wrong?
Thx!
L
I have just tested this using a similar example and I can’t reproduce.
I have added a TXT record _aaa-bbb with the value "test" to a domain (example.com replaces the actual domain I used here) using the web interface. That worked fine. The record shows up in the web interface.
Then I used host(1) to to retrieve the record:
$ host -t txt _aaa-bbb.example.com
_aaa-bbb.example.com descriptive text "test"
$
I also checked using dig(1):
$ dig +short _aaa-bbb.example.com txt
"test"
$
So no problems here.
How did you attempt to create the record? Do you actually see the record in the web interface?
Did you take into account DNS TTLs when testing, e.g. by asking the authoritative servers directly, or by waiting long enough for the propagation? There is also an additional delay for time deSEC needs to update the frontend servers. Sometimes this can take 2-3 minutes.
HTH
fiwswe
I attempted to create it in the web interface and also through the API, and yes i was able to see it through the web interface afterwards.
Again, i’m using a DynDNS (dedyn.io) domain, and i was trying either locally or by hitting directly ns1.desec.io.
However i tried again right now, and it seems that now it’s working. Maybe bad luck or some transient issue earlier today?
Doesn’t make any difference. A subdomain of dedyn.io is treated the same as any other domain for this purpose. If it makes you feel better, substitute example.dedyn.io for example.com in my previous post.
Ok, so TTLs were not the issue.
Great!
Nothing is noted on https://desec-status.net. But like I wrote, sometimes there is a nontrivial delay updating the frontend servers. Maybe that was it. I believe the folks at deSEC are already aware of this issue and are working on reducing the delays.
fiwswe
Just to corroborate what @fiwswe wrote: It looks like you just need to give it some time. Modifications can take upward of 2 minutes to show up at the nameservers. This isn’t ideal and a target for improvement, but you should currently wait at least 3 minutes (better 4) before you tell Letsencrypt to check for those records.
Thanks for all your replies. Actually i did indeed wait for a few minutes - though maybe not 4!
And actually, 3-4 minutes of wait is way too long for ACME enrollment. Thing is that there’s not only Let’s Encrypt, almost all CAs out there are switching to ACME because of shortening lifetime of certificates and DVs. DNS-01 validation is by far the most efficient in corporate/DevOps environments and even in lots of “SOHO” setups. Having 3-4 minutes propagation time for simple TXT record will end up breaking ACME enrollment in a lot of circumstances: if you pile up that time with a slow CA you can end up with an enrollment time taking up to 6-7 
minutes, and lots of ACME clients will give up.
And some CAs are slow on ACME for actually good (and some less good) reasons (e.g. ensuring proper OV validation thanks to EAB, CAA check, CSR additional checks, DNS additional checks, etc.). Let’s Encrypt doesn’t offer all of these services - which is normal because it targets pure and simple DV certs.
As someone who uses Desec for ACME with Letsencrypt, I can attest that a 4 minute wait time to make sure the records are there when Letsencrypt requests them is not an issue with multiple clients that I’ve used. Desec is aware that there is room for improvement though, so your background tasks may someday get your certificates in minutes instead of two more minutes.
Any modification may take this long to propagate. This is not specific to TXT RRsets.
And yes, this could be improved (and hopefully will at some point).
However specifically for creating/renewing certificates this should not be much of an issue. RFC 8555 does not mention any inherent timeouts in the the protocol. And AFAICT Let’s Encrypt DNS-01 challenges remain valid for days. You just need to adjust the ACME client configuration to allow for this time. Human impatience needs to be curtailed when dealing with automated processes . Just trust that it will work eventually.
It is more of a problem for DDNS updates (though still not too big of an issue).
My point was just that it’s an issue for TXT records because of some ACME implementations both on CA side (besides Let’s Encrypt there are dozens of Public CAs supporting ACME) and on the client side (there are literally hundreds if not thousands of ACME client implementations): the combination of the two will sometimes lead to timeouts if DNS propagation is too slow, whatever RFC 8555 says (or not) about it.
Again: i’m NOT talking about Let’s Encrypt and common ACME clients such as certbot or acme.sh.
Let’s hope deSEC team improves it 
Is your concern purely theoretical or do you have a particular service-client-combination in mind which can’t be made to work with Desec? There are plenty configurations where changing or adding a record within minutes is a big ask. For example, with any of the free secondary DNS services that don’t allow update notifications, you’d have to wait a lot longer before the record can be assumed to have propagated everywhere. I think RFC 8555 doesn’t specify maximum delays for good reason, and any system assuming fast updates is going to be problematic in many situations.
I do have particular service-client combinations in mind, i just don’t want to disclose it on public forum.
Regarding the CA side, think about commercial public CA, and on the client side think about LBs and CLMs.