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