You are not logged in.
Hello,
The current version of networkmanager fails to resolve private (available in VPN only) .local domains.
Using the 'dig' command the hostname it's resolved correctly, but for firefox and ssh it fails.
Downgrading networkmanager and libnm from 1.28.1dev+7+g3f5df3cdc6-1 to 1.26 solves the problem.
Is it a known issue ?
Last edited by DeletedUser210826 (2021-07-29 08:00:25)
Offline
If you have openresolv installed, try installing systemd-resolvconf instead and enable the systemd-resolved service afterward:
systemctl enable --now systemd-resolved
Offline
Thanks for the suggestion. I did never use openresolv though.
Offline
The issue is still present in the current version (1.28.1dev+16+gdaad4e2fee-1).
Anyone knows if any recent change in networkmanager could be related to this ?
Offline
Using the 'dig' command the hostname it's resolved correctly, but for firefox and ssh it fails.
Please post the full output of 'dig' for both a hostname that works in ssh and one that doesn't. My guess it's a ipv4 vs. ipv6 thing, but let's see the output first.
Offline
I do not have any working ssh hostname with the latest networkmanager (all the machines I access to, are under VPN), and the dig output is the same.
The guess that is a VPN related problem comes from the fact that public web addresses are resolved correctly in firefox, while VPN's ones aren't working (dig output of any url is the same here as well, with both networkmanager versions).
Offline
The issue persists with version 1.30. Is there anything I could do in order to debug this?
Offline
"Aren't working" and "the same" aren't complete logs/output/versions/error messages, so it's impossible to tell if this is an issue with NetworkManager, your setup, or simply you're not understanding how name resolution works with multiple networks. That's why I asked for the output of 'dig'.
Offline
This is the output of dig, it's identical in both nm versions, and dig is able to resolve the ip in both cases:
[davide@thinkpad ~]$ dig ws.sample.local
; <<>> DiG 9.16.12 <<>> ws.sample.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59557
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ws.sample.local. IN A
;; ANSWER SECTION:
ws.sample.local. 3600 IN A 10.30.1.1
;; Query time: 370 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Sun Feb 21 13:53:40 CET 2021
;; MSG SIZE rcvd: 64
Like I said before, unfortunately currently I do not have any hostname which I can test outside a VPN, nor any working hostname.
Last edited by DeletedUser210826 (2021-07-29 08:38:58)
Offline
Solved. I do suspect the issue is because of this (from NetworkManager changelog):
* Introduce a new "rc-manager=auto" setting and make it the default,
unless a different default is chosen at compile time. This mode
tries to detect "systemd-resolved", "resolvconf", and "netconfig"
and chooses the mode that seems most suitable depending on build
setting and runtime detection. "resolvconf" and "netconfig" are
only considered iff NetworkManager was built with the respective
options enabled.
Looks like systemd-resolved fails because .local is reserved for mDNS. Configure it to use a specific DNS for your private .local domains:
# /etc/systemd/resolved.conf.d/sample.conf
[Resolve]
DNS=10.0.0.1 10.0.0.2
Domains=~sample.local
Last edited by DeletedUser210826 (2021-07-29 08:43:26)
Offline