Federation doesn't fail over to IPv4 when IPv6thenIPv4 is used and AAAA records are returned for a domain #1686

New issue

Open

opened 2026-04-19 00:52:34 +00:00 by Quasido · 4 comments

Quasido commented

2026-04-19 00:52:34 +00:00

When browsing the internet on a dual-stack connection the standard is to try IPv6 and fail back to IPv4 if the connection fails. When Continuwuity connects to a domain with an AAAA record, but is refused connection by the remote firewall, it fails to connect to the remote server. This is true even if A records are published and the IPv4 traffic is allowed through the firewall.

👍 2

stratself commented

2026-04-19 04:33:34 +00:00

Contributor

So the firewall blocks v6-traffic? In that case you shohld use Ipv4OverIpv6, or Ipv4Only

Do let me know of the specific domain so I can maybe test on my side

So the firewall blocks v6-traffic? In that case you shohld use Ipv4OverIpv6, or Ipv4Only Do let me know of the specific domain so I can maybe test on my side

Quasido commented

2026-04-19 04:41:44 +00:00

Author

(Un)fortunately I was in contact with the admin of the server in question and they fixed their v6 firewall rules.

IPv6 is the current internet best practice; it shouldn't be disabled because a server I was trying to federate with was poorly configured. My server's IPv6 and firewall were fine.

The issue was, the remote server published AAAA records for their domain. However their firewall was incorrectly configured and was not allowing any v6 traffic in. They also had A records for IPv4. I temporarily added a local-zone to my unbound config to make it appear as if their domain did not have AAAA records. This enabled my server to communicate with theirs while they fixed their firewall.

(Un)fortunately I was in contact with the admin of the server in question and they fixed their v6 firewall rules. IPv6 is the current internet best practice; it shouldn't be disabled because a server I was trying to federate with was poorly configured. My server's IPv6 and firewall were fine. The issue was, the remote server published AAAA records for their domain. However their firewall was incorrectly configured and was not allowing any v6 traffic in. They also had A records for IPv4. I temporarily added a local-zone to my unbound config to make it appear as if their domain did not have AAAA records. This enabled my server to communicate with theirs while they fixed their firewall.

stratself commented

2026-04-19 05:59:18 +00:00

Contributor

I can confirm a potential bug when ip_lookup_strategy = 4 with an IPv4-only network. This seems to affect outbound conns to all dual-stack enabled servers.

Steps to repro:

Has no IPv6 connectivity. I did this by setting my Continuwuity container network to pasta:--ipv4-only
!admin debug ping tchncs.de, this returns a tcp connect error: Network is unreachable response
!admin debug resolve-true-destination tchncs.de returns a wrong address (Destination: tchncs.de:8448; Hostname URI: tchncs.de:8448)
Meanwhile, !admin debug ping frei.chat (an IPv4-only server) is fine

Looking at DNS logs, I can see the following behavior (most recent query first)

tchncs.de

No A requests were even made for this domain. C10y asks for an AAAA record, tries to .well-known it, fails, and fallback to SRV. When it fails again, it tries to reach out to tchncs.de:8448 over IPv6

Expand for image

frei.chat

C10y asks for an AAAA record, it doesn't exist. It then asks for an A record and can connect as normal.

Expand for image

It seems like the internal resolver will fully follow the default v6 steps, and only switch to v4 only if there is no v6 DNS record in place. Even on domains with SRV records, the target SRV will be resolved via AAAA records, not A. This affect connectivity as switching stack after .well-known doesn't seem feasible. Furthermore, knowing #1615 exists, I wonder if there are any caching problems associated with this approach.

I believe c10y should handle dual-stack more seamlessly rather than relying only on existence of DNS records. This would help resolve issues like intermittent ipv6 disconnectivity and other failure modes (e.g. remote servers misconfig like you said). Let's see if the new resolver backend will be able to handle this.

I can confirm a potential bug when `ip_lookup_strategy = 4` with an IPv4-only network. This seems to affect outbound conns to all dual-stack enabled servers. Steps to repro: - Has no IPv6 connectivity. I did this by setting my Continuwuity container network to `pasta:--ipv4-only` - `!admin debug ping tchncs.de`, this returns a `tcp connect error: Network is unreachable` response - `!admin debug resolve-true-destination tchncs.de` returns a wrong address (`Destination: tchncs.de:8448; Hostname URI: tchncs.de:8448`) - Meanwhile, `!admin debug ping frei.chat` (an IPv4-only server) is fine Looking at DNS logs, I can see the following behavior (most recent query first) **tchncs.de** No A requests were even made for this domain. C10y asks for an AAAA record, tries to .well-known it, fails, and fallback to SRV. When it fails again, it tries to reach out to `tchncs.de:8448` _over IPv6_ <details> <summary>Expand for image</summary> ![image](/attachments/c6d0c10d-2aa1-4580-85d0-eeb87d1c285b) </details> **frei.chat** C10y asks for an AAAA record, it doesn't exist. It then asks for an A record and can connect as normal. <details> <summary>Expand for image</summary> ![image](/attachments/ff3250a8-c32e-411f-b2b3-ead22883e72d) </details> It seems like the internal resolver will fully follow the default v6 steps, and only switch to v4 _only if there is no v6 DNS record in place_. Even on domains with SRV records, the target SRV will be resolved via AAAA records, not A. This affect connectivity as switching stack _after .well-known_ doesn't seem feasible. Furthermore, knowing #1615 exists, I wonder if there are any caching problems associated with this approach. I believe c10y should handle dual-stack more seamlessly rather than relying only on existence of DNS records. This would help resolve issues like intermittent ipv6 disconnectivity and other failure modes (e.g. remote servers misconfig like you said). Let's see if the new [resolver backend](https://forgejo.ellis.link/continuwuation/resolvematrix/) will be able to handle this.

image.png

97 KiB

image.png

104 KiB