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

New Issue

GiteaMirror · 2026-05-24T18:11:43-05:00

GiteaMirror commented

2026-05-24 18:11:43 -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 added the stale label 2026-05-24 18:11:43 -05:00

GiteaMirror commented

2026-05-24 18:11:45 -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

GiteaMirror commented

2026-05-24 18:11:48 -05:00

@github-actions[bot] commented on GitHub (May 11, 2026):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

@github-actions[bot] commented on GitHub (May 11, 2026): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/olm#1103