GNOME Bugzilla – Bug 656260
dns: support running an external script to set up resolv.conf
Last modified: 2020-11-12 14:35:08 UTC
Unencrypted wireless network, openvpn on top. My resolv.conf file contains the dns servers for the wireless network after the dns servers for the vpn network. It would be great if it didn't.
You should be able to set custom DNS servers for the VPN by setting the addressing method in the connection editor to "Automatic (addresses only)" and filling in the DNS servers and search domains yourself. Does that not work, or are you using KDE?
Gnome 3. I suppose the problem is that it's not clear what "addresses only" means. What are the addresses is it referring to? Does it mean only accept an ip address and ignore the gateway, ntp servers, etc.?
It means accept addressing-related information, but not DNS information.
Hi, just installed the Oniric Beta and the described feature doesn't work anymore. On Ubuntu 11.10 i had set up "only addresses" and entered 2 DNS Servers. Now, the Connection information shows the 2 DNS servers (correct). BUT: The /etc/resolv.conf shows the DNS servers from VPN (pptp) and there are indeed used. Versions: Network-manager 0.9.4.0-0ubuntu3
As I understand the bugreport, the problem is that NetworkManager combines DNS servers from VPN and the underlying connection and puts them to resolv.conf. And can confirm this. Moving to VPN: openvpn until someone confirms this is the case for *all* VPNs. I reproduce it with autoconfigured DNS while the original reporter also reproduced with manual DNS. I guess this feature was intentional at the beginning and I'd appreciate other developers' comments on this.
It happens for all VPNs; the VPN code just returns the nameservers, and the NM core merges that with the existing nameserver info. And it is intentional; eg, I have a network printer, and I still want to be able to resolve "printer.local" when I'm connected to the VPN. This is sort of the inverse feature request of split DNS (https://bugzilla.redhat.com/show_bug.cgi?id=842037)...
*** Bug 637894 has been marked as a duplicate of this bug. ***
> It happens for all VPNs; the VPN code just returns the nameservers, and the NM > core merges that with the existing nameserver info. Yes. I was trying to clarify how I understand the report. > And it is intentional; eg, I have a network printer, and I still want to be > able to resolve "printer.local" when I'm connected to the VPN. You should never use .local domain in DNS. It's used by Multicast DNS. But I see your point. > This is sort of the inverse feature request of split DNS > (https://bugzilla.redhat.com/show_bug.cgi?id=842037)... So let's support both (leaving the default as is).
There are lots of people who want to slightly tweak resolv.conf management in slightly different ways. Rather than add options for every possibility, we're just going to make it possible to write your own script to write out resolv.conf the way you want it. bug 603321 will add a DnsManager to NM's D-Bus interfaces, so that you can actually see the current set of DNS information from the current connections. Once we have that, we can add support for having external DNS-management scripts, which can use the DnsManager information to figure out what they want to write to resolv.conf
*** Bug 673793 has been marked as a duplicate of this bug. ***
*** Bug 695384 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > bug 603321 will add a DnsManager to NM's D-Bus interfaces, so that you can > actually see the current set of DNS information from the current connections. > Once we have that, we can add support for having external DNS-management > scripts, which can use the DnsManager information to figure out what they want > to write to resolv.conf Maybe those two tickets could be merged?
They're two separate features. 603321 is still useful for other things even if we didn't implement this.
(In reply to comment #14) > They're two separate features. 603321 is still useful for other things even if > we didn't implement this. OK.
*** Bug 702013 has been marked as a duplicate of this bug. ***
Just to keep everyone updated... Tomáš Hozza is currently using the dispatcher scripts as a way to set up unbound and dnssec-trigger correctly, while dnssec-trigger locks /etc/resolv.conf so it's not updated by NetworkManager. I know it is suboptimal, but there's currently no better way.
You can follow Tomáš's work here: http://www.nlnetlabs.nl/svn/dnssec-trigger/trunk/contrib/01-dnssec-trigger-hook-new_nm The script is now written in Python and uses NetworkManager API to retrieve most of the information it needs.
Yep and we also support dns=none to avoid writing to /etc/resolv.conf, so this seems to be actually fixed.
no, this is about dns=/usr/bin/my-resolv.conf-updating-script
(In reply to comment #20) > no, this is about dns=/usr/bin/my-resolv.conf-updating-script Ah, yes, that would be useful at least as an optimization of the current ways.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).