Disclaimer: I use lego, but not treafik. I believe, only lego is relevant here.
Are you sure, that the TXT record is not created? Lego cleans it up after the (failed) verification step, so you’d have to poll quickly to see the record at all.
If the record is created (or you’re not quite sure if it is), this sound like an issue I had a while ago.
The gist of it: After setting up the response TXT record, lego polls the authoritative nameserver(s) until they have it. Lego then tells the CA to do the DNS verification. The CA queries the authoritative nameserver(s) for the same information.
In that last step, the CA may talk to other servers than lego did, due to deSEC’s global anycast network.
So, if you’re unlucky, the newly created record propagates faster to the servers near your lego instance than to those near the CA’s verifier.
Apparently, propagation may take up to one minute.
My solution was to make lego increase the interval between creating the TXT record and the first time polling for it to be more than one minute. You can probably do this with DESEC_POLLING_INTERVAL (see docs), unless traefik does something wild here. You may have to increase DESEC_PROPAGATION_TIMEOUT as well.
Hope that helps. Your issue may be something totally different.
I second black’s opinion. Due to different locations in the Internet, you and Let’s Encrypt may be talking to different name servers. deSEC’s propagation to the frontend name servers is currently slightly delayed due to a bug in the powerDNS lmdb backend. We are working with the powerDNS maintainers towards a solution.
Increasing the waiting time should resolve your problem in the meantime. Sorry for the inconvenience!