Cloudron Forum

@girish said: I have added a 429 check and waiting for "retry-after" in e532401510dc64570f5c0d3d9972429da6268e0f . I guess that's the best we can do on our side . Hi @girish Thanks for this - I appreciate your attempt in trying to help with this. The related server experiencing the issue has been updated to v10.0.2 recently and it seems that this change was part of the update. However, the patch has made the situation worse actually. Since the update, I have been locked out of the related server because the "my." record did not successfully update (or only sporadically, before being scrapped from the DeSEC domain name record table entries shortly after) Attempts to manually add the record to DeSEC entry were also impossible because the DeSEC account was also locked out behind never-ending permanently-resetting with growing threshold waiting times. Not too sure how the Cloudron side is handling this though: It seems like the Cloudron DNS update requests are still batched. e.g. when one record needs updating, all records are updated, no matter if they actually need to. Still seem like Cloudron does not take into account whether or not a record was successfully update. e.g. do DNS record udpate -> if it works great; if it does not, carry on with the next record (thus leaving previous record in limbo) Update task starts at H=x and the next relevant entry is at approx H=x+8 (I suppose this could be due to the threshold retry waiting time) At the moment, the errors on the Cloudron server log oscillate between: reason: 'External Error' reason: 'Database Error' (-> sqlMessage: 'Too many connections',) HTML: 429 too many request HTML: 502 Bad gateway So currently, I feel this is a bit of a mess and I am sorry that this has come down to this. Any idea how this could/should be dealt with? I remain convinced that a more individual approach to DNS record update as well as switching DNS update method to batch HTTP API call would alleviate part of this/the whole issue i.e. only update records that needs updating, prioritze record update ("my." top prio) But I also acknowledge that this seems very specific to DeSEC and might not fit in Cloudron's development plan I hope that this makes sense. Otherwise we will be obliged to move on from DeSEC. @milian.hackradt May I ask what DN server are you using instead of deSEC?

@tecbox I sent a reply from support. I debugged this further . The 502 is returned from deSEC . I have added some logs on your server to see if we can get the full error to report to deSEC. So far, it's been running for the last one hour without reporting any error from deSEC .

Thank you for taking the time to investigate. It seems like there are several tools that have successfully implemented DNS-based Let's Encrypt challenges and DNS-based automation for deSEC. If the higher TTLs really are a problem, could it be possible to just restrict the usage of deSEC to wildcard DNS + Certificate usage (wildcard A/AAAA record + DNS challenge for Let's Encrypt)? These records only need to be updated very infrequently if at all. I personally run my cloudron instance behind a VPN, which is why I am unable to use the HTTP based verification. deSEC is a very special provider that I think is worth putting the effort into supporting. AFAIK It's the only donation-run/free, European provider with DNSSEC support currently included in Cloudron. Hetzner doesn't support DNSSEC. It's also (likely) one of the most privacy respecting providers available. I have also made a post on their forum. Maybe some creative ideas will come about.

You can read more about ports and firewall setup with cloudron at https://docs.cloudron.io/security/#cloud-firewall