Hostname Resolution With Homarr/nextjs

[qrkourier]

@thedarkula

Actually, the liveness probe is always happy.

Thanks. That's an important detail!

OK, to restate the essential details: only Homarr consistently fails to look up the address in Ziti DNS. It's a Next.js application running in Alpine w/ MUSL. The Ziti nameserver is provided by a ziti tunnel tproxy sidecar container sharing the pod interface with Homarr. The same Ziti address can be resolved in the same Homarr container by running curl, dig, or drill, ruling out the possibility that MUSL is breaking Ziti DNS because the same call to getaddrinfo is used by cURL.

Is Homarr configured like AUTH_OIDC_URI=auth.domain.com? I'm wondering precisely which part of Homarr is failing to look up that domain name. At a glance, Homarr is only using system call getaddrinfo, not doing any DNS tricks.

from: homarr/src/env.js at master · ajnart/homarr · GitHub

Based on the Dockerfile you linked earlier, are you using container image ghcr.io/homarr-labs/homarr:v1.13.0?

---

EDIT: I incorrectly assumed cURL was using getaddrinfo (asking the OS to resolve the name in Ziti DNS), when in fact cURL was built for Alpine to use ares_getaddrinfo (c-ares - Alpine Linux packages), so curl, dig, and drill are each using an alternative DNS resolver configuration, and only Homarr is using the pod's full DNS config.

Now I'll confirm whether getaddrinfo ever works with ziti tunnel's NS.

[thedarkula]

@qrkourier

Thanks. That's an important detail!

Sure thing!

@qrkourier

OK, to restate the essential details: only Homarr consistently fails to look up the address in Ziti DNS. It's a Next.js application running in Alpine w/ MUSL. The Ziti nameserver is provided by a ziti tunnel tproxy sidecar container sharing the pod interface with Homarr. The same Ziti address can be resolved in the same Homarr container by running curl, dig, or drill, ruling out the possibility that MUSL is breaking Ziti DNS because the same call to getaddrinfo is used by cURL.

That all seems correct

@qrkourier

Is Homarr configured like AUTH_OIDC_URI=auth.domain.com? I'm wondering precisely which part of Homarr is failing to look up that domain name. At a glance, Homarr is only using system call getaddrinfo, not doing any DNS tricks.

Yes, the environment variable is set as such: AUTH_OIDC_ISSUER: https://auth.domain.com/realms/realmname.
From what I can tell, nothing odd with DNS.

@qrkourier

Based on the Dockerfile you linked earlier, are you using container image ghcr.io/homarr-labs/homarr:v1.13.0?

Yes

@qrkourier

EDIT: I incorrectly assumed cURL was using getaddrinfo (asking the OS to resolve the name in Ziti DNS), when in fact cURL was built for Alpine to use ares_getaddrinfo (c-ares - Alpine Linux packages), so curl, dig, and drill are each using an alternative DNS resolver configuration, and only Homarr is using the pod's full DNS config.

Now I'll confirm whether getaddrinfo ever works with ziti tunnel's NS.

Ah, well spotted!
My suspicion is that does not

[thedarkula]

@qrkourier Have you been able to poke around?

[qrkourier]

Yes, I poked around and found some scenarios where leveraging Alpine-based applications with TPROXY mode is unreliable or impossible.

I've documented the issues w/ MUSL in:

• TPROXY mode in MUSL - error responses to IPv6 AAAA requests invalidate the IPv4 intercept answer · Issue #3075 · openziti/ziti · GitHub
• TPROXY mode in MUSL - enable split-horizon DNS · Issue #3076 · openziti/ziti · GitHub

There's no appealing workaround, though it is possible to manage this by running a separate nameserver like dnsmasq.

TL;DR Alpine-based containers that rely on the OS's resolver are currently unable to discover Ziti intercepts by domain name