github-starred/olm
2
0
Fork 0
mirror of https://github.com/fosrl/olm.git synced 2026-05-06 10:47:55 -05:00
Code Issues 61 Packages Projects Releases 15 Wiki Activity

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

New Issue
Open
opened 2026-04-23 01:55:08 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-23 01:55:08 -05:00
Owner
Copy Link

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.

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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
dependencies
documentation
enhancement
good first issue
help wanted
needs investigating
pull-request
Mirrored from GitHub Pull Request
 stale
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/olm#320
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?