Bug 1228707

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.

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.

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.

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?

(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.

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

Patches posted on upstream bugzilla entry:

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

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

brilliant way to go, many! thanks.

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