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. infomaniak IPv6 issues

infomaniak IPv6 issues

Scheduled Pinned Locked Moved Solved Support
infomaniakipv6
70 Posts 9 Posters 2.3k Views 6 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic was forked from Email sending broken after updating to 8.2.x (due to IPv6 issues) girish
This topic has been deleted. Only users with topic management privileges can see it.
  • J joseph

    Cloudron uses unbound to do DNS lookups .Can you try host -t PTR <ip6> 127.0.0.150 ? 127.0.0.150 is the address where unbound listens

    GengarG Offline
    GengarG Offline
    Gengar
    wrote on last edited by
    #3

    @joseph When I have the issue ? Or when I don't ? As I already rebooted my server a few hours ago, atm I don't have the issue. But I guess it will come tomorrow or the day after.

    J 1 Reply Last reply
    1
    • GengarG Gengar

      @joseph When I have the issue ? Or when I don't ? As I already rebooted my server a few hours ago, atm I don't have the issue. But I guess it will come tomorrow or the day after.

      J Offline
      J Offline
      joseph
      Staff
      wrote on last edited by
      #4

      @Gengar when you have the issue. hopefully, the output gives us a good error code to analyze.

      1 Reply Last reply
      1
      • GengarG Offline
        GengarG Offline
        Gengar
        wrote on last edited by Gengar
        #5

        @joseph I'm having the issue right now. And I think I've found a pattern.

        It seems to be nearly each time an app updates. And then it breaks my PTR6 record in Cloudron only.
        Works fine with MxToolbox (but it switched back to the second nameserver as the last time when it wasn't working on cloudron side for the PTR6 record and the first NS reported the PTR4 record => I still don't think there may be a link but just writing it here in case it could be a lead ) .

        Below you will find the output of the following command :

        host -t PTR <ip6> 127.0.0.150
        

        2025-03-21 21_20_19-VPS.png

        Edit : As a workaround I've rebooted my server and now it works again in Cloudron and MxToolBox. But we know it's just a temporary fix... (In mx toolbox the PTR6 is reported by the first NS now. And the PTR4 by the second NS).

        1 Reply Last reply
        1
        • nebulonN Offline
          nebulonN Offline
          nebulon
          Staff
          wrote on last edited by
          #6

          The PTR record is actually set by your server provider, not through Cloudron. Somehow I can't see how this would be connected to an app update, since Cloudron cannot programmatically set the PTR in any way.

          jdaviescoatesJ GengarG 2 Replies Last reply
          0
          • nebulonN nebulon

            The PTR record is actually set by your server provider, not through Cloudron. Somehow I can't see how this would be connected to an app update, since Cloudron cannot programmatically set the PTR in any way.

            jdaviescoatesJ Offline
            jdaviescoatesJ Offline
            jdaviescoates
            wrote on last edited by
            #7

            @nebulon it seems the issue is simply that Cloudron keeps telling them the PTR record isn't correct, when seemingly actually it is.

            I use Cloudron with Gandi & Hetzner

            1 Reply Last reply
            1
            • nebulonN nebulon

              The PTR record is actually set by your server provider, not through Cloudron. Somehow I can't see how this would be connected to an app update, since Cloudron cannot programmatically set the PTR in any way.

              GengarG Offline
              GengarG Offline
              Gengar
              wrote on last edited by Gengar
              #8

              @nebulon Yeah, I’m aware the PTR6 record is set by my VPS provider, and I’ve double-checked that it’s configured correctly on their end. MXToolBox confirms everything looks good.

              The issue seems to be on Cloudron’s side: it occasionally shows the PTR6 record as “null”. But this only happens after some time — for example, right after a full reboot, everything works fine. Then, 24 to 48 hours later, Cloudron throws an error saying the email setup isn’t correct, and it shows the PTR6 value as “null”.

              What’s strange is that MXToolBox still shows the correct PTR6 value, exactly as set on my VPS provider’s side. So the record itself is definitely working.

              I’ve noticed this often happens after an app update. I’m not 100% sure it’s the cause, but every time the issue appears, it’s usually right after an update.

              Not sure if this is a Cloudron issue or something with Ubuntu, but for some reason, only my server fails to resolve the PTR6 correctly after a while.

              Edit @ 9:00 PM CET: MiroTalk P2P has been updated automatically at 9PM CET. And atm (9:05PM CET) my PTR6 record is still resolved correctly by Cloudron. I will monitor.
              2025-03-22 21_05_41.png

              @joseph => fyi

              Edit @ 9:40 PM CET : Cloudron doesn't resolve my PTR6 record anymore...
              2025-03-22 21_48_12.png
              2025-03-22 21_43_46.png

              But on MXToolBox Side it's still working fine :
              2025-03-22 21_54_36-PTR6.png

              It's only cloudron that returns a "null" value for PTR6.

              And I guess the value is null because when I do :

              host -t PTR <ip6> 127.0.0.150
              

              I have a time out ...
              2025-03-21 21_20_19-VPS.png

              BTW, I use Uptime Kuma to notify me on Telegram each time there is a notification in Cloudron. And usually notifications are about automatic app updates and my Cloudron will fail to resolve my PTR6 record after this. In this example it was about 40 minutes after the update / the notification. Could also be linked to notifications, idk. But there is something with updates or notifications and PTR6 record resolving on Cloudron/Ubuntu side.

              robiR GengarG 2 Replies Last reply
              2
              • GengarG Gengar

                @nebulon Yeah, I’m aware the PTR6 record is set by my VPS provider, and I’ve double-checked that it’s configured correctly on their end. MXToolBox confirms everything looks good.

                The issue seems to be on Cloudron’s side: it occasionally shows the PTR6 record as “null”. But this only happens after some time — for example, right after a full reboot, everything works fine. Then, 24 to 48 hours later, Cloudron throws an error saying the email setup isn’t correct, and it shows the PTR6 value as “null”.

                What’s strange is that MXToolBox still shows the correct PTR6 value, exactly as set on my VPS provider’s side. So the record itself is definitely working.

                I’ve noticed this often happens after an app update. I’m not 100% sure it’s the cause, but every time the issue appears, it’s usually right after an update.

                Not sure if this is a Cloudron issue or something with Ubuntu, but for some reason, only my server fails to resolve the PTR6 correctly after a while.

                Edit @ 9:00 PM CET: MiroTalk P2P has been updated automatically at 9PM CET. And atm (9:05PM CET) my PTR6 record is still resolved correctly by Cloudron. I will monitor.
                2025-03-22 21_05_41.png

                @joseph => fyi

                Edit @ 9:40 PM CET : Cloudron doesn't resolve my PTR6 record anymore...
                2025-03-22 21_48_12.png
                2025-03-22 21_43_46.png

                But on MXToolBox Side it's still working fine :
                2025-03-22 21_54_36-PTR6.png

                It's only cloudron that returns a "null" value for PTR6.

                And I guess the value is null because when I do :

                host -t PTR <ip6> 127.0.0.150
                

                I have a time out ...
                2025-03-21 21_20_19-VPS.png

                BTW, I use Uptime Kuma to notify me on Telegram each time there is a notification in Cloudron. And usually notifications are about automatic app updates and my Cloudron will fail to resolve my PTR6 record after this. In this example it was about 40 minutes after the update / the notification. Could also be linked to notifications, idk. But there is something with updates or notifications and PTR6 record resolving on Cloudron/Ubuntu side.

                robiR Offline
                robiR Offline
                robi
                wrote on last edited by
                #9

                @Gengar How did you end up connecting Cloudron notifications to Uptime Kuma?

                Conscious tech

                GengarG 1 Reply Last reply
                1
                • robiR robi

                  @Gengar How did you end up connecting Cloudron notifications to Uptime Kuma?

                  GengarG Offline
                  GengarG Offline
                  Gengar
                  wrote on last edited by
                  #10

                  @robi said in Email sending broken after updating to 8.2.x (due to IPv6 issues):

                  How did you end up connecting Cloudron notifications to Uptime Kuma?

                  I’m using Uptime Kuma to monitor the Cloudron notifications using Cloudron API.

                  The API endpoint I monitor is:

                  https://my.domain.tld/api/v1/notifications?acknowledged=false&page=1&per_page=2
                  

                  This returns a list of unacknowledged notifications. In Uptime Kuma, I use the “Keyword exists” monitor type and set the keyword to:

                  "notifications":[]
                  

                  When this keyword is not found, it means there are new notifications waiting to be read. Uptime Kuma then considers the service as “down” and sends me an alert to a Telegram channel. Once I acknowledge the notification in the Cloudron UI, the keyword is present again, and Kuma marks the monitor as “up”.

                  To authenticate the API call, you need to add a custom header in Uptime Kuma:

                  {
                    "authorization": "Bearer YOUR_CLOUDRON_API_TOKEN"
                  }
                  

                  You can generate the API token from your Cloudron account (Account > API Tokens).

                  I saw this solution somewhere on the forum a while ago, but I don’t remember exactly where or who shared it.

                  robiR 1 Reply Last reply
                  6
                  • GengarG Gengar

                    @robi said in Email sending broken after updating to 8.2.x (due to IPv6 issues):

                    How did you end up connecting Cloudron notifications to Uptime Kuma?

                    I’m using Uptime Kuma to monitor the Cloudron notifications using Cloudron API.

                    The API endpoint I monitor is:

                    https://my.domain.tld/api/v1/notifications?acknowledged=false&page=1&per_page=2
                    

                    This returns a list of unacknowledged notifications. In Uptime Kuma, I use the “Keyword exists” monitor type and set the keyword to:

                    "notifications":[]
                    

                    When this keyword is not found, it means there are new notifications waiting to be read. Uptime Kuma then considers the service as “down” and sends me an alert to a Telegram channel. Once I acknowledge the notification in the Cloudron UI, the keyword is present again, and Kuma marks the monitor as “up”.

                    To authenticate the API call, you need to add a custom header in Uptime Kuma:

                    {
                      "authorization": "Bearer YOUR_CLOUDRON_API_TOKEN"
                    }
                    

                    You can generate the API token from your Cloudron account (Account > API Tokens).

                    I saw this solution somewhere on the forum a while ago, but I don’t remember exactly where or who shared it.

                    robiR Offline
                    robiR Offline
                    robi
                    wrote on last edited by
                    #11

                    @Gengar Oh amazing, thanks for sharing the detail.

                    That's an interesting choice to keep on top of all the notifications.

                    Conscious tech

                    1 Reply Last reply
                    3
                    • GengarG Gengar

                      @nebulon Yeah, I’m aware the PTR6 record is set by my VPS provider, and I’ve double-checked that it’s configured correctly on their end. MXToolBox confirms everything looks good.

                      The issue seems to be on Cloudron’s side: it occasionally shows the PTR6 record as “null”. But this only happens after some time — for example, right after a full reboot, everything works fine. Then, 24 to 48 hours later, Cloudron throws an error saying the email setup isn’t correct, and it shows the PTR6 value as “null”.

                      What’s strange is that MXToolBox still shows the correct PTR6 value, exactly as set on my VPS provider’s side. So the record itself is definitely working.

                      I’ve noticed this often happens after an app update. I’m not 100% sure it’s the cause, but every time the issue appears, it’s usually right after an update.

                      Not sure if this is a Cloudron issue or something with Ubuntu, but for some reason, only my server fails to resolve the PTR6 correctly after a while.

                      Edit @ 9:00 PM CET: MiroTalk P2P has been updated automatically at 9PM CET. And atm (9:05PM CET) my PTR6 record is still resolved correctly by Cloudron. I will monitor.
                      2025-03-22 21_05_41.png

                      @joseph => fyi

                      Edit @ 9:40 PM CET : Cloudron doesn't resolve my PTR6 record anymore...
                      2025-03-22 21_48_12.png
                      2025-03-22 21_43_46.png

                      But on MXToolBox Side it's still working fine :
                      2025-03-22 21_54_36-PTR6.png

                      It's only cloudron that returns a "null" value for PTR6.

                      And I guess the value is null because when I do :

                      host -t PTR <ip6> 127.0.0.150
                      

                      I have a time out ...
                      2025-03-21 21_20_19-VPS.png

                      BTW, I use Uptime Kuma to notify me on Telegram each time there is a notification in Cloudron. And usually notifications are about automatic app updates and my Cloudron will fail to resolve my PTR6 record after this. In this example it was about 40 minutes after the update / the notification. Could also be linked to notifications, idk. But there is something with updates or notifications and PTR6 record resolving on Cloudron/Ubuntu side.

                      GengarG Offline
                      GengarG Offline
                      Gengar
                      wrote on last edited by Gengar
                      #12

                      Hey again @nebulon & @joseph ,

                      Just wanted to report that I had the same issue again today.

                      There was another automatic app update on my Cloudron instance at 9 PM CET. I checked shortly after, and PTR6 resolution was still working fine on Cloudron’s side around 10 PM. So initially everything looked okay.

                      But now, at 11 PM CET, Cloudron is once again returning a null value for the PTR6 record. Just like before, this is only on Cloudron’s side — when I check with MXToolBox, the PTR6 record still resolves correctly and matches what’s configured on my VPS provider's end.
                      49d79caa-d8a0-493e-b47e-1a9dd5c35296-image.png
                      5ea7c50a-035d-4d42-b152-5d4c0c1c95ed-image.png

                      This confirms it’s not a DNS issue upstream, but something on the Cloudron/Ubuntu side that breaks PTR6 resolution after a while, possibly related to app updates or maybe even internal DNS caching?

                      Really seems like the exact same pattern as before:

                      • PTR6 works right after reboot of the server
                      • After some time (or update?), Cloudron stops resolving it and shows null
                      • External tools like MXToolBox still show it correctly
                      • host -t PTR <ip6> times out locally when PTR6 doesn't resolves correctly.

                      As mentionned in my previous post, I'm using Uptime Kuma to forward Cloudron notifications to Telegram, and again, the Cloudron PTR6 resolution broke some time after the notification of the app update. Not saying they’re directly connected, but the timing is always suspiciously close.

                      1 Reply Last reply
                      1
                      • GengarG Offline
                        GengarG Offline
                        Gengar
                        wrote on last edited by Gengar
                        #13

                        Just wanted to provide an update after some deeper investigation on my side.

                        I tried running the following command while everything was still marked as green in Cloudron:

                        host -t PTR <ipv6> 127.0.0.150
                        

                        Even though Cloudron still showed a valid PTR6 at that moment, the command returned a timeout. That might indicate that the issue does not start with Cloudron itself, but with Unbound no longer resolving correctly via 127.0.0.150.

                        To address this, I modified Unbound’s configuration to use Cloudflare as the upstream DNS resolvers, instead of relying on the resolvers provided via DHCP by my VPS provider. Here's what I did:

                        1. Create a new file "forward.conf" at this path :
                        /etc/unbound/unbound.conf.d/forward.conf
                        
                        1. Edited this file "forward.conf" using nano to add the following :
                        forward-zone:
                          name: "."
                          forward-addr: 1.1.1.1
                          forward-addr: 1.0.0.1
                          forward-addr: 2606:4700:4700::1111
                          forward-addr: 2606:4700:4700::1001
                        
                        
                        1. Validated the configuration with the following command :
                        sudo unbound-checkconf
                        
                        1. Restarted Unbound:
                        sudo systemctl restart unbound
                        

                        After this change, PTR6 resolution via

                        host -t PTR <ipv6> 127.0.0.150
                        

                        works instantly and consistently. (I just had to wait like 5 minutes and now it's resolving instantly and consistently)

                        I will continue monitoring over the next few days to confirm whether the issue comes back or not.
                        If it doesn't comes back, it means there was an issue with Unbound and my VPS Provider Resolvers (DNS) received through DHCP...

                        EDIT : Unfortunatly this workaround comes with an issue... Spamhaus is now considering my IP as blacklisted as I am using an open resolver for the unbound... => https://www.spamhaus.com/resource-center/successfully-accessing-spamhauss-free-block-lists-using-a-public-dns/

                        I thought I had a good idea by using another resolver for Unbound... But I didn't knew the implication it would have with the IP Black lists of those "DNSBL" ...

                        1 Reply Last reply
                        1
                        • GengarG Offline
                          GengarG Offline
                          Gengar
                          wrote on last edited by Gengar
                          #14

                          I was wrong... each time I SSH to my server, and run for the first time :

                          host -t PTR <ipv6> 127.0.0.150
                          

                          It will time out.
                          And the second time it will work perfectly and instantly...

                          I've rolled back Unbound to the default cloudron configuration in order to not be blacklisted by https://www.spamhaus.org/ .

                          And

                          host -t PTR <ipv6> 127.0.0.150
                          

                          Works correctly ... I just have to send it twice, first time time out. Second time instantly resolved.

                          It means I am still having the exact same issue that I cannot explain... with my PTR6 value showing "null" in Cloudron only after an app update or after approximately 24-48 hours...

                          Any ideas @nebulon & @joseph ?

                          I really don't know where to look/search ...

                          1 Reply Last reply
                          0
                          • scookeS Offline
                            scookeS Offline
                            scooke
                            wrote on last edited by
                            #15

                            Who is the VPS server?

                            A life lived in fear is a life half-lived

                            GengarG 1 Reply Last reply
                            0
                            • scookeS scooke

                              Who is the VPS server?

                              GengarG Offline
                              GengarG Offline
                              Gengar
                              wrote on last edited by Gengar
                              #16

                              @scooke The VPS Provider is

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

                                @Gengar Which ubuntu version are you on ? Unbound behavior slighly varies based on Ubuntu 22.04 and 24.04

                                Can you please try this:

                                • Edit /home/yellowtent/box/src/mail.js . You will find a line at around line 86 like const DNS_OPTIONS = { timeout: 10000 }; .

                                • Change it to const DNS_OPTIONS = { timeout: 30000, tries: 4 }; .

                                • systemctl restart box

                                GengarG 1 Reply Last reply
                                3
                                • girishG girish

                                  @Gengar Which ubuntu version are you on ? Unbound behavior slighly varies based on Ubuntu 22.04 and 24.04

                                  Can you please try this:

                                  • Edit /home/yellowtent/box/src/mail.js . You will find a line at around line 86 like const DNS_OPTIONS = { timeout: 10000 }; .

                                  • Change it to const DNS_OPTIONS = { timeout: 30000, tries: 4 }; .

                                  • systemctl restart box

                                  GengarG Offline
                                  GengarG Offline
                                  Gengar
                                  wrote on last edited by
                                  #18

                                  @girish Thank you for your help .

                                  I am using Ubuntu 24.04.

                                  I've edited what you told me to edit.

                                  If I understand correctly , it could happen simply because there was no retry and a time out after 10 seconds.
                                  And now that we changed it to 4 retries and 30 seconds, so if it was a time out issue, it should solve it now by giving it more opportunities to do it if it's a bit slow.

                                  Is this setting override by each cloudron update ?

                                  I will monitor and let you know if it solved my issue or not.

                                  girishG 1 Reply Last reply
                                  1
                                  • GengarG Gengar

                                    @girish Thank you for your help .

                                    I am using Ubuntu 24.04.

                                    I've edited what you told me to edit.

                                    If I understand correctly , it could happen simply because there was no retry and a time out after 10 seconds.
                                    And now that we changed it to 4 retries and 30 seconds, so if it was a time out issue, it should solve it now by giving it more opportunities to do it if it's a bit slow.

                                    Is this setting override by each cloudron update ?

                                    I will monitor and let you know if it solved my issue or not.

                                    girishG Offline
                                    girishG Offline
                                    girish
                                    Staff
                                    wrote on last edited by
                                    #19

                                    @Gengar yeah, just guessing here that maybe it is taking more than 10s for the initial resolution. There is a default retry of 2 times . Don't know if changing it to more helps . I have been looking into the unbound docs on increasing the timeout in general but haven't found a good config variable yet.

                                    GengarG 1 Reply Last reply
                                    1
                                    • girishG girish

                                      @Gengar yeah, just guessing here that maybe it is taking more than 10s for the initial resolution. There is a default retry of 2 times . Don't know if changing it to more helps . I have been looking into the unbound docs on increasing the timeout in general but haven't found a good config variable yet.

                                      GengarG Offline
                                      GengarG Offline
                                      Gengar
                                      wrote on last edited by Gengar
                                      #20

                                      @girish Yeah makes sense. I will monitor and update in this post with the final result. Thx again for your help.

                                      Would I have to set this after each cloudron update ? Or is this setting never overriden ?

                                      girishG 1 Reply Last reply
                                      0
                                      • GengarG Gengar

                                        @girish Yeah makes sense. I will monitor and update in this post with the final result. Thx again for your help.

                                        Would I have to set this after each cloudron update ? Or is this setting never overriden ?

                                        girishG Offline
                                        girishG Offline
                                        girish
                                        Staff
                                        wrote on last edited by
                                        #21

                                        @Gengar I will update our code for the next release if the fix works.

                                        GengarG 1 Reply Last reply
                                        4
                                        • girishG girish

                                          @Gengar I will update our code for the next release if the fix works.

                                          GengarG Offline
                                          GengarG Offline
                                          Gengar
                                          wrote on last edited by Gengar
                                          #22

                                          @girish Unfortunatly it didn't worked...

                                          491bdadc-b96c-4f9e-a79b-11106e9b0b42-image.png

                                          The PTR6 is again viewed as null by Cloudron (and by Cloudron only, MxToolBox works fine).
                                          419c0bae-f3a8-4013-b965-4760cfc868c8-image.png

                                          The pattern I observe is that each time I have some app updates (or some notifications ?) then after a few minutes / hours (after the update / notification) it will show the PTR6 value as if it was null.

                                          see below :
                                          eb95fb78-e0ac-47fa-96eb-a1bbc4864812-image.png

                                          Yesterday I did some updates but I restarted the server also so I didn't had the issue because my workaround is to restart the server.

                                          Any ideas @girish to troubleshoot further ?

                                          Edit : added one screenshot

                                          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