# Hostname Resolution With Homarr/nextjs **URL:** \ **Category:** General Questions\ **Created:** [March 25, 2025, 8:27pm UTC](https://openziti.discourse.group/t/hostname-resolution-with-homarr-nextjs/4248 "2025-03-25T20:27:11Z")\ **Posts on this page:** 4\ **Page:** 2
**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\ **Post date:** [March 28, 2025, 7:44pm UTC](https://openziti.discourse.group/t/hostname-resolution-with-homarr-nextjs/4248/21 "2025-03-28T19:44:07Z")
> [@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](https://github.com/ajnart/homarr/blob/master/src/env.js#L94) 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](https://pkgs.alpinelinux.org/package/edge/main/x86/c-ares)), 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. ---
**Author:** ![thedarkula](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thedarkula/32/1459_2.png) [@thedarkula](https://openziti.discourse.group/u/thedarkula)\ **Post date:** [March 28, 2025, 9:18pm UTC](https://openziti.discourse.group/t/hostname-resolution-with-homarr-nextjs/4248/22 "2025-03-28T21:18:23Z")
> [@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](https://pkgs.alpinelinux.org/package/edge/main/x86/c-ares)), 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 馃檪 ---
**Author:** ![thedarkula](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thedarkula/32/1459_2.png) [@thedarkula](https://openziti.discourse.group/u/thedarkula)\ **Post date:** [May 21, 2025, 8:01am UTC](https://openziti.discourse.group/t/hostname-resolution-with-homarr-nextjs/4248/23 "2025-05-21T08:01:50Z")
@qrkourier Have you been able to poke around? 馃檪 ---
**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\ **Post date:** [June 2, 2025, 3:41pm UTC](https://openziti.discourse.group/t/hostname-resolution-with-homarr-nextjs/4248/24 "2025-06-02T15:41:08Z")
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](https://github.com/openziti/ziti/issues/3075) - [TPROXY mode in MUSL - enable split-horizon DNS 路 Issue #3076 路 openziti/ziti 路 GitHub](https://github.com/openziti/ziti/issues/3076) 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 [Previous page](https://openziti.discourse.group/t/hostname-resolution-with-homarr-nextjs/4248.md?page=1)