Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Support
  3. When renewing certificates, IPv6 queried despite being disabled

When renewing certificates, IPv6 queried despite being disabled

Scheduled Pinned Locked Moved Unsolved Support
certificatesipv6
5 Posts 2 Posters 96 Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic was forked from What's coming in Cloudron 9 girish
This topic has been deleted. Only users with topic management privileges can see it.
  • girishG girish

    Since many IPv6/PTR issues have been reported, I revisited the code to double-check.

    I found two biggish bugs:

    • There was a typo in the IPv4/IPv6 caching code 😕 Because of this IPv6 will sometimes be returned as undefined
    • On versions less than Ubuntu 24, unbound was configured to use IPv6 . Zen SpamHaus is not replying IPv6 queries for most of the public VPS providers . I made a fix to make unbound use IPv4 to query SpamHaus.

    Finally, I also added IPv6 DNSBL checks . Also, double checked that SPF record "a:" includes AAAA .

    I am hoping this helps the situation. If not, we can add a flag in 9.1 to make the mail server not use IPv6 at all.

    M Offline
    M Offline
    msbt
    App Dev
    wrote last edited by girish
    #1

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

    1 Reply Last reply
    2
    • girishG Offline
      girishG Offline
      girish
      Staff
      wrote last edited by
      #2

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

      1 Reply Last reply
      0
      • M Offline
        M Offline
        msbt
        App Dev
        wrote last edited by
        #3

        @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
        
        1 Reply Last reply
        0
        • girishG Offline
          girishG Offline
          girish
          Staff
          wrote last edited by
          #4

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

          1 Reply Last reply
          1
          • M Offline
            M Offline
            msbt
            App Dev
            wrote last edited by
            #5

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

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Bookmarks
            • Search