<![CDATA[When renewing certificates, IPv6 queried despite being disabled]]>@girish piggybacking on that (also not a 100% sure if I or someone else asked that already): Why is it that letsencrypt is trying to get both, ipv4 and ipv6, in order to provision a certificate, even though ipv6 is disabled in Cloudron? Every time I change something with a location setting, it takes 2 minutes per (sub)domain to check, because ipv6 isn't set up and always fails.

]]>https://forum.cloudron.io/topic/14007/when-renewing-certificates-ipv6-queried-despite-being-disabledRSS for NodeMon, 20 Apr 2026 15:52:38 GMTMon, 30 Jun 2025 10:16:04 GMT60<![CDATA[Reply to When renewing certificates, IPv6 queried despite being disabled on Tue, 01 Jul 2025 07:40:25 GMT]]>@girish IPv6 is enabled on the server but not "in use", since some domains that are added manually don't have v6 and I don't want to run into troubles. Those are mostly Hetzner Cloud servers.

]]>https://forum.cloudron.io/post/109523https://forum.cloudron.io/post/109523Tue, 01 Jul 2025 07:40:25 GMT<![CDATA[Reply to When renewing certificates, IPv6 queried despite being disabled on Tue, 01 Jul 2025 07:19:19 GMT]]>@msbt Ah, I think I see now.

The IPv6 setting in Cloudron only controls whether AAAA record is set up for app domains. Nothing else. It doesn't disable IPv6 network in the server or anything like that. Of course, we can revisit what this setting should do.

What's happening is that Cloudron is checking if the A record propagated. But the NS has IPv6 servers and it's checking against the IPv6 servers if the A record is there. The reason why this check has to be done is that Let's Encrypt might still check against IPv6 servers for your A record.

Is IPv6 disabled only on the interface level on your server? Is it disabled at all? (Both situations are fine but trying to narrow down the problem)

]]>https://forum.cloudron.io/post/109521https://forum.cloudron.io/post/109521Tue, 01 Jul 2025 07:19:19 GMT<![CDATA[Reply to When renewing certificates, IPv6 queried despite being disabled on Mon, 30 Jun 2025 16:19:09 GMT]]>@girish exactly, it's disabled in the network view, but still tries to provision. Turns out it's not superbad, apparently it takes one minute per domain until it times out. I just had the case that I had a LAMP with a primary domain & redirect domain and a secondary domain (both apex and www) also as redirects, which nedeed to be split. So I had two minutes of downtime while removing the secondary domain and another 2 minutes of setup-time for the secondary domain on a new LAMP. However, if you have more than one redirect and change anything, that downtime grows quite quickly.

