infomaniak IPv6 issues

[girish]

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

[Gengar]

@girish Unfortunatly it didn't worked...

The PTR6 is again viewed as null by Cloudron (and by Cloudron only, MxToolBox works fine).

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 :

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

[Gengar]

I can't really understand why each first try of :
host -t PTR <ipv6> 127.0.0.150 always fails instantly.

And each second try works instantly.

Binding seems correct, it's listning :

I also tried to generate a trace of a dig of my ipv6 dig -x <my_ipv6> @127.0.0.150 +trace

Here is the result :

dig -x <my_ipv6> @127.0.0.150 +trace

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> -x <my_ipv6> @127.0.0.150 +trace
;; global options: +cmd
.                       300     IN      NS      h.root-servers.net.
.                       300     IN      NS      i.root-servers.net.
.                       300     IN      NS      j.root-servers.net.
.                       300     IN      NS      k.root-servers.net.
.                       300     IN      NS      l.root-servers.net.
.                       300     IN      NS      m.root-servers.net.
.                       300     IN      NS      a.root-servers.net.
.                       300     IN      NS      b.root-servers.net.
.                       300     IN      NS      c.root-servers.net.
.                       300     IN      NS      d.root-servers.net.
.                       300     IN      NS      e.root-servers.net.
.                       300     IN      NS      f.root-servers.net.
.                       300     IN      NS      g.root-servers.net.
.                       300     IN      RRSIG   NS 8 0 518400 20250409050000 20250327040000 26470 . PVIijRDCpvp/usENq3aRJ+1WJb76GXi7mM85QySLrS6ixxDl5QbQo1Di Sl9wPYETpkYfZrRW4jDhOJyVAHtjit1m9ZJ2MAu9Rhcq72O7J/unHyjL K8vpXhwRQOwggasqVvFiqBDBlOh+TvKmxk++50UrFnokaFMbbJ45+H3t TAZ5CThu0VQwkNDFIGXdcupMGYO/GabVtEVjC22m12mZjMD8udjHbO1D msVclMSGFiGhi4LAjgCBDpx9sld7BeEkv/lIlZs8S/9GJ09a/+5sqe+d 2byJnEcdGUYE1kjHGA/mE6I2lncLKeyt1awD8CPhh3OGkDaiPCzDskwH pUs0aQ==
;; Received 525 bytes from 127.0.0.150#53(127.0.0.150) in 74 ms

;; communications error to 2001:500:2f::f#53: timed out
;; communications error to 2001:500:2f::f#53: timed out
;; communications error to 2001:500:2f::f#53: timed out
ip6.arpa.               172800  IN      NS      f.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      c.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      a.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      b.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      d.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      e.ip6-servers.arpa.
ip6.arpa.               86400   IN      DS      45094 8 2 E6B54E0A20CE1EDBFCB6879C02F5782059CECB043A31D804A04AFA51 AF01D5FB
ip6.arpa.               86400   IN      DS      13880 8 2 068554EFCB5861F42AF93EF8E79C442A86C16FC5652E6B6D2419ED52 7F344D17
ip6.arpa.               86400   IN      DS      64060 8 2 8A11501086330132BE2C23F22DEDF0634AD5FF668B4AA1988E172C6A 2A4E5F7B
ip6.arpa.               86400   IN      RRSIG   DS 8 2 86400 20250409060000 20250327050000 41220 arpa. BrH6HJZNlu//lKOfi1e71GXexN7Q9Xxup1XbXiXQQ1YaxU82FszIRDtg 7OJQ8NmOuIiGhLsHAbsB/aBdIsh+8QeCYYXw7NvnT7sIHDAsXdNEs1qv cxh/4j7BIocLqPf4BMDW9ng9JuppGkg3fXrA7nOiPZMZxJ0UrsWzCtKR bDc2tgrS6Q6nwuo+1c/75C51TkTXqC5iq+mA3ouS2H/UKmbEnOOMt1y+ GaY7R2zU+vWRnJ0CQjqR8cn8wL2LkKvxEJ//wWymu4onhggPrPOiiyyK 77No8mh9CJlreLN9eIa+2qpDdfDZZvUpFoh2uJbDw0nVZgmhvO6faUdw ocrRAQ==
;; Received 949 bytes from 192.112.36.4#53(g.root-servers.net) in 38 ms

