Using desec with lego/traefik suddenly doesnt work anymore

Hello there,

I am using desec with lego/traefik in a kuberentes cluster.
It was working fine until recently, but now domains arent able to pass validation, I see the follwing output on 2022/01/30 15:39:08 client.go:551: [DEBUG] GET - (cant post here since forum regognizes log entries as links)

which looks like the API calls are working correctly, but also I never see the entries created in the desec dashboard.

anyone else seeing this issue at the moment?

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.

1 Like

Hi Freundschaft,

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!


1 Like

yes that sounds very much like the issue at hand here.
The API calls appear to go through so I also assume its a DNS propagation issue.

Thanks & Best Regards