Bug 1228707 - it would make sense for NM to allow specifying an order for DNS servers
Summary: it would make sense for NM to allow specifying an order for DNS servers
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.1
Hardware: x86_64
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1301628 1313485
TreeView+ depends on / blocked
 
Reported: 2015-06-05 13:39 UTC by lejeczek
Modified: 2016-11-03 19:14 UTC (History)
8 users (show)

Fixed In Version: NetworkManager-1.4.0-0.1.git20160606.b769b4df.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 19:14:02 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2581 normal SHIPPED_LIVE Low: NetworkManager security, bug fix, and enhancement update 2016-11-03 12:08:07 UTC
GNOME Bugzilla 758772 None None None 2016-04-27 14:45:56 UTC

Description lejeczek 2015-06-05 13:39:46 UTC
Description of problem:

.. over before those from DHCP, so manually set DNS would have the highest priority.

Version-Release number of selected component (if applicable):

NetworkManager-1.0.0-14.git20150121.b4ea599c.el7.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 4 Beniamino Galvani 2016-03-30 14:20:04 UTC
Hi,

do you have a specific use case for this? The feature doesn't seem
particularly useful to me because if want to use a static DNS server
you can just set ipv4.ignore-auto-dns=yes to use it instead of the one
provided by DHCP.

I imagine that having both set and giving the precedence to the static
one means that you want to use the dynamic one as a backup in case the
other doesn't respond; but I don't see the advantage of such setup.

Comment 5 lejeczek 2016-03-30 18:45:01 UTC
hi,
think "bigger" than this :) actually not big at all. A box with more then one active interfaces - one has dhcp given dns and the other has manual, or just one has manual (for a reason) and many other have dhcp, and you want all DNS server to be in your query path.
Maybe even (too) connection.autoconnect-priority should directly affect the order of dns servers.

Comment 6 Beniamino Galvani 2016-03-31 08:19:36 UTC
If we consider multiple connections then things start to be more
complicated... :) When it has to update resolv.conf, NM considers the
device having the default route as the preferred one and puts its DNS
servers before others. The idea is that when your traffic is going by
default to a interface, you want to use the DNS server provided by the
active connection associated to that interface.

So if I understand correctly you are looking for a way to give
nameservers from a given connection a higher priority than
others. Wouldn't the current implementation be enough to do this?
Note that you can assign to each connection a different
ipv4.route-metric to ensure that a choosen one will get the default
route and its DNS servers will be at the top of the list.

Comment 7 lejeczek 2016-03-31 09:32:27 UTC
this is "Enterprise Linux", we have to consider complicated scenarios.
If route-metric does that, sets DNS servers order accordingly then it's great! -half of the problem solved.
But still easy to get into a situation where a user/admin needs to attach manually a DNS to one (among many) connection, when s/he does that then almost certainly for there is a need for it - to be there at the top.
Or assume all multiple connections have manually set dns and connection metric (weirdly enough does not reflect connection priorities) - I thought connection.autoconnect-priority sounds like the place - what does it affect anyway?

Comment 8 Beniamino Galvani 2016-03-31 15:54:46 UTC
(In reply to lejeczek from comment #7)
> But still easy to get into a situation where a user/admin needs to attach
> manually a DNS to one (among many) connection, when s/he does that then
> almost certainly for there is a need for it - to be there at the top.
> Or assume all multiple connections have manually set dns and connection
> metric (weirdly enough does not reflect connection priorities) - I thought
> connection.autoconnect-priority sounds like the place - what does it affect
> anyway?

autoconnect-priority is used to choose the connection to auto-activate
when multiple ones are available for a device (see 'man nm-settings'),
so I don't think it should have anything to do with DNS servers.

What NM does now WRT DNS server selection seems reasonable to me and
allows a good level of customization, since you can choose between a
static or dynamic name server (or both) for each connection and which
connection will be the preferred one.

But if you want to implement a more complex logic probably you can set
dns=none in NetworkManager.conf and use dispatcher scripts to update
resolv.conf according to your needs.

Basically you can place your scripts in
/etc/NetworkManager/dispatcher.d/ and NM will run them after certain
events (like connections going up and down), providing the connection
parameters in the environment (including the list of DNS servers); see
'man NetworkManager' for the details.

Comment 9 lejeczek 2016-03-31 18:47:15 UTC
we know dispatcher.

back to my original request - if a user/admin decides to use/set DNS manually for a connection I believe (only acceptable logic to me) s/he does it deliberately, purposefully hoping this is "the dns" - otherwise, what's the point.

ps. I don't get why bugzilla, if I remember it correctly did in the old days, does not let us flank reports (@ filing in time) as other than bug doc types - I thought of it more as enhancement than a bug.

let's close it.
thanks

Comment 10 Beniamino Galvani 2016-04-27 14:45:56 UTC
Patches posted on upstream bugzilla entry:

https://bugzilla.gnome.org/show_bug.cgi?id=758772

Comment 11 Beniamino Galvani 2016-05-12 16:19:43 UTC
With upstream commit [1], it is now possible to specify a priority for DNS configurations of connections:

[1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=8da3e658f7313f56928d22cfe13f9ab78cc1dd3c

Comment 13 lejeczek 2016-07-01 09:17:23 UTC
brilliant way to go, many! thanks.

Comment 15 errata-xmlrpc 2016-11-03 19:14:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2581.html


Note You need to log in before you can comment on or make changes to this bug.