6.1.1.0.0.2.ip6.arpa.   86400   IN      NS      ns4.apnic.net.
6.1.1.0.0.2.ip6.arpa.   86400   IN      NS      pri.authdns.ripe.net.
6.1.1.0.0.2.ip6.arpa.   86400   IN      NS      rirns.arin.net.
6.1.1.0.0.2.ip6.arpa.   86400   IN      NS      ns3.afrinic.net.
6.1.1.0.0.2.ip6.arpa.   86400   IN      NS      ns3.lacnic.net.
6.1.1.0.0.2.ip6.arpa.   86400   IN      DS      3320 13 2 36869F9062FA3449B6362A3C618B7F17949E8729D355510E224789ED 165F0AD9
6.1.1.0.0.2.ip6.arpa.   86400   IN      RRSIG   DS 8 8 86400 20250417050647 20250327071005 29628 ip6.arpa. oqnemTiOsFj0CxOy5DjTdN8ml4bE47lmKONe+4NMdVS+gNclSwaDWycN UDAj+wFoI2dbM20Iy8jZvcgim6icQ02M77a1p5fK9SSozGYONEjXE7De 4w2jnNBOXzX+JOur97+Vf1YyC9e1LfEp/cbhbTtRxf3/7fgKke9aj4Co LXg=
;; Received 483 bytes from 193.0.9.2#53(f.ip6-servers.arpa) in 16 ms

;; communications error to 2001:67c:e0::5#53: timed out
;; communications error to 2620:38:2000::53#53: timed out
1.0.1.0.3.1.0.0.0.0.6.1.1.0.0.2.ip6.arpa. 86400 IN NS ns1.infomaniak.ch.
1.0.1.0.3.1.0.0.0.0.6.1.1.0.0.2.ip6.arpa. 86400 IN NS ns2.infomaniak.ch.
1.0.1.0.3.1.0.0.0.0.6.1.1.0.0.2.ip6.arpa. 3600 IN NSEC 2.0.1.0.3.1.0.0.0.0.6.1.1.0.0.2.ip6.arpa. NS RRSIG NSEC
1.0.1.0.3.1.0.0.0.0.6.1.1.0.0.2.ip6.arpa. 3600 IN RRSIG NSEC 13 18 3600 20250409180748 20250326163748 58998 6.1.1.0.0.2.ip6.arpa. 5jdTVibPvZSZ5qdnaTmefipFkNuRMvODtFmpW/nOELP8QTKQzo9mDHxg Zk6YdI2BZiS5AQR59bLAdJTlklvl2w==
;; Received 396 bytes from 199.253.249.53#53(rirns.arin.net) in 90 ms

5.REVERSED_OF_my_IPV6.2.ip6.arpa. 3600 IN PTR my.DOMAIN.XYZ.
1.0.1.0.3.1.0.0.0.0.6.1.1.0.0.2.ip6.arpa. 86400 IN NS ns1.infomaniak.ch.
1.0.1.0.3.1.0.0.0.0.6.1.1.0.0.2.ip6.arpa. 86400 IN NS ns2.infomaniak.ch.
;; Received 247 bytes from 84.16.67.66#53(ns2.infomaniak.ch) in 1 ms

[Gengar]

After some digging I've understood that Cloudron is using Hakara in a docker container as the SMTP mail server.

So I guess the whole mail server stack is running in a docker container.

Based on those facts, I had a look if ipv6 was enabled in docker.

I saw that Docker is configured to manage IPv6 firewall rules (iptables) using ps aux | grep dockerd . => --storage-driver=overlay2 --experimental --ip6tables --userland-proxy=false

but that containers aren't using ipv6 : sudo docker network inspect bridge | grep -A 5 IPv6
Result :

"EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {

@girish , if I create a custom config file "deamon.js" in /etc/docker/daemon.json , and I add this config inside the json to enable ipv6 inside containers :

{
  "ipv6": true,
  "fixed-cidr-v6": "fd00:dead:beef::/64"
}

Do you think it could solve the issue ? Because I guess reverse DNS checks likely happen inside this mail container ?
And maybe each app update reset the docker network bridge ? And then the mail container loses ipv6 connectivity / ability to do his rever DNS check for ipv6 correctly ?

I really don't know, trying to figure things out here.

[jdaviescoates]

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

Do you think it could solve the issue ? Because I guess reverse DNS checks likely happen inside this mail container ?

if that was the issue then wouldn't we all be having the strange issues you're having? Speaking personally my PTR6 status has been fine and green ever since I initially set it.

