[GH-ISSUE #114] DNS resolution fails on systems where NSS routes hostname lookups through systemd-resolved (e.g. Arch Linux) #606

New Issue

GiteaMirror · 2026-05-05T10:23:59-05:00

GiteaMirror commented

2026-05-05 10:23:59 -05:00

Originally created by @andusystems-dev-0 on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/fosrl/olm/issues/114

Symptom

After olm brings up the tunnel, hostname resolution for tunnel-only hostnames silently fails. Direct lookups against the in-tunnel DNS work:

dig @100.96.128.1 foo.example.internal → correct answer
getent hosts foo.example.internal → empty
curl foo.example.internal / browsers → NXDOMAIN / NS_ERROR_UNKNOWN_HOST

Olm logs indicate it thinks everything is fine:

Detected DNS manager: NetworkManager
Using NetworkManager DNS configurator
Set DNS servers: [100.96.128.1]

/etc/resolv.conf is updated as expected:

# Generated by NetworkManager
nameserver 100.96.128.1

Environment

Arch Linux (and any distro with a similar NSS hosts line)
systemd-resolved running, but not listed in /etc/resolv.conf
NetworkManager managing /etc/resolv.conf

/etc/nsswitch.conf hosts line:

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns

Root cause

On this NSS configuration, the classic dns service that reads /etc/resolv.conf is never consulted:

NSS asks resolve (systemd-resolved) first.
systemd-resolved has no DNS configured for the pangolin tunnel interface and returns NOTFOUND.
[!UNAVAIL=return] halts fallthrough — dns is never tried.

So /etc/resolv.conf is functionally irrelevant on these systems. The actual resolver is systemd-resolved, which must be configured per-interface via D-Bus (org.freedesktop.resolve1.Link.SetDNS + SetDomains + SetDefaultRoute).

Olm's existing SystemdResolvedDNSConfigurator already does exactly that — the bug is in DetectDNSManager (dns/platform/detect_unix.go), which currently returns NetworkManagerManager without checking whether NSS even consults the dns service.

Workaround (confirmed)

sudo resolvectl dns pangolin 100.96.128.1
sudo resolvectl domain pangolin '~<your-internal-domain>'

This is equivalent to what SystemdResolvedDNSConfigurator does via D-Bus.

Proposed fix

In DetectDNSManager, when the file hint is NetworkManagerManager or ResolvconfManager, also inspect /etc/nsswitch.conf. If resolve precedes dns (or dns is absent) and systemd-resolved is running, return SystemdResolvedManager so the D-Bus configurator takes over.

PR incoming.

Originally created by @andusystems-dev-0 on GitHub (Apr 21, 2026). Original GitHub issue: https://github.com/fosrl/olm/issues/114 ### Symptom After `olm` brings up the tunnel, hostname resolution for tunnel-only hostnames silently fails. Direct lookups against the in-tunnel DNS work: - `dig @100.96.128.1 foo.example.internal` → correct answer - `getent hosts foo.example.internal` → empty - `curl foo.example.internal` / browsers → NXDOMAIN / `NS_ERROR_UNKNOWN_HOST` Olm logs indicate it thinks everything is fine: ``` Detected DNS manager: NetworkManager Using NetworkManager DNS configurator Set DNS servers: [100.96.128.1] ``` `/etc/resolv.conf` is updated as expected: ``` # Generated by NetworkManager nameserver 100.96.128.1 ``` ### Environment - Arch Linux (and any distro with a similar NSS hosts line) - systemd-resolved running, but **not** listed in `/etc/resolv.conf` - NetworkManager managing `/etc/resolv.conf` - `/etc/nsswitch.conf` hosts line: ``` hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns ``` ### Root cause On this NSS configuration, the classic `dns` service that reads `/etc/resolv.conf` is never consulted: 1. NSS asks `resolve` (systemd-resolved) first. 2. systemd-resolved has no DNS configured for the `pangolin` tunnel interface and returns NOTFOUND. 3. `[!UNAVAIL=return]` halts fallthrough — `dns` is never tried. So `/etc/resolv.conf` is functionally irrelevant on these systems. The actual resolver is systemd-resolved, which must be configured **per-interface** via D-Bus (`org.freedesktop.resolve1.Link.SetDNS` + `SetDomains` + `SetDefaultRoute`). Olm's existing `SystemdResolvedDNSConfigurator` already does exactly that — the bug is in `DetectDNSManager` (`dns/platform/detect_unix.go`), which currently returns `NetworkManagerManager` without checking whether NSS even consults the `dns` service. ### Workaround (confirmed) ``` sudo resolvectl dns pangolin 100.96.128.1 sudo resolvectl domain pangolin '~<your-internal-domain>' ``` This is equivalent to what `SystemdResolvedDNSConfigurator` does via D-Bus. ### Proposed fix In `DetectDNSManager`, when the file hint is `NetworkManagerManager` or `ResolvconfManager`, also inspect `/etc/nsswitch.conf`. If `resolve` precedes `dns` (or `dns` is absent) and systemd-resolved is running, return `SystemdResolvedManager` so the D-Bus configurator takes over. PR incoming.

GiteaMirror commented

2026-05-05 10:23:59 -05:00

@andusystems-dev-0 commented on GitHub (Apr 26, 2026):

Can also be fixed by adding your Pangolin endpoint to /etc/hosts

@andusystems-dev-0 commented on GitHub (Apr 26, 2026): Can also be fixed by adding your Pangolin endpoint to /etc/hosts

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/olm#606