Cloudron Forum

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.

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

For those who hit this 8.2.4 is out . It's marked as unstable just to not have everyone update at the same time but it should be stable and has the fix for this issue.

@scooke said in Notes on domains?: Christmas has passed; that same day was my birthday! Happy Belated Birthday! You have the same birthday as my fly expert friend Erica McAlister - check out her books here https://www.ethicalbooksearch.com/uk?query=Erica+McAlister

Is ianoautomatico.online the real domain? If so, it has no nameservers per host -t NS ianoautomatico.online

@nebulon Fully agree, it's really odd that Wix doesn't allow AAAA records in this day and age. I'll change that domain to noop for now then as recommended, but my preference is to have the logic of the location DNS propagation check change so that domains in manual status can still be successful even if only one IPv4 or one IPv6 address is set rather than both. The noop is for development after all, isn't it? As long as one of the DNS records exists, that should be seen as successful IMO, since it will work in terms of getting traffic to the site still. There shouldn't be a reason to fail that.

Since porkbun returns an 400 error, I might guess something is wrong with the API call we do. Sadly https://porkbun.com/api/json/v3/documentation is not very detailed here, nor is the error message itself. Possibly the API requires something else for the naked domain, since the subdomains work apparently fine then. But also I can't find anything mentioned in the docs Can you check if this might be a record conflict error which just reports as 400? Like do A records for that already exist?

Looks like there is some DNS issue on your system. Can you run the following via SSH: host -t A api.cloudflare.com Also maybe cloudron-support --troubleshoot

@salmonetc said in Changing DNS provider and email with minimal downtime.: I started trying to "add" the domain. However, I get the following error: Zone not found: 200 {"result":[],"result_info":{"page":1,"per_page":20,"total_pages":0,"count":0,"total_count":0},"success":true,"errors":[],"messages":[]} Have you added domain.com into cloudflare ? When you create a token also make sure that you add the domain in the Zone Resources list. See https://docs.cloudron.io/domains/#cloudflare-dns

The issue here was server DNS related . The upgrade to Cloudron 8 left the system in a broken state where DNS was not working. Fixing up /etc/systemd/resolved.conf to have DNS servers resolved the problem.

And I would appreciate if this fix get published soon. I need to update it, because I accidently did not renew but delete the API key and there is no way back. (Really not "no bullshit" like years ago @gandi) @girish

I think @nebulon means host -t NS vysvr.org . This should resolve to your nameservers.

@nebulon something is slipping out here... If it works from host abra-ka-da-bra.mydomain.com command, but does not from Cloudron - isn't it something specific to Cloudron implementation?

Thanks for sharing . Right... our current domain/location configuration follows an all or nothing approach. If one or more fail, it will refuse to bring the app up and will get "stuck" forever . We have a task somewhere to make this more smart and also make the app repair feature smarter but it always gets pushed out as low priority.

This is handled in support by now. The AAAA records for that domain are not set up.

@potemkin_ai & @kk_cloudron On my side I was also having the issue "queryNs ETIMEOUT" , and it was because my outbound UDP port 53 was not open. I just had to add it like that on my Hetzner Cloud Firewall : [image: 1744283926608-7bf48621-4935-4413-af8d-775b9a05abe2-image-resized.png]