Homarr OIDC login fails: pod DNS can not resolve auth.yukselcloud.com (EAI_AGAIN) #45

New issue

Open

opened 2026-08-02 12:56:23 +00:00 by lab · 0 comments

lab commented

2026-08-02 12:56:23 +00:00

Owner

Symptom

OIDC login on homarr.yukselcloud.com fails with EAI_AGAIN — the homarr pod cannot resolve auth.yukselcloud.com.

Root cause

Node /etc/resolv.conf is nameserver 127.0.0.53 + search lan (systemd-resolved). CoreDNS pods embed the node resolv.conf at creation. Pods query with search lan expansion (ndots:5), e.g. auth.yukselcloud.com.lan. -> forwarded upstream -> 5-10s timeouts; upstream 1.1.1.1 is flaky (UDP i/o timeouts in old coredns logs).

Evidence

homarr pod getent hosts auth.yukselcloud.com fails every time (~10s timeout, both plain and trailing-dot forms).
busybox in-cluster nslookup: 8.8.8.8 and 192.168.0.1 both resolve; 1.1.1.1 flaky.
Old coredns pod (145d) had 1.1.1.1 embedded; fresh pods read node resolv.conf (127.0.0.53 loop).

Prior attempt (reverted)

A coredns-custom ConfigMap with lan.override (template NXDOMAIN) + upstream.override (forward . 8.8.8.8 192.168.0.1) broke cluster.local + external resolution (SERVFAIL). Removed -> cluster healthy. Do NOT add a second forward . via override (Corefile import sits before the default forward).

TODO / options

Set k3s --resolv-conf to a file with real upstream nameservers (e.g. 192.168.0.1) so fresh CoreDNS pods embed a working config.
OR minimal coredns-custom that ONLY adds lan NXDOMAIN template (no forward override) + verify cluster.local unaffected.
Verify homarr getent then succeeds and OIDC login works.
Redeploy homarr after fix (current install OK otherwise).

Related: #43 (same lan-expansion root cause behind authelia slowness).

## Symptom OIDC login on `homarr.yukselcloud.com` fails with EAI_AGAIN — the homarr pod cannot resolve `auth.yukselcloud.com`. ## Root cause Node `/etc/resolv.conf` is `nameserver 127.0.0.53` + `search lan` (systemd-resolved). CoreDNS pods embed the node resolv.conf at creation. Pods query with `search lan` expansion (ndots:5), e.g. `auth.yukselcloud.com.lan.` -> forwarded upstream -> 5-10s timeouts; upstream 1.1.1.1 is flaky (UDP i/o timeouts in old coredns logs). ## Evidence - homarr pod `getent hosts auth.yukselcloud.com` fails every time (~10s timeout, both plain and trailing-dot forms). - busybox in-cluster nslookup: 8.8.8.8 and 192.168.0.1 both resolve; 1.1.1.1 flaky. - Old coredns pod (145d) had 1.1.1.1 embedded; fresh pods read node resolv.conf (127.0.0.53 loop). ## Prior attempt (reverted) A `coredns-custom` ConfigMap with `lan.override` (template NXDOMAIN) + `upstream.override` (`forward . 8.8.8.8 192.168.0.1`) broke cluster.local + external resolution (SERVFAIL). Removed -> cluster healthy. Do NOT add a second `forward .` via override (Corefile import sits before the default forward). ## TODO / options - [ ] Set k3s `--resolv-conf` to a file with real upstream nameservers (e.g. 192.168.0.1) so fresh CoreDNS pods embed a working config. - [ ] OR minimal coredns-custom that ONLY adds `lan` NXDOMAIN template (no forward override) + verify cluster.local unaffected. - [ ] Verify homarr getent then succeeds and OIDC login works. - [ ] Redeploy homarr after fix (current install OK otherwise). Related: #43 (same lan-expansion root cause behind authelia slowness).