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 answergetent hosts foo.example.internal → emptycurl 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.
Symptom
After
olmbrings 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 answergetent hosts foo.example.internal→ emptycurl foo.example.internal/ browsers → NXDOMAIN /NS_ERROR_UNKNOWN_HOSTOlm logs indicate it thinks everything is fine:
/etc/resolv.confis updated as expected:Environment
/etc/resolv.conf/etc/resolv.conf/etc/nsswitch.confhosts line:Root cause
On this NSS configuration, the classic
dnsservice that reads/etc/resolv.confis never consulted:resolve(systemd-resolved) first.pangolintunnel interface and returns NOTFOUND.[!UNAVAIL=return]halts fallthrough —dnsis never tried.So
/etc/resolv.confis 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
SystemdResolvedDNSConfiguratoralready does exactly that — the bug is inDetectDNSManager(dns/platform/detect_unix.go), which currently returnsNetworkManagerManagerwithout checking whether NSS even consults thednsservice.Workaround (confirmed)
This is equivalent to what
SystemdResolvedDNSConfiguratordoes via D-Bus.Proposed fix
In
DetectDNSManager, when the file hint isNetworkManagerManagerorResolvconfManager, also inspect/etc/nsswitch.conf. Ifresolveprecedesdns(ordnsis absent) and systemd-resolved is running, returnSystemdResolvedManagerso the D-Bus configurator takes over.PR incoming.