bug: Can not connect OIDC in a dual stack environment.

[Heracles31]

Describe the bug

Infos already posted in the Discord help group here

Deployed Homarr 1.18.1 in a dual stack Kubernetes cluster. DNS resolution works and returns both A and AAAA records. Ingress works and listens on both v4 and v6 addresses.

Homarr is configured for OIDC authentication using Keycloak deployed in the very same cluster.

When configured properly for it, Homarr just says that all logins fail. In the log, there is this :

2025-04-28T03:28:09.512Z error: fetch failed 
... 
    at async doRender (/app/node_modules/next/dist/server/base-server.js:1513:42)
caused by Error: getaddrinfo ENOTFOUND auth.domain.tld errno="-3007" code="ENOTFOUND" syscall="getaddrinfo" hostname="auth.domain.tld"
    at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:122:26)
    at GetAddrInfoReqWrap.callbackTrampoline (node:internal/async_hooks:130:17)

From inside the pod, DNS works :

/app # nslookup auth.domain.tld
Server:         10.96.0.10
Address:        10.96.0.10:53

auth.domain.tld   canonical name = nginx-ing64.domain.tld
Name:   nginx-ing64.domain.tld
Address: 172.24.138.10

auth.domain.tld   canonical name = nginx-ing64.domain.tld
Name:   nginx-ing64.domain.tld
Address: 2001:0DB8:6000:c4::100

