Cloudron Forum

That is interesting...

@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?

Thanks! Fixed now

Hello @mendoksai That checks out with our other topic. A RAID failure can cause such a catastrophic issue.

@m3pilot it's not a problem. Cloudron periodically checks (everyday) if the namecheap credentials are working. If not working, it will give you a notification that DNS credentials are not working. As part of the check, a DNS entry is created and deleted immediately .

Not sure if cloning is exactly UI-friendly here. The user intention is to add another domain, which is a separate action than cloning. You'd assume you perform an action that is separate from other domains, I'd say. For backup sites, I am more with you: There it makes more sense to use the same site, but change a detail.

Mystery solved! https://forum.cloudron.io/post/35426

Nevermind, it was just a matter of being patient. Everything was set up correctly. For anyone else using Namecheap, it takes a minute for the DNS to sync. Give it some time (quite a bit more than you think) and it'll work.

Yeah, I don't have the original, because I repaired this manually already, but that is basically it - the CNAME was a standard of Porkbun pointing to their server. Well, it's solved quickly, albeit manually.

It worked! Thank you so much!

You should do this - https://docs.cloudron.io/troubleshooting/#domain-issues-expiry

@james I could not get it working at all, so I switched to use Sendgrid instead since we have an account and that is working fine. The issue is that I am using Cloudron as a VM inside of Truenas Community 25.04.1 and it is Truenas causing the issue and I would have to make some major changes and I don't want to affect the File Server side by doing this.

I found that I was using that domain name as an alias for another app.

Hello @Shai The second level domain, also known as @ in most DNS providers e.g cloudron.io has a different propagation time then third level domains aka. example.cloudron.io. This could take up to 24 hours or more, depending on the hosters default TTL for the domain or what you've set. Might even be resolved now when you retry it after 7 hours.

Fantastic! Thanks so much, @james

@girish Much appreciated

Do you have the "Enable proxying" flag enabled in the Domains -> Cloudflare configuration ? This whole discussion only applies if you have that flag changed. Cloudron does not touch the proxying flag if that is disabled. When enabled, it will set the proxying flag when adding new cloudflare DNS records. This is set only when adding and in all other situations that flag is left untouched . It does this for both ipv4 and ipv6 records.

So it turns out DNSSEC is the problem. Unbeknownst to me, the previous registrar had enabled DNSSEC by default, when I transferred the domain some time ago, the records were not removed when the new registrar updated the nameservers. As they don't have DNSSEC management and my DNS resolver doesn't validate DNSSEC, I didn't notice anything was amiss. Thank you for your help with this!