Jun 30 18:10:14 box:dns/waitfordns waitForDns: waiting for example.com to be 123.123.123.123 in zone example.com
Jun 30 18:10:14 box:dns/waitfordns waitForDns: nameservers are ["fred.ns.cloudflare.com","carol.ns.cloudflare.com"]
Jun 30 18:10:14 box:dns/waitfordns resolveIp: Checking A for example.com at 108.162.193.113
Jun 30 18:10:14 box:dns/waitfordns resolveIp: Checking A for example.com at 172.64.33.113
Jun 30 18:10:14 box:dns/waitfordns isChangeSynced: example.com (A) was resolved to 123.123.123.123 at NS fred.ns.cloudflare.com (108.162.193.113). Expecting 123.123.123.123. Match true
Jun 30 18:10:14 box:dns/waitfordns isChangeSynced: example.com (A) was resolved to 123.123.123.123 at NS fred.ns.cloudflare.com (172.64.33.113). Expecting 123.123.123.123. Match true
Jun 30 18:10:14 box:dns/waitfordns resolveIp: Checking A for example.com at 173.245.59.113
Jun 30 18:10:14 box:dns/waitfordns isChangeSynced: example.com (A) was resolved to 123.123.123.123 at NS fred.ns.cloudflare.com (173.245.59.113). Expecting 123.123.123.123. Match true
Jun 30 18:10:14 box:dns/waitfordns resolveIp: Checking A for example.com at 2a06:98c1:50::ac40:2171
Jun 30 18:10:19 box:dns/waitfordns resolveIp: No A. Checking CNAME for example.com at 2a06:98c1:50::ac40:2171
Jun 30 18:10:25 box:dns/waitfordns isChangeSynced: NS fred.ns.cloudflare.com (2a06:98c1:50::ac40:2171) not resolving example.com (A): Error: queryCname ETIMEOUT example.com. Ignoring
Jun 30 18:10:25 box:dns/waitfordns resolveIp: Checking A for example.com at 1234:5678:58::adf5:3b71
Jun 30 18:10:30 box:dns/waitfordns resolveIp: No A. Checking CNAME for example.com at 1234:5678:58::adf5:3b71
Jun 30 18:10:35 box:dns/waitfordns isChangeSynced: NS fred.ns.cloudflare.com (1234:5678:58::adf5:3b71) not resolving example.com (A): Error: queryCname ETIMEOUT example.com. Ignoring
Jun 30 18:10:35 box:dns/waitfordns resolveIp: Checking A for example.com at 2803:f800:50::6ca2:c171
Jun 30 18:10:40 box:dns/waitfordns resolveIp: No A. Checking CNAME for example.com at 2803:f800:50::6ca2:c171
Jun 30 18:10:45 box:dns/waitfordns isChangeSynced: NS fred.ns.cloudflare.com (2803:f800:50::6ca2:c171) not resolving example.com (A): Error: queryCname ETIMEOUT example.com. Ignoring
Jun 30 18:10:45 box:dns/waitfordns waitForDns: example.com at ns fred.ns.cloudflare.com: done
Jun 30 18:10:45 box:dns/waitfordns resolveIp: Checking A for example.com at 108.162.192.80
Jun 30 18:10:45 box:dns/waitfordns isChangeSynced: example.com (A) was resolved to 123.123.123.123 at NS carol.ns.cloudflare.com (108.162.192.80). Expecting 123.123.123.123. Match true
Jun 30 18:10:45 box:dns/waitfordns resolveIp: Checking A for example.com at 173.245.58.80
Jun 30 18:10:45 box:dns/waitfordns isChangeSynced: example.com (A) was resolved to 123.123.123.123 at NS carol.ns.cloudflare.com (173.245.58.80). Expecting 123.123.123.123. Match true
Jun 30 18:10:45 box:dns/waitfordns resolveIp: Checking A for example.com at 172.64.32.80
Jun 30 18:10:45 box:dns/waitfordns isChangeSynced: example.com (A) was resolved to 123.123.123.123 at NS carol.ns.cloudflare.com (172.64.32.80). Expecting 123.123.123.123. Match true
Jun 30 18:10:45 box:dns/waitfordns resolveIp: Checking A for example.com at 2803:f800:50::6ca2:c050
Jun 30 18:10:50 box:dns/waitfordns resolveIp: No A. Checking CNAME for example.com at 2803:f800:50::6ca2:c050
Jun 30 18:10:55 box:dns/waitfordns isChangeSynced: NS carol.ns.cloudflare.com (2803:f800:50::6ca2:c050) not resolving example.com (A): Error: queryCname ETIMEOUT example.com. Ignoring
Jun 30 18:10:55 box:dns/waitfordns resolveIp: Checking A for example.com at 1234:5678:50::adf5:3a50
Jun 30 18:11:00 box:dns/waitfordns resolveIp: No A. Checking CNAME for example.com at 1234:5678:50::adf5:3a50
Jun 30 18:11:05 box:dns/waitfordns isChangeSynced: NS carol.ns.cloudflare.com (1234:5678:50::adf5:3a50) not resolving example.com (A): Error: queryCname ETIMEOUT example.com. Ignoring
Jun 30 18:11:05 box:dns/waitfordns resolveIp: Checking A for example.com at 2a06:98c1:50::ac40:2050
Jun 30 18:11:10 box:dns/waitfordns resolveIp: No A. Checking CNAME for example.com at 2a06:98c1:50::ac40:2050
Jun 30 18:11:15 box:dns/waitfordns isChangeSynced: NS carol.ns.cloudflare.com (2a06:98c1:50::ac40:2050) not resolving example.com (A): Error: queryCname ETIMEOUT example.com. Ignoring
Jun 30 18:11:15 box:dns/waitfordns waitForDns: example.com at ns carol.ns.cloudflare.com: done
Jun 30 18:11:15 box:dns/waitfordns waitForDns: example.com has propagated
]]>https://forum.cloudron.io/post/109463https://forum.cloudron.io/post/109463Mon, 30 Jun 2025 16:19:09 GMT<![CDATA[Reply to When renewing certificates, IPv6 queried despite being disabled on Mon, 30 Jun 2025 14:48:46 GMT]]>@msbt I think this one might be unrelated to what I fixed. So in the renew logs, you are seeing Cloudron waiting for IPv6 propagation ? When you say ipv6 is disabled in Cloudron,, did you disable on the server or in the Network page?

]]>https://forum.cloudron.io/post/109459https://forum.cloudron.io/post/109459Mon, 30 Jun 2025 14:48:46 GMT