But OpenSSL can not connect using the DNS name :
/```app # openssl s_client -connect auth.domain.tld:443
28AB5B27057F0000:error:10080002:BIO routines:BIO_lookup_ex:system lib:crypto/bio/bio_addr.c:763:Name has no usable address
connect:errno=22

If I hard code the IPv4 in the hosts file, it works.

### Steps to reproduce

Deploy in a similar environment and try OIDC / DNS resolution from the pod...


### Impact

Unable to use OIDC at all which defeats the purpose of using Homarr over here.

### Additional information

Talos Linux 1.9.5 ; Kubernetes 1.32.2 ; Flannel ; but considering how DNS works from inside and that the hard coding in the host file bypass the bug, I highly doubt it is related to environment....

### Version

1.18.0

### Installation method

Helm

### Browser

Safari

[manuel-rw]

@oben01 I don't see how IPv6 should be an issue in the integrations code itself, so I redirect this issue to you.
Can you look into it and confirm whether it's related to the chart or not? Let me know if I can assist somehow

[oben01]

Hello @Heracles31 could u please try to modify homarr-service to something like and let me now if it fixes the issue

[Heracles31]

Hi,

Indeed, the service ended up single stack IPv4.

    "spec": {
        "clusterIP": "10.104.216.157",
        "clusterIPs": [
            "10.104.216.157"
        ],
        "internalTrafficPolicy": "Cluster",
        "ipFamilies": [
            "IPv4"
        ],
        "ipFamilyPolicy": "SingleStack",
        "ports": [
            {
                "name": "app",
                "port": 7575,
                "protocol": "TCP",
                "targetPort": "http"
            }
        ],

FYI, Longhorn is the same about this : it is single stack IPv4 and does not support IPv6 at all. Should the cluster be IPv6 or IPv6 / IPv4, Longhorn does not connect. But with IPv4 only or a dual stack as IPv4 / IPv6, it does work.

Here, Longhorn does work as an IPv4 only service.

As for how to modify the service, I do not see an option for that in the chart. I will try to edit it / re-create it manually for debug purposes.

Should be able to post the results soon.

(Je parle français aussi si cela peut être utile...)

[Heracles31]

There is also the fact that the problem is not reaching the service / the pod from outside. The problem is that pod being unable to resolve the DNS name of its OIDC provider to reach it. The evidence is the workaround, which is to hard code the OIDC's IPv4 address in the pod's hosts file. With such a hard coding, the OIDC function works.

[oben01]

Thank you @Heracles31 for the clarification.
I believe we may need to add an additional value for podDnsConfig.
To confirm whether this would work, could you please take a look at this section of the Kubernetes documentation and try modifying the pod as needed?
If your tests are successful, I’ll go ahead and include the feature.

[Heracles31]

Hi again,

Did not had the time to do the test yet but again, I doubt this will change anything...

Sorry for my last comment... I said that the pod did not resolve the DNS name. That is not true. It does. It does to the point of getting both A and AAAA records. Problem is that the pod tries to dial out over IPv6 because it received an AAAA records. But being an IPv4 only pod, it can not.

The problem is, it gives up after that instead of trying the A record / IPv4. That is also why the fix of hard coding the IPv4 only in the hosts file works : the pod goes straight for IPv4, which it can do.

The pod should either be dual stack whenever the cluster is. If not, it must ensure to restrict itself to IPv4 and here, it means doing a DNS query for A record (not AAAA or Any) ; discard IPv6 addresses or try all addresses instead of giving up after a first failure.

[oben01]

Hi again,

It looks like this issue is related to Node.js rather than Kubernetes itself. The application running inside the Pod is resolving both IPv4 (A) and IPv6 (AAAA) DNS records, and it's attempting to connect using IPv6 first. When the IPv6 connection fails, it doesn’t properly fall back to IPv4 which is likely due to the way Node.js handles DNS resolution or how the base Alpine image behaves with networking.

@manuel-rw do you have any insight on this? One possible fix might be to set the environment variable NODE_OPTIONS="--dns-result-order=ipv4first", which tells Node.js to prefer IPv4 over IPv6 when resolving hostnames.
Node doc

We could also consider making this configurable in the Helm chart (not tested yet), something like:

ipv6:
  disable: true

And apply it in the Deployment:

env:
  - name: NODE_OPTIONS
    value: {{ if .Values.ipv6.disable }}"--dns-result-order=ipv4first"{{ else }}""{{ end }}

Let me know your thoughts!

[Heracles31]

Your description is 100% accurate and corresponds exactly to what is happening here. The symptom, the workaround with the hosts file, etc.

The option to order ipv4 first would fix my situation for sure.

How hard would it be to specify the pod's ipFamilies as PrefereDualStack, for it to get an IPv6 when possible ? With one, it would be able to dial out over IPv6 just like it does over IPv4. The ipFamilies option could be an option in the helm chart as well.

[oben01]

Glad to hear the diagnosis matches what you're seeing.

As mentioned, setting NODE_OPTIONS="--dns-result-order=ipv4first" should resolve the issue by forcing Node.js to prefer IPv4 when both A and AAAA DNS records are present. Could you give that a try in your environment and let me know if it fixes the issue? That would help validate the solution before we include it as a configurable option in the Helm chart.

Regarding your suggestion about ipFamilies: yes, we can definitely expose that in the Helm chart for users running in dual-stack clusters. For example:

network:
  ipFamilyPolicy: "PreferDualStack"
  ipFamilies:
    - IPv6
    - IPv4

And in the deployment manifest:

spec:
  ipFamilyPolicy: {{ .Values.network.ipFamilyPolicy | quote }}
  ipFamilies:
  {{- range .Values.network.ipFamilies }}
    - {{ . | quote }}
  {{- end }}

We’ll make sure to keep this optional and well documented since it requires dual-stack support at the cluster and CNI level.

Let me know how the NODE_OPTIONS test goes and happy to move forward with chart updates once we confirm!

[Heracles31]

I searched how / where can I configure this and did not find the proper way. I tried to export an environment variable NODE_OPTIONS="--dns-result-order=ipv4first" but it did not change anything.

Did a grep -R NODE_OPTIONS in /app and did not find an obvious place / syntax to add it.

Should I modify the pod / add an environment variable, I also did not find how to re-start Node.js for it to take the new config without restarting the pod, so removing my modification at the same time.

Please, give a complete set of command about how to test this. I am pretty sure this is the problem and that would just confirm it.

[oben01]

u can use the env entry in the values file something like :

env:
  NODE_OPTIONS="--dns-result-order=ipv4first"

[Heracles31]

Just a little typo in your line... It has to be
NODE_OPTIONS: --dns-result-order=ipv4first
instead of
NODE_OPTIONS="--dns-result-order=ipv4first"

Unfortunately, I have the same error : Login failed (Your login failed) in the Web page and the DNS error in kubectl logs

at async doRender (/app/node_modules/next/dist/server/base-server.js:1513:42)
caused by Error: getaddrinfo ENOTFOUND auth.jblan.ca errno="-3007" code="ENOTFOUND" syscall="getaddrinfo" hostname="auth.domain.tld"
    at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:122:26)
    at GetAddrInfoReqWrap.callbackTrampoline (node:internal/async_hooks:130:17)

When I open a shell in the pod and do nslookup on the domain name, it works. I receive both IPv4 and IPv6 resolutions, with the IPv6 listed first. The node option is also there :

/app # echo $NODE_OPTIONS
--dns-result-order=ipv4first

And even more surprising is that doing ip -a in the pod shows that it did receive an IPv6 address...

Even stranger is that openssl itself can not connect the socket. From inside the pod, I do openssl s_client -connect auth.domain.tld:443 and receive :

283B0F01B57F0000:error:10080002:BIO routines:BIO_lookup_ex:system lib:crypto/bio/bio_addr.c:763:Name has no usable address
connect:errno=22