[Gengar]

@jdaviescoates yeah i thought about that too and I guess you are right…

But I really have no other leads rn …

[Gengar]

@girish I think I have very interesting new information to narrow down the possibilities for the root cause. What I did is that I tried to restart every component/service I could, starting from the most specific (mail container) to the most general (full system reboot):

Service / Component restarted	Result
sudo docker restart mail	NOK
sudo systemctl restart box	NOK
sudo systemctl restart docker	NOK – I had to restart apps manually due to bad gateway / 500 errors.
sudo systemctl restart unbound	NOK
sudo systemctl restart systemd-resolved	NOK
sudo systemctl restart systemd-networkd	NOK
sudo netplan apply	NOK
sudo reboot	OK – PTR6 works again.

So I asked myself: what could exist between the NOK and OK state that I hadn't tried?

I decided to target the IPv6 stack of the OS directly. I ran:

sudo ip -6 neigh flush all
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sleep 2
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0

️ After this, it was still NOK, but interestingly it reported the PTR6 = null state instantly, instead of the usual 1–2 minute delay. That suggested something was cleared or reset => Makes sense as I flushed.

After flushing the IPv6 neighbours and disabling / re-enabling the ipv6 module I've restarted netplan and docker :

sudo netplan apply
sudo systemctl restart docker

️ Again, after restarting Docker I had to manually restart all apps (some with bad gateway / nginx errors like n8n). But...

---

IT WORKED!

The PTR6 value was immediately resolved again and Cloudron no longer shows null. So this suggests that the root cause may lie somewhere in the interaction between the kernel IPv6 stack and Docker’s networking layer ? particularly after updates...

What do you think @girish ? What could be the root cause ?

[joseph]

Not sure, but in many VPS , IPv6 and related networking are simply not that reliable . It's hard to point at the root cause without debugging the setups. Which VPS are you using, if you don't mind sharing?

[Gengar]

@joseph I'm using a VPS from Infomaniak. => https://www.infomaniak.com/

[joseph]

@Gengar should I use https://www.infomaniak.com/en/hosting/vps-lite ? Can't make out if those have IPv6

[Gengar]

@joseph Yeah I'm using a vps light And it has IPv6

[Gengar]

@joseph Did you had the chance to make a try ?

On my side I'm stuck and still having this issue 🥲

[Gengar]

@girish It should take aproximatly 10 minutes to 15 minutes for the order to perform If I remember correctly.

[girish]

@Gengar I have created a ticket now to set the PTR records. But going back to your original issue:

"host -t PTR <ipv6> 127.0.0.150 always fails instantly." This works just fine on my VPS. Maybe you have some firewall rules? I just allowed everything incoming in firewall.

ubuntu@ov-9503b4:~$ host -t PTR 45.55.2.141 127.0.0.150
Using domain server:
Name: 127.0.0.150
Address: 127.0.0.150#53
Aliases: 

141.2.55.45.in-addr.arpa domain name pointer my.cloudron.io.
ubuntu@ov-9503b4:~$ host -t PTR 2604:a880:1:4a::2:7000 127.0.0.150
Using domain server:
Name: 127.0.0.150
Address: 127.0.0.150#53
Aliases: 

0.0.0.7.2.0.0.0.0.0.0.0.0.0.0.0.a.4.0.0.1.0.0.0.0.8.8.a.4.0.6.2.ip6.arpa domain name pointer my.cloudron.io.

[Gengar]

This post is deleted!

[Gengar]

@girish Okay so here it doesn't work the same. For example I've rebooted my server this morning (like 2 hours ago) beceause my PTR6 was null.

And I've tried again and yeah, I have a communication error during the 1st try that you don't have. But each time it resolve it even with the communication error and the 2nd time it always works. And I have this exact behavior each time.

That's weird.

My firewall is setup like this :

[scooke]

OK, i'm gonna say it: It's something to do with infomaniak, and it's time to move to a different VPS provider.

[Gengar]

@scooke 🥲 I really like Infomaniak especially their commitment to ecology https://www.infomaniak.com/en/ecology ... If I have no other choices maybe I will switch to another hosting provider... We will see...

[BrutalBirdie]

@Gengar
Just read the Hetzner page: https://www.hetzner.com/unternehmen/nachhaltigkeit/
If you are looking for an eco-friendly provider, Hetzner is pretty good.

[Gengar]

@BrutalBirdie Oh thanks for the link ! I will